我们的API网关和Lambdas经常使用,并且在大多数情况下都可以正常工作,但是我们有时会看到5XX错误的峰值,这会导致客户投诉和其他问题的峰值。在这段时间内查看日志时,看到大量以下错误:
Execution failed due to configuration error: Malformed Lambda proxy response
没有其他细节。 10或15分钟后,它将消失并伴随客户投诉。我已经读到,如果您超过并发限制,则可能会发生这种情况,但是从仪表板看,它似乎并没有突破150个并发执行量。
除了5XXs中的随机峰值外,被击中的呼叫本身也始终如一地工作。
还有什么可能导致这种不一致?
仔细查看日志以尝试找出答案。我已将日志尽可能详细,并且没有任何内容。我们将进行一次正常的呼叫,并带有成功的响应,然后在几分钟后,此错误出现了,没有其他日志记录,仅是错误。然后几分钟后,我们开始记录下一个成功的呼叫。
10:25:42 Successfully completed execution
10:25:42 Method completed with status: 200
10:42:01 Execution failed due to configuration error: Malformed Lambda
proxy response
12:21:21 Successfully completed execution
12:21:21 Method completed with status: 200
由于无法执行lambda,因此记录无法继续进行。因此,我们没有发送给它的有效负载或调用的任何内部日志记录等详细信息。它只是在API网关级别立即失败。
编辑:我们仍然会遇到这些尖峰,但我们正在努力进一步分解lambda。我们有一个ExpressJS应用程序,可以处理所有请求中的大部分。因此,我们正在将更多(尤其是高流量请求)分解为自己的lambda,以查看是否有帮助。万一出现一个问题,那就是容器由于处理长时间运行的请求(最多需要20秒)以及被完成时间小于500ms的请求所困扰而导致积压或超时。
其他理论认为,可能是某个错误触发了某个地方,该错误会杀死进程或其他事件,并且该容器是坏的,直到被销毁并重新生成为止。由于这些峰值,然后在几分钟内消失。因此,更多地分解lambda应当减少一次级联并影响所有其他请求的错误几率。
我们还增加了lambda的资源,以查看这是否可以帮助处理大量请求。
答案 0 :(得分:1)
这通常发生在您的通话超时和lambda执行延迟的情况下。
如果要访问RDS或外部网络呼叫之类的外部资源,请使用Promise进行包装,并使用超时进行处理。这样,您可以确定哪个资源存在瓶颈或需要很长时间来执行。
exports.handler = function(event, context, callback) {
var response = {}; // set the response object
var err = "An error occured";
setTimeout(function () {
callback(err, response);
}, 3000); // 3000 ms is the timeout
}
// Actual code here
};
此外,检查是否缺少任何回调。那也会导致这个问题。
希望这会有所帮助。