Amazon DVA-C02: 监控、日志记录与调试 (CloudWatch, X‑Ray, Tracing, Alarms) — 学习指南

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

属于 AWS Developer Associate DVA-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

CloudWatch Logs、指标和日志指标筛选器

CloudWatch Logs 是应用程序和平台遥测数据的主要管道；开发者应将日志设计为结构化格式（JSON），以便 Metrics 和 Insights 能够可靠地解析它们。对于自定义应用程序指标，优先选择 CloudWatch Embedded Metric Format (EMF) 或 PutMetricData，以满足即时维度和高分辨率的需求；EMF 在日志行中嵌入 _aws JSON，允许 CloudWatch 在单次 PutLogEvents 调用中提取多个指标，从而提高成本和吞吐量效率。当需要从服务端的文本日志中派生指标时，可以针对日志组创建指标筛选器（PutMetricFilter），将筛选模式映射到 MetricTransformations；这些筛选器会生成可用于绘图和告警的 CloudWatch 指标。常见的操作 API 包括 CreateLogGroup、CreateLogStream 和 PutLogEvents（注意 sequenceToken 和 PutLogEvents 的批处理大小限制），以及用于将客户管理的 KMS 密钥附加到日志组以实现静态加密的 AssociateKmsKey。注意 IAM：PutLogEvents 和 PutMetricData 需要显式权限，并且 KMS 授权必须允许服务主体使用密钥进行加密。使用保留策略来控制成本，并且仅在需要亚分钟级可见性时才选择高分辨率指标（使用 StorageResolution=1 的 PutMetricData）。

分布式系统的追踪与 X-Ray

分布式追踪通过检测跨服务的请求流来揭示延迟和错误发生的位置；AWS X-Ray 是集成的选项。在 Lambda 函数上启用主动追踪（Lambda TracingConfig Mode: Active），并为 API Gateway 阶段启用 X-Ray 以传播 X-Ray 追踪标头。在您的运行时中使用 AWS X-Ray SDK（Node.js 使用 aws-xray-sdk-core，Python 使用 aws_xray_sdk，Java 使用 AWSXRayRecorder）来创建子分段（subsegments）、添加注解（annotations，已索引的小值）和元数据（metadata，未索引的较大对象）。通过使用 X-Ray 记录器包装 AWS SDK 客户端来捕获下游 SDK 调用，这样 SDK 就会自动检测对 S3、DynamoDB 的请求以及 HTTP 调用。对于容器化工作负载，将 X-Ray 守护进程作为 sidecar 运行或使用守护进程层；它接受 UDP 数据包（默认端口 2000）并将其批量发送到 X-Ray 服务。配置采样规则（CreateSamplingRule）以避免噪音，但对于您希望始终追踪的关键流程，可以调整规则或使用 SDK 覆盖。注意分段文档的大小限制，切勿将个人身份信息（PII）放入注解中，因为它们会被索引并可供搜索。

告警、通知和警报设计

告警应能检测可操作的事件、减少噪音，并与运行手册（runbook）集成。在原生指标、自定义指标（来自 PutMetricData 或指标筛选器）或指标数学表达式上使用 CloudWatch Alarms；调整 DatapointsToAlarm 和 EvaluationPeriods 以避免告警抖动（flapping），并优先使用复合告警来处理多信号条件（如下游中断 + 错误率增加），以减少告警量。告警操作可以发布到 SNS 主题以用于人工/自动化工作流，调用 Auto Scaling 或 Systems Manager OpsCenter（创建 OpsItems），或通过 EventBridge 规则路由以实现复杂的 playbook（来源：aws.cloudwatch）。对于快速的待命（on-call）需求，使用 SNS -> HTTP 端点或 PagerDuty 集成；对于自动化修复，使用 EventBridge -> Step Functions 或具有最低权限 IAM 的 Lambda。考虑使用异常检测模型对流量进行基线分析，并设置带有滞后（hysteresis）的“正常”（OK）阈值。常见的陷阱包括创建过多的维度化告警（导致监控成本爆炸性增长）、仅依赖单数据点触发器，以及未能保护通知主题（SNS 访问策略）导致告警泄露给非预期的消费者。

故障排查模式与 SDK/API 实践

排查故障时，首先应构建预期与实际的时间线对比，然后关联分析日志、指标和追踪数据。使用 CloudWatch Logs Insights 进行即席查询（例如

undefined

）以发现流量尖峰，然后转向 X-Ray 追踪以获取详细的延迟信息。对于由 Lambda 支持的 API，应检查冷启动、VPC ENI 挂载时间（针对 VPC 中的函数），以及是否配置了 Lambda 目标（destinations）或死信队列（DLQ）来捕获失败的异步调用。要捕获失败的调用，可使用 Lambda Destinations（onFailure 发送到 SNS、SQS 或 EventBridge）或异步调用的 DLQ 来保留负载（payload）。在代码中进行埋点检测时，通过实现带抖动的指数退避算法来处理 API 节流，并通过指标筛选器或 EMF 计数器监控 429 错误。常见陷阱：PutLogEvents 需要正确的序列令牌（sequence token）且必须先调用 CreateLogStream；PutMetricData 可能被节流——应批量发送并发布聚合指标；X-Ray 需要 xray:PutTraceSegments 和 xray:PutTelemetryRecords 权限（托管策略 AWSXRayDaemonWriteAccess）；采样可能会隐藏问题，除非您为低频但关键的流程调整采样规则。

实践问题：用例场景

场景：Acme Retail 公司在 AWS 上运营一个无服务器结账服务，架构为 API Gateway -> Lambda -> DynamoDB。团队使用集中的 CloudWatch Logs 和 X-Ray，但缺少每分钟的设备吞吐量指标，并需要针对 API 延迟尖峰设置可靠的告警，同时避免产生告警噪音。

挑战：捕获每分钟近乎实时的设备/消息计数，确保对慢请求进行端到端追踪，并创建一个低噪音告警，该告警能触发一个自动修复 Lambda 函数并通知待命人员。

推荐方法：

在结账 Lambda 函数中埋点，使用 PutMetricData API 发送一个自定义高分辨率指标，参数为 Namespace=Acme/Checkout、MetricName=DeviceReportsPerMinute、Timestamp=now、Value=1 和 StorageResolution=1；在内存中批量处理这些指标，并每 30 秒刷新一次，以避免 API 节流。
同时，将 EMF JSON 嵌入到 Lambda 日志中以获得更丰富的维度（如 customerId、region），并依靠 CloudWatch Logs 通过 PutLogEvents 和指标筛选器（PutMetricFilter）来提取额外的指标，例如错误计数。
启用 X-Ray 追踪：将 Lambda 的 TracingConfig 模式（Mode）设置为 Active，在 API Gateway 的阶段（stage）上启用 X-Ray，并使用 X-Ray SDK 在对第三方 API 的外部 HTTP 调用周围添加注解（annotations，非 PII）和子分段（subsegments）。
创建一个复合 CloudWatch Alarm，它结合了高第 95 百分位延迟指标（使用指标数学）和 DeviceReportsPerMinute 指标的尖峰；设置 EvaluationPeriods=3、DatapointsToAlarm=2，并将操作（Action）设置为一个 SNS 主题，该主题触发一个待命人员的端点，外加一条调用修复 Lambda 函数（使用最小权限角色）的 EventBridge 规则。

理由：发送高分辨率指标和 EMF 既能提供即时的每分钟计数，又能提供更丰富的维度；X-Ray 能提供延迟的根本原因分析，直至下游调用；复合告警通过要求在告警前满足相关联的条件来减少噪音，并允许通过 EventBridge 实现自动化。

← 安全、IAM、KMS 与密钥管理 (Cognito · 所有领域 · 存储、Amazon S3、CloudFront 与文件系统 (EFS →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →