排查 Lambda 中的事件源映射问题
Lambda 中与事件源映射相关的问题可能更加复杂,因为它们涉及跨多项服务的调试。此外,根据所使用的确切事件源,事件源行为可能会有所不同。本节列出了涉及事件源映射的常见问题,并提供了有关如何发现和解决这些问题的指导。
注意
本节以 Amazon SQS 事件源进行说明,但相关原则适用于为 Lambda 函数对消息进行排队的其他事件源映射。
识别和管理节流
在 Lambda 中,当达到函数或账户的并发限制时,就会发生节流。考虑以下示例,有一个 Lambda 函数从某个 Amazon SQS 队列中读取消息。此 Lambda 函数模拟 30 秒的调用,批次大小为 1。这意味着该函数每 30 秒仅处理 1 条消息:
const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))
exports.handler = async (event) => {
await doWork(30000)
}
由于调用时间如此之长,消息开始进入队列的速度要快于系统处理它们的速度。如果账户的未预留并发数为 100,则 Lambda 最多可扩展到 100 个并发执行,然后就会发生节流。您可以在该函数的 CloudWatch 指标中看到此模式:

该函数的 CloudWatch 指标未显示任何错误,但并发执行图表显示已达到最大并发数 100。因此,限制图表显示了已设置的节流。
您可以使用 CloudWatch 警报检测节流,并设置在函数的节流指标大于 0 时发出警报。发现节流问题后,可以选择以下几种解决方法:
-
向此区域的 Amazon Support 请求增加并发。
-
确定函数中的性能问题,以提高处理速度,从而提高吞吐量。
-
增加函数的批次大小,以便每次调用都能处理更多消息。
处理函数中的错误
如果处理函数引发错误,则 Lambda 会将消息返回到 SQS 队列。Lambda 可防止您的函数扩展,从而防止大规模出现错误。CloudWatch 中的以下 SQS 指标表明队列处理存在问题:

特别是,最早消息的期限和可见消息的数量都在增加,但没有消息被删除。队列继续增长,但没有处理消息。处理 Lambda 函数的 CloudWatch 指标也表明存在问题:

错误计数指标不为零且不断增长,而并发执行次数减少了,且节流已停止。这表明由于错误,Lambda 已停止纵向扩展函数。该函数的 CloudWatch 日志提供了错误类型的详细信息。
您可以通过识别导致错误的函数,然后找到并解决错误,以解决此问题。修复错误并部署新函数代码之后,CloudWatch 指标应显示处理的恢复情况:

在这里,错误计数指标降为零,成功率指标恢复为 100%。Lambda 再次开始纵向扩展函数,如并发执行图中所示。
识别和处理反向压力
如果事件产生器为 SQS 队列生成消息的速度始终高于 Lambda 函数处理消息的速度,则会出现反向压力。在这种情况下,SQS 监控应显示最早消息的期限线性增长,以及可见消息的大致数量。您可以使用 CloudWatch 警报检测队列中的反向压力。
解决反向压力的步骤取决于您的工作负载。如果主要目标是通过 Lambda 函数提升处理能力和吞吐量,您有以下几种选择:
-
向 Amazon Support 请求增加特定区域的并发。
-
增加函数的批次大小,以便每次调用都能处理更多消息。