请求排查：AWS Lambda函数无CloudWatch日志及调用记录异常

先理清楚你的场景：同一个CloudWatch Events Rule调度新旧两个Lambda函数，旧的运行一切正常，但新函数的监控图表看起来像在执行，可「Recent Invocations」里没数据，点CloudWatch日志链接提示日志组不存在，手动测试也没生成任何日志——哪怕你给两个函数共用的IAM角色加了CloudWatchFullAccess权限也没解决。

下面是几个核心的排查方向，按优先级来：

1. 先确认函数到底有没有被真正触发 #

监控页面的图表有时候会“误导人”——它可能显示的是CloudWatch Rule的触发次数，而非Lambda函数实际执行的次数。你可以：

• 跳转到CloudWatch Events的Rule页面，查看触发历史（Trigger History），看每个触发请求的状态码和详情。如果状态是Failed，那大概率是函数在执行前就被拒绝了，根本没机会生成日志。
• 检查Lambda函数的并发限制：如果你的账号或者这个函数的并发配额被耗尽，新的调用会直接被丢弃，自然也不会留下日志痕迹。

2. 日志组不存在的核心原因：函数从未成功完成初始化 #

Lambda默认会在函数**第一次成功执行（哪怕只是部分执行）**后自动创建/aws/lambda/MyFunctionName日志组。如果日志组压根不存在，说明你的函数可能在初始化阶段就崩溃了，连日志的写入流程都没走到。这种情况常见于：

• 代码有语法错误（比如Python缩进错了、Node.js依赖的模块没打包进去），导致初始化直接失败。
• 内存配置太低，初始化时内存不足被系统Kill。
• 超时时间设置太短，还没完成初始化就超时了。
• 环境变量配置错误（比如依赖的密钥、服务端点填错了），导致初始化报错。

3. 再仔细核对IAM角色的配置 #

虽然你给角色加了CloudWatchFullAccess，但有两个细节容易被忽略：

• 信任策略是否正确：角色必须允许Lambda服务来扮演它，信任策略里得包含这段配置：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "lambda.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }
  

  如果信任策略不对，Lambda根本没法用这个角色执行，自然不会生成日志。
• 权限是否生效：有时候添加权限后需要等几分钟让IAM同步，或者你可以尝试把角色从函数上解绑再重新关联一次。

4. 手动测试的细节排查 #

你说手动点Test按钮也没日志，这说明问题大概率出在函数本身或者基础配置上：

• 检查Test事件的格式是否符合函数预期？比如函数需要特定结构的输入，你用了默认的Hello World事件，可能导致函数报错，但哪怕报错也应该生成日志——除非初始化就失败了。
• 查看Lambda监控页面的Invocation Errors指标，如果有错误计数，说明函数执行出错，但日志没生成的话还是回到「初始化失败」的问题上。
• 尝试简化代码：写一个最简单的Hello World函数替换现有代码，再手动测试。如果这个测试能生成日志，那肯定是原代码有问题（比如依赖缺失、逻辑错误）。

5. 检查CloudWatch Events Rule的目标配置 #

确认Rule的目标是否正确指向了新函数的ARN：

• 有时候复制Rule或者创建新目标时，可能选错了函数，或者ARN写错了（比如区域不对、函数名拼写错误）。
• 检查目标的启用状态是否为开启，如果目标被禁用了，函数根本不会被触发。

6. 最后确认区域是否一致 #

一定要确认你查看CloudWatch日志的区域，和Lambda函数所在的区域是同一个！很多人会因为选错区域，导致找不到日志组。

我之前遇到过类似的情况：函数代码里的Python依赖包没正确打包到部署包，导致Lambda初始化时找不到模块，直接崩溃，日志组根本没创建。后来把依赖包用Lambda Layer打包，问题就解决了。

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