Serverless 监控和调试怎么做？实战方案详解

Serverless 的监控比传统应用难得多——函数生命周期短，日志转瞬即逝，一次请求可能跨越十几个函数，调用链路像黑盒。传统 APM 工具虽然支持 Serverless，但配置复杂，且按函数收费的定价模式在大量函数场景下很贵。

先搞清楚要监控什么：冷启动频率和耗时、函数执行时间、错误率和错误类型、并发数和限流情况、调用链路和依赖关系。这五项覆盖了 Serverless 最核心的可观测性需求。

日志：结构化是前提

Serverless 函数的日志不是写在本地文件上的，而是打到 CloudWatch / 日志服务。如果还是 print("something happened") 这种格式，在几千条日志里找到你要的那条无异于大海捞针。

必须做两件事：

• JSON 格式输出：每条日志包含 trace_id、function_name、timestamp、level、message，方便用 CloudWatch Insights 或 Loki 过滤查询
• 请求级 trace ID：在 API Gateway 层生成，一路透传到下游所有函数，这样可以用一条查询把整个请求链路的日志串起来

分布式追踪：看清调用链路

一个 API 请求从 API Gateway → Lambda A → SQS → Lambda B → DynamoDB，光看日志拼不出完整链路。分布式追踪就是解决这个问题的。

AWS X-Ray 是最直接的选择——和 Lambda 原生集成，开启即可用，但功能有限。OpenTelemetry 更灵活，支持多后端（Jaeger、Zipkin、Datadog），适合多云或混合架构。关键配置点：

• 确保所有函数都开启 tracing
• 在函数间传递 trace context（W3C Trace Context 标准的 traceparent header）
• 设置合理的采样率——全量追踪成本高，1% 采样又可能漏掉关键错误

本地调试：模拟环境还是直接上云？

本地跑 Serverless 函数有两种思路：

模拟派：用 SAM CLI 的 sam local invoke 或 Serverless Framework 的 offline 插件，在本地模拟 API Gateway、DynamoDB 等服务。好处是快，坏处是模拟环境总跟线上有差异——IAM 策略、VPC 配置、环境变量都可能不一样。

直接上云派：写完代码直接部署到 dev 环境，用真实云服务测试。好处是环境一致，坏处是部署慢、费钱。

实际项目中两者结合：单元测试本地跑，集成测试部署到 dev 环境。别花太多时间折腾本地模拟——线上环境的差异问题，本地模拟永远解决不了。

错误处理和告警

Serverless 函数报错后实例就被回收了，现场信息不会保留。所以错误处理必须做到两点：

捕获所有异常：在函数入口包一层 try-catch，把错误信息连同上下文（请求参数、环境变量、调用栈）写入日志和错误追踪服务（Sentry、Rollbar）。裸奔的 Lambda 一旦崩溃，你连它为什么崩溃都不知道。

设置合理的告警：CloudWatch Alarm 按 Lambda 的 ErrorRate 和 Duration 设阈值，错误率超过 5% 或 P99 延迟超过 2 秒就触发告警。别等到用户投诉才发现问题。