AWS Lambda仅修改重部署后才输出CloudWatch日志问题排查

场景回顾 #

使用3个AWS Lambda函数：

• 第一个由API Gateway触发
• 第二个、第三个分别由SQS FIFO队列（queue1、queue2）触发，每个FIFO队列对应独立的FIFO死信队列（DLQ）

流程表现：API Gateway触发第一个Lambda后，消息能在队列中正常流转（queue1消息进入飞行状态，超重试/可见性超时后进入DLQ），但CloudWatch无日志输出。已尝试：

• 确认IAM角色附加了AWSLambdaBasicExecutionRole
• 调整Lambda超时时间
• 上述操作后，仅部署后首次执行能生成日志，后续触发均无日志

共用的IAM角色包含两个自定义内联策略（示例）：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "sqs:ReceiveMessage",
                "sqs:SendMessage",
                "sqs:GetQueueAttributes"
            ],
            "Resource": "arn:aws:sqs:<rest-of-the-arn>.fifo"
        }
    ]
}

可能的原因及排查方向 #

1. Lambda执行环境复用导致日志客户端异常 #

Lambda会复用热启动的执行环境，若代码中自定义了日志逻辑（如第三方日志库Winston、Bunyan），可能存在以下问题：

• 冷启动时初始化的日志客户端在热启动时连接断开，未自动重连
• 日志缓冲未在Lambda执行结束时强制刷新，导致热启动时缓冲日志丢失
• 排查：检查代码中日志初始化逻辑，确保热启动时能重新初始化日志客户端，或在函数执行结束时显式调用日志flush方法（如logger.end()）

2. CloudWatch日志流的资源限制或状态异常 #

首次执行会创建新的日志流，后续复用日志流时可能遇到：

• 日志流达到CloudWatch的写入TPS限制（单日志流默认最大1000条/秒），若Lambda批量处理消息且日志输出密集，可能被限流
• 日志流因权限变更、资源锁定等原因变为不可写状态
• 排查：查看CloudWatch日志组的指标（如IncomingLogEvents、ThrottledLogEvents），确认是否存在限流；手动创建新的日志流测试是否能写入

3. IAM角色的日志权限存在隐性限制 #

虽然AWSLambdaBasicExecutionRole允许日志写入，但可能存在以下冲突：

• 自定义内联策略中的Deny语句（未在示例中体现）覆盖了日志权限
• 角色的信任关系存在条件限制，仅允许首次触发的会话获取日志权限
• 排查：检查IAM角色的所有策略（包括托管和自定义），确保无Deny日志相关操作的语句；验证角色的信任策略是否允许Lambda服务长期获取凭证

4. SQS FIFO触发的批量处理逻辑导致日志吞没 #

SQS FIFO触发的Lambda默认启用批量处理，若代码中存在：

• 批量处理时仅在全部消息处理完成后输出日志，但若中途出现未捕获的异常（未终止函数），导致日志未输出
• 批量消息处理的日志被缓冲在内存中，未及时写入CloudWatch
• 排查：在批量处理的每个消息逻辑中添加独立日志输出，测试是否能正常写入；关闭批量处理（设置批量大小为1）验证日志是否恢复正常

5. Lambda日志配置的动态冲突 #

若Lambda使用了动态日志组名称（如包含FIFO队列的动态参数），可能存在：

• 热启动时日志组名称解析错误，导致写入不存在的日志组
• 日志组的权限未覆盖所有可能的动态名称
• 排查：检查Lambda的日志配置，确认日志组名称固定；查看CloudWatch是否存在未预期的日志组

内容的提问来源于stack exchange，提问作者Arturo Avila