Amazon SOA-C02: 监控、日志与修复 — 学习指南

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

监控、日志记录和修复构成了 AWS 环境的运营神经系统：它们负责检测问题、提供上下文并驱动纠正措施。本领域涵盖创建有意义的指标和控制面板、经济高效地收集和保留日志、构建可追踪的应用程序可观测性，以及实现警报和修复的自动化。好的实施方案应平衡信噪比、控制成本，并确保操作手册和自动化经过测试且可审计。

CloudWatch 指标、控制面板和警报

围绕业务和运营 SLI（延迟、错误率、队列深度、基础设施的 CPU/内存）设计指标。使用内置指标（EC2、RDS、ELB）以及通过 PutMetricData 提供的自定义指标，用于应用程序级别的计数器（

undefined

）。优先选择可用于筛选的维度（InstanceId、ServiceName），并避免使用会激增指标成本的高基数维度。

使用 CloudWatch 控制面板将指标、日志和警报组合成运营视图。在控制台中或通过 CloudFormation（AWS::CloudWatch::Dashboard）创建小组件，并利用指标数学计算派生指标：使用指标数学计算错误率（ERRORS/SUM(REQUESTS)）并显示百分位数（p50、p90、p99）。对于警报，根据意图选择配置模式：

• 用于简单阈值的单一度量警报：

undefined

• 复合警报，通过组合多个警报的条件（AND/OR）来减少噪音。
• 异常检测，用于自动调整阈值：对具有预期季节性行为的指标使用 CloudWatch 异常检测。

决策标准：使用评估周期和“数据点到警报”设置来避免警报抖动；将 SNS、Auto Scaling 或 Systems Manager Automation 作为警报操作触发。对于基线可变的环境，优先使用复合警报和异常检测。

CloudWatch Logs、Logs Insights 和保留策略

使用 CloudWatch Logs 日志组聚合日志，并按应用程序和环境对其进行结构化。通过 CLI 创建日志组：

undefined

，并使用

undefined

强制执行保留策略。使用订阅筛选器将日志流式传输到 Kinesis Data Firehose（用于 S3/Redshift）、Lambda（用于实时处理）或合作伙伴工具；在 S3 中进行压缩和分区以降低存储成本。

使用 CloudWatch Logs Insights 进行即席查询和构建控制面板；构建可提取跟踪 ID 和错误上下文的已保存查询（例如，

undefined

）。保留和摄取成本控制实践：

• 根据合规性和故障排查需求，为每个日志组设置适当的保留期（7/30/90/365 天）。
• 通过保留生命周期或 Firehose 将较旧的日志导出到 S3，并使用压缩和生命周期规则将其归档到 Glacier/Archive。
• 使用采样或结构化日志（JSON）和嵌入式指标格式（EMF）来减少昂贵的高基数日志，同时仍能派生指标。

决策标准：为详细的调试日志设置较短的保留期，为审计/安全日志设置较长的保留期；将高容量日志路由到 S3，而不是在 CloudWatch 中无限期保留。

CloudTrail、审计跟踪和事件历史

在所有区域和账户中启用 CloudTrail；创建组织跟踪以实现集中式审计日志记录，并将其保存到安全的 S3 存储桶中，同时启用日志文件验证和 SSE-KMS 加密。配置管理事件（读/写），并有选择地启用数据事件（S3 对象级别、Lambda 函数调用），仅在需要详细审计的场景下开启，因为数据事件的量更大且成本更高。

使用控制台中的 CloudTrail 事件历史进行 90 天的快速搜索，并使用 CloudTrail Lake 或基于导出的 S3 日志的 Athena 进行长期分析和调查。通过以下方式保护跟踪：

• 强制实施多区域跟踪以捕获全球服务事件。
• 将 CloudTrail 与 CloudWatch Logs 集成以进行近实时检测，或与 EventBridge 集成以将特定事件路由到 Lambda/Systems Manager 进行自动化修复。
• 应用 S3 存储桶策略和 S3 对象锁定（如果需要）以防止篡改。

决策标准：仅在需要取证可见性的存储桶/函数上启用数据事件；使用集中式跟踪和跨账户访问模式来简化合规性。

应用程序跟踪与可观测性 (X-Ray)

使用 AWS X-Ray SDK 检测应用程序以发出分段和子分段。对于未检测的运行时，将 X-Ray 守护进程/代理作为 sidecar 或服务（ECS 任务、EC2 守护进程或 Lambda 内置跟踪）运行。配置采样规则以控制跟踪量，并在 ServiceLens 中设置服务地图以可视化服务间的依赖关系。使用业务键（userId、orderId）为跟踪添加注释，并记录异常/元数据以帮助分类。

通过在应用程序日志中包含 X-Ray 跟踪 ID（使用跟踪标头或 SDK 获取当前跟踪 ID），将跟踪与日志关联起来，这样 CloudWatch Logs Insights 查询就可以连接日志和跟踪。对于 Lambda，启用主动跟踪（在控制台或通过

undefined

）以自动将跟踪发送到 X-Ray。使用跟踪分析来检测长尾延迟、热点和数据库调用分解。

决策标准：为关键服务启用跟踪，并使用自适应采样来限制成本；优先选择结构化跟踪（注释/元数据），使日志+跟踪的关联具有确定性。

自动化修复与告警 (EventBridge/Lambda)

使用 EventBridge 规则来匹配 CloudWatch Alarm 状态变更、CloudTrail 事件或自定义事件，并将它们路由到 Lambda、Systems Manager Automation 文档、Step Functions 或 SNS 等目标。创建带有输入转换器的规则，以便向修复操作传递最小化的上下文 (aws events put-rule –name HighErrorRule –event-pattern ‘{“source”:[“aws.cloudwatch”],…}’)。对于轻量级修复（重启服务、撤销凭证），可以实施 Lambda 函数；但对于带有检查点的、可审计的、长时间运行的剧本，应使用 SSM Automation 或 Step Functions。

安全地设计修复措施：包括演练模式、幂等性、验证步骤、IAM 最小权限、日志记录和一个紧急停止开关。在 EventBridge/Lambda 集成上使用死信队列和重试策略，并将修复尝试发布到审计日志或安全轨迹中。在预生产账户中测试自动化，并在部署后运行金丝雀测试。

决策标准：对于多步骤恢复和需要人工审批的场景，优先选择 SSM Automation 或 Step Functions；对于简单、快速的修复，使用 Lambda。对于有风险的操作，务必包含手动回滚或人工介入的断点。

常见陷阱与决策标准

• 依赖单一指标做健康决策：组合多个指标（例如，错误率 + 延迟 + 节流）或使用复合告警/指标数学来避免误报。
• 未考虑日志保留和摄入成本：按日志组设置保留期，通过 Firehose 将批量日志压缩后路由到 S3，并使用生命周期策略将旧数据迁移到更便宜的存储层。
• 使用高基数维度或禁用追踪采样导致过度检测：限制维度并启用自适应采样，以便在保留有效信号的同时控制成本。
• 未经测试就部署自动化修复：在预生产环境中验证，使用演练标志，并在生产激活前确保幂等性和安全回滚。
• 因告警噪音导致的告警疲劳：使用异常检测、复合告警、抑制窗口，并且仅将有意义的事件上报给值班人员。
• 日志、指标和追踪之间缺乏关联：将追踪 ID 传播到日志和 EMF 指标中，并构建已保存的 Logs Insights 查询和 ServiceLens 视图以将数据关联起来。

实践问题：用例场景

Acme Payments 在流量高峰期会经历间歇性的支付处理失败；工程师观察到延迟增加和零星的 5xx 错误，但自动化重启有时会掩盖根本原因。

1. 使用 X-Ray SDK 和 EMF 指标来检测支付服务；将追踪 ID 添加到应用程序日志中，并通过 PutMetricData/EMF 发送结构化指标 OrdersFailed 和 OrdersProcessed。
2. 创建 CloudWatch 指标数学来计算错误率 (OrdersFailed / OrdersProcessed)，并创建一个复合告警，该告警结合了“错误率 > 阈值”和“p99 延迟 > 阈值”两个条件。
3. 将告警操作路由到一个 EventBridge 规则，该规则触发一个 Step Functions 工作流以执行诊断步骤（收集最近的追踪/日志、运行健康检查），并在安全的情况下，通过 SSM Automation 执行自动化重启。
4. 配置 CloudTrail 和 CloudWatch Logs 订阅，将完整日志（压缩后）归档到 S3，并设置生命周期策略迁移到 Glacier；同时为详细的调试日志在 CloudWatch 中设置较短的保留期。
5. 运行端到端测试和金丝雀综合事务 (CloudWatch Synthetics)，在生产环境中启用自动修复之前，验证可观测性和修复流程。

基本原理：关联指标、日志和追踪来定位根本原因，而不是反复处理表面症状；组合告警以减少噪音，并使用可审计、经过测试的自动化（Step Functions/SSM）进行安全修复，同时控制日志存储成本。

所有领域 · 高可用性、容错与灾难恢复 →

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

浏览 Amazon →