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

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

本文示例针对 Lambda Event Functions。Lambda Managed Instances 只支持 JSON 日志，执行模型也不同，不能直接套用下面的文本格式示例。日志格式说明。

核心要点速览

• 常规文本格式调用通常包含三类系统日志，实际还受格式、级别和失败路径影响：START（开始）、END（结束）、REPORT（耗时/内存/计费摘要）——REPORT 是性能与成本分析的金矿。
• 日志组按函数命名：/aws/lambda/<函数名>，组内日志流按执行环境实例划分。
• JSON 结构化日志可一键开启：函数配置的 Log format 设为 JSON，系统日志及受支持运行时日志 API 可结构化，任意 stdout 输出不保证自动转换。
• 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: 449 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（实际峰值）——内存低占用可作为降配测试线索，但 CPU 随内存配置变化，需实测耗时和费用；Max Memory Used 还可能反映同一执行环境多次调用的峰值。

2. 日志组与日志流结构

具备写入权限时日志写入默认 CloudWatch 日志组 /aws/lambda/<函数名>，也可配置自定义日志组；组内每个执行环境实例一个日志流（YYYY/MM/DD/[版本]<实例ID>）。环境复用期间继续写入相应日志流。查询单次调用时，应选对日志组与时间窗，并按 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"
  }
}

系统日志与受支持运行时日志 API 可输出 JSON；Node.js console 对象参数与已结构化日志的处理不同，任意 stdout 写入不保证转换为同一结构，应检查真实样本。这是 Lambda 日志可机器分析的关键一步。

4. 用 Lambda Layer 统一日志配置

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

pino-layer/
└── nodejs/
    ├── index.mjs    # ESM：导出配置好的 logger
    └── node_modules/  # 同时打包所需日志库及依赖

函数里可用 import { logger } from '/opt/nodejs/index.mjs' 引入；依赖包需匹配运行时、Linux 环境与函数架构。只有实际使用该 logger 且配置兼容的输出才会统一，挂载 Layer 不会自动改写所有日志，发布新 Layer 版本也不会自动更新所有函数。

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 是什么？

报告中记录的初始化耗时。按需冷启动常在 REPORT 中报告；预置并发、SnapStart、失败和 suppressed init 的报告方式不同，不能据此断言只在首次调用可见。持续偏高时，可检查初始化代码与依赖；考虑预置并发（Provisioned Concurrency）时也要评估额外费用。

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

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

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

不同执行环境通常对应不同日志流。排障时选对日志组与时间窗，再使用支持跨流的查询按 RequestId 筛选；未带该标识或写入其他目的地的日志不会自动补齐。

可以不写 CloudWatch 直接外送吗？

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

系列阅读

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