AWS Lambda 日志实战：系统日志解读、JSON 结构化与成本控制

Lambda 排障需要把同次调用的日志、耗时和内存使用对应起来。本文介绍系统日志、JSON 格式与保留策略，并说明通过 DataKit 扩展将日志接入观测云的步骤。

核心要点速览

• 每次调用产生三条系统日志：START（开始）、END（结束）、REPORT（耗时/内存/计费摘要）——REPORT 是性能与成本分析的金矿。
• 日志组按函数命名：/aws/lambda/<函数名>，组内日志流按执行环境实例划分。
• JSON 结构化日志可一键开启：函数配置的 Log format 设为 JSON，系统与自定义日志全部结构化。
• CloudWatch 成本可优化：外送第三方平台后可收紧 CloudWatch 写入与保留。

1. 解读 Lambda 系统日志

INIT_START Runtime Version: nodejs:22.v24 ...
START RequestId: 765b52b4-... Version: $LATEST
END RequestId: 765b52b4-...
REPORT RequestId: 765b52b4-... Duration: 259.72 ms Billed Duration: 260 ms
       Memory Size: 128 MB Max Memory Used: 69 MB Init Duration: 189.15 ms

• INIT_START：冷启动初始化（新执行环境才有），含运行时版本与 Init Duration——冷启动耗时优化的依据；
• START/END：调用的开始与结束，RequestId 串联该次调用的所有日志；
• REPORT：Duration（实际执行）、Billed Duration（计费时长）、Memory Size（分配）vs Max Memory Used（实际峰值）——Memory 长期远低于分配值说明可以降配省钱。

2. 日志组与日志流结构

日志自动写入 CloudWatch 日志组 /aws/lambda/<函数名>；组内每个执行环境实例一个日志流（YYYY/MM/DD/[版本]<实例ID>）。冷启动产生新流，热复用期间写同一流——同一个 RequestId 的所有日志在同一流内，按 RequestId 过滤即还原单次调用。

3. 开启 JSON 结构化日志

函数配置 → 监控与操作工具 → 日志格式（Log format）设为 JSON：

{
  "time": "2026-08-25T14:55:35.345Z",
  "type": "platform.report",
  "record": {
    "requestId": "88c76e69-...",
    "metrics": {"durationMs": 2226.333, "billedDurationMs": 2227, "memorySizeMB": 128, "maxMemoryUsedMB": 88},
    "status": "success"
  }
}

系统日志与应用日志统一 JSON 化；应用中 console.log 输出合法 JSON 对象时会被自动解析进 message 字段。这是 Lambda 日志可机器分析的关键一步。

4. 用 Lambda Layer 统一日志配置

团队内多个函数共享日志格式？把日志库配置打进 Lambda Layer：

pino-layer/
└── nodejs/
    └── index.js    # 导出配置好的 logger

函数里 import { logger } from '/opt/nodejs/index.js' 即用——所有函数日志格式一致，平台侧解析规则一份就够。

5. 成本治理

• 函数日志保留期默认永久——按日志组改 7-30 天；
• 高频函数日志量惊人：应用侧控制级别，平台侧评估是否全量保留；
• 外送前后分别统计 CloudWatch、转发链路和接收端的费用；确认查询、重试与保留要求后，再调整 CloudWatch 保留期。

6. 将 Lambda 日志接入观测云

需要跨函数查询时，可使用官方 AWS Lambda 扩展 采集指标和日志。该集成标为 Experimental，先在测试函数验证：

1. 按函数架构选择扩展包，创建 DataKit Layer 并添加到函数。
2. 配置 ENV_DATAWAY，指向工作空间对应的接收地址，限制 Token 的访问权限。
3. 执行一次成功调用和一次可控失败调用，核对函数名、时间、日志及耗时字段是否到达；不要把 CloudWatch JSON 字段名直接当作接入后的字段名。
4. 用实际收到的字段筛选失败调用，再配置告警并验证通知。确认采集可靠后，才调整原有日志保留策略。

常见问题（FAQ）

REPORT 里的 Init Duration 是什么？

冷启动初始化耗时（运行环境创建 + 代码初始化）。只在新执行环境的首次调用出现。持续偏高说明初始化代码重或包太大——优化依赖体积、考虑预置并发（Provisioned Concurrency）。

日志里找得到超时的调用吗？

应按 RequestId 检查同次调用的超时信息和平台状态；只有缺少 END 不能单独证明超时，也可能是日志尚未到达。接入观测云后，先核对实际收到的错误和超时字段，再设置查询条件。

函数并发很高时日志流怎么对应？

每个并发执行环境一个流。排障不用关心流——按 RequestId 或时间窗过滤，平台自动跨流检索。

可以不写 CloudWatch 直接外送吗？

可评估扩展采集路径，但不要在验证前移除原有日志通道。应先测试失败调用、网络中断和函数结束时的日志到达情况，再决定是否调整 CloudWatch 写入权限与保留策略。

系列阅读

• 上一篇：AWS 日志体系入门
• 下一篇：CloudTrail 日志实战
• 相关阅读：Vercel 日志实战 ｜ 降低日志成本七步法