AWS Lambda执行持续时间随机激增并导致超时

Question

我正在构建一个无服务器的网络跟踪系统，该系统使用AWS API网关为其跟踪像素提供服务，每当跟踪请求到达时将其调用Lambda函数将跟踪事件写入Kinesis流。

Lambda函数本身并没有做任何花哨的事情。它只接受传入事件（它自己的参数）并将其写入流。基本上，它只是：

import boto3
kinesis_client = boto3.client("kinesis")

kinesis_stream = "my_stream_name"

def return_tracking_pixel(event, context):
    ...
    new_record = ...(event)
    kinesis_client.put_record(
        StreamName=kinesis_stream,
        Data=new_record,
        PartitionKey=...
    )
    return ...

有时我在Lambda执行持续时间中遇到一个奇怪的峰值，导致我的一些Lambda函数调用超时并且跟踪请求丢失。

这是受影响时间段内Lambda函数1分钟调用计数的图表：

在20:50到23:10之间，我突然看到很多调用错误（1分钟错误计数）：

显然是由Lambda执行超时（以1分钟为间隔的最长持续时间）引起的：

我的Kinesis流（数据输入，放置记录数，put_record成功计数等，一切看起来都正常）和我的API GW（调用次数对应于API GW的数量）都没有什么奇怪的结果呼叫，完全在API GW的范围内。）

什么可能导致Lambda函数执行持续时间突然（并且看似随机发生）的峰值？

编辑：lambda函数都没有受到限制，这是我的第一个想法。

Answer 1

只需加上我的2美分，因为没有额外的日志记录或X射线分析就没有太多的调查工作。

AWS Lambda有时会强制回收容器，使它们感觉像冷启动一样，即使您的功能得到了合理的锻炼和预热。这可能会带来所有与冷启动相关的问题，例如，如果您的Lambda连接了VPC，则ENI会额外延迟等等。但是，即使对于像您这样的简单功能，对于冷启动来说1秒钟的超时有时也过于乐观。 >

我不知道有关这些强制回收的任何文件，只有一些人对此有证据。

  

“我们每天大约要强制回收7次。” source

     

“看起来，即使是预热的，高并发函数也比仅有少量内存的函数要快得多地被回收。” source

我想知道如何确认这种情况。也许您可以检查Cloud Watch日志流中出现的那些错误，是由于以前从未出现过的容器引起的。