AWS Lambda超时

Question

我遇到了AWS Lambda函数的意外超时问题。该功能每天被调用约700万次-每5分钟发生一次固定的调用。我看到的峰值通常是半小时内〜1,000个功能超时。一天的其余时间通常没有超时。

这是一个示例示例，其中超时沿y轴计数。

该功能的超时设置为30秒。对于大输入，该函数的平均运行时间约为50毫秒，预期的最大运行时间约为5秒。该函数使用Python3.6运行时，而不使用ENI / VPC Lambda功能，因此冷启动通常只需要几秒钟。

为了调查超时，我在发生超时时浏览了CloudWatch日志。没有日志消息，也没有来自超时调用的异常，只有消息：Task timed out after 30.03 seconds。

该函数最初在单个线程中运行，所以我认为代码可能挂在某个地方并且无法记录。我试图通过修改功能来向日志添加更多信息，如下所示：

def business_logic():
    ...
    queue.put(result)

def lambda_handler(event, context):
    thread = threading.Thread(target=business_logic)
    thead.start()

    while queue.empty():
        if seconds_running > 10:
            comprehensive_logging()

我通过在business_logic中添加睡眠并确认该功能确实comprehensive_logging来测试了此功能是否正常。但是，在实际超时期间，{strong>从未达到comprehensive_logging 。

从该实验中，我得出结论，超时的Lambda调用从未到达我的代码。由于超时的尖峰特性，我怀疑运行我的功能的Lambda microVM之一进入了不良状态，无法在请求被回收之前的一段时间内处理。

问题：

• 这种理论是否成立？
• 还有其他可能被我忽略的原因吗？
• 有人经历过类似的经历吗？

其他详细信息：

• 使用SigV4签名的请求直接调用功能
• 我使用Chalice库来处理请求。
• 在每次通过SWIG执行时，Python都会与一些大的二进制文件进行交互
• 该功能不与任何外部资源交互

注意：由于CloudWatch的成本，我不愿意为所有呼叫添加全面的日志记录。

Answer 1

您是否考虑过更改该功能的超时设置？ 30可能是默认值，而chalice是默认值。但是，如果超出该范围，那么您将不会真正获得日志记录，因为在此之前该日志记录将被终止。我将超时设置为几分钟，然后查看长时间运行的功能的日志以查看是否可以确定问题所在。您不会在图形上看到超时，因为只有在终止时才会发生超时。但是Lambda会记录执行时间，因此您应该能够基于执行时间进行过滤。

即使您超时，如果该功能正常完成得更快，您仍将只为使用的东西付费。

该函数调用什么？外部HTTP API？ AWS服务？

此外，您可能希望查看AWS X-Ray SDK进行调试，它可能使您对失败的Lambda执行有更多了解。