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

Lambda 日志看似简单——console.log 就进了 CloudWatch——但这种"无感"正是成本失控与排障困难的根源。本文讲透 Lambda 日志的结构、JSON 化配置与成本治理，并给出观测云平台落地方案。

核心要点速览

• 每次调用产生三条系统日志：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 侧保留，避免双份存储成本。

观测云落地：Lambda 日志接入

1. 外送通道：CloudWatch 日志组配订阅过滤器 → 转发 Lambda/Firehose → 推送观测云 HTTP 接收端；JSON 日志自动解析。
2. 标准化：type 与 record.status 映射标准 status（platform.report 中的 error → error），time 解析为事件时间；service 按函数名打标。
3. 分析：REPORT 日志的 durationMs/maxMemoryUsedMB 字段聚合出耗时分布与内存水位仪表板；慢调用、近内存上限调用一键过滤。
4. 告警：监控器对 ERROR 日志、超时（durationMs 接近 timeout）、内存超限设规则，通知钉钉/企业微信/飞书。
5. 成本控制：REPORT/ERROR 标准索引，INFO 访问流水低频索引，历史归档对象存储。

常见问题（FAQ）

REPORT 里的 Init Duration 是什么？

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

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

超时的调用有 START 但没有正常 END/REPORT（或 REPORT 带 Error）。观测云中用"有 START 无 END"的模式匹配或监控平台错误类日志即可定位。

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

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

可以不写 CloudWatch 直接外送吗？

可以：Lambda 扩展（Extension）经 Telemetry API 在函数进程外接管日志流直发平台，之后可移除函数的 CloudWatch 写权限省掉这笔费用。权衡是链路复杂度增加，中小规模用订阅过滤器即可。

系列阅读

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

---