Amazon DOP-C02: 监控、日志记录和可观测性 — 学习指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

概览

AWS 上的监控、日志记录和可观测性需要将指标、日志、追踪、事件和健康遥测数据组合成可操作的信号。有效的架构会使用 Amazon CloudWatch 进行指标、告警和控制面板的监控；使用 CloudWatch Logs 和 Logs Insights 进行日志摄取和分析；使用 AWS X-Ray 进行分布式追踪；使用 AWS CloudTrail 进行审计和完整性验证；使用 Amazon EventBridge 进行事件驱动的检测和自动化；使用 AWS Health 获取特定于账户的服务事件；并使用集中式管道（Kinesis Data Firehose 和 OpenSearch）进行大规模的搜索和关联。以下模式强调了降噪、精确的信号路由、自动化以及多账户/多区域操作。

CloudWatch 指标、告警、控制面板和复合告警

CloudWatch 指标是 SLO、扩展和告警的基础。发布带有细粒度维度的自定义指标以隔离信号（例如，apiOperation、appVersion、statusCode）。将 CloudWatch 嵌入式指标格式 (EMF) 与结构化日志结合使用，可以高效地从 Lambda、容器和 EC2 发出高基数维度的指标，从而避免 PutMetricData API 的开销。

配置具有稳健评估机制的告警：

选择与数据粒度和 SLO 窗口对齐的周期。
设置 datapointsToAlarm（n 个数据点中的 m 个）以抵御瞬时噪声。
使用 TreatMissingData 来避免在部署或暂停期间出现误报。
当基线随季节性变化时，利用异常检测范围；并使用指标数学计算派生指标（p95 延迟、错误百分比、饱和度比率）。
为告警附加操作：通过 SNS 通知、创建 OpsCenter OpsItems、执行 SSM Automation 或恢复 EC2 实例。扩展策略可以引用告警状态来执行操作，但复合告警不能直接触发扩展。

复合告警通过 AND/OR 逻辑组合多个底层告警，从而减少告警疲劳。例如，仅当 p95 延迟过高、5xx 错误率超过阈值且 CPU 饱和度持续存在时才发出告警，从而与用户受到的实际影响保持一致。复合告警可以通过跨账户可观测性或将指标流式传输到中心账户的方式，接受来自跨区域/跨账户的子告警的状态更新。

控制面板可以跨服务可视化关键指标。使用小组件展示指标、Logs Insights 查询结果和告警状态。标准化控制面板的约定（命名、时间范围、SLO 叠加层），并利用 CloudWatch Observability Access Manager (OAM) 实现跨区域/跨账户视图。为了进行即席关联，可以将 Logs Insights 和 X-Ray ServiceLens 小组件与服务地图小组件和 Kinesis Firehose 错误率并排固定。

CloudWatch Logs：日志组、指标筛选器、订阅筛选器和 Logs Insights

按应用程序/组件和生命周期阶段来组织日志组。设置明确的保留策略（不要依赖“永不过期”），并在需要时启用 KMS 加密。使用资源策略和细粒度的 IAM 来控制生产者和订阅者。对于高吞吐量摄取，请确保足够的日志流并发和批处理能力。

指标筛选器可将日志模式转换为指标。定义一个带有提取令牌（JSON 或空格分隔）的筛选模式，并将令牌映射到指标维度。这支持了诸如按 API、按版本、按响应代码生成指标等用例，这些指标可以直接从日志发布，而无需修改生产者。确保单位和默认值正确；首选每个事件为 1，并通过指标数学派生出速率。使用这些指标进行 SLO 告警和控制面板展示。

订阅筛选器可将日志近乎实时地流式传输到：

Kinesis Data Firehose，用于转换并交付到 S3/OpenSearch。
Kinesis Data Streams，用于自定义消费者。
Lambda，用于自定义路由、PII（个人身份信息）编辑或事件驱动的通知。使用带有 IAM 角色的 CloudWatch Logs 目标来实现跨账户订阅。为重试和背压做好规划；Lambda 和 Firehose 分别提供内置的重试和 DLQ/错误 S3 存储桶。

CloudWatch Logs Insights 提供对日志的交互式、无服务器查询。核心操作符包括 fields、filter、parse、stats、sort、limit、dedup 和用于时间分桶的 bin。可以解析 JSON 字段或对文本日志使用类似 grok 的解析。示例：

undefined

使用 QueryDefinition 保存常用查询以供团队复用，并将它们作为查询小组件嵌入到控制面板中。为了实现自动化，可以通过 EventBridge 调度一个 Lambda 来运行 StartQuery/GetQueryResults，并将摘要发布到 SNS 或 OpsCenter。将查询范围限制在特定的日志组和时间窗口内以控制成本。

使用 Kinesis Data Firehose 和 OpenSearch 实现集中式日志记录

多账户、多区域的日志记录策略可以标准化日志的摄取和搜索。在每个生产者账户中，配置 CloudWatch Logs 订阅筛选器，将其指向一个由中央 Kinesis Data Firehose 支持的跨账户日志目标。启用 Firehose 的以下功能：

通过 Lambda 进行数据转换，以实现标准化 (JSON)、PII（个人身份信息）脱敏，并使用 AWS 账户、区域、VPC 和服务元数据来丰富日志内容。
在交付到 S3 时进行压缩 (GZIP) 和动态分区，以优化 Athena 中的查询性能。
使用 KMS 加密并通过 VPC 交付到私有端点。将日志交付到 Amazon OpenSearch Service 以实现低延迟搜索和 Kibana/OpenSearch Dashboards 可视化。使用索引模板、用于滚动和保留的 ILM/ISM 策略，以及将用户映射到索引模式（例如，账户/团队/服务）的精细化访问策略。为失败的文档配置到 S3 的错误输出，并监控 Firehose 的交付和 OpenSearch 的摄取指标 (DeliveryToElasticsearch.Success, ElasticsearchFailedRequests)。对于超高流量的场景，可以考虑通过 Firehose 将所有日志存入 S3，然后将一个子集流式传输到 OpenSearch，同时对 S3 中的数据按需使用 Athena 查询进行长尾调查，以控制成本。

将此管道与 CloudWatch 指标筛选器结合使用，以实现快速、低成本的计数器；并与 Logs Insights 结合使用，以进行临时的深度查询。使用由 Firehose/OpenSearch 异常或 CloudWatch 警报触发的 EventBridge 规则来启动修复措施或引发事件。

实际问题场景

Airbnb 部署在 EKS 和 Lambda 上的微服务出现了间歇性的 API 错误和延迟峰值，同时有多个移动应用版本在线上运行。运维团队需要近乎实时地按 API 操作、响应代码和应用版本进行检测；跨越跟踪和日志进行快速的根因分析；对已知的故障模式进行自动化修复；并建立符合治理要求的审计追踪。

标准化结构化日志记录

在服务（EKS、Lambda）中实施 EMF 结构的 JSON 日志，包括 apiOperation、statusCode、appVersion、tenantId 和 latencyMs 等字段。
原因：EMF 能够以低开销和高基数维度在 CloudWatch 中直接提取指标，从而实现精确的警报。

创建 CloudWatch Logs 指标筛选器

为每个服务日志组定义指标筛选器，按 apiOperation、statusCode 和 appVersion 递增计数器。
原因：无需额外的代码路径即可生成按维度划分的指标，从而能够为每个 API 和客户端版本创建仪表板和可操作的警报。

构建分层 CloudWatch 警报和复合警报

针对 p95 延迟、5xx 错误率和饱和度（CPU、内存、并发/节流）设置警报。创建一个复合警报：连续 3 个周期中有 2 个周期出现 LatencyHigh AND ErrorsHigh。
原因：减少噪音，专注于对用户产生影响的事件。

部署带有目标采样的 X-Ray 跟踪

在 EKS 上使用 ADOT 收集器，并为 Lambda 启用主动跟踪。定义采样规则以捕获所有错误跟踪和具有代表性的成功调用样本，并对新的应用版本进行更高的采样率。
原因：在控制成本的同时，保证对故障的可见性，并为性能热点提供足够的覆盖范围。

与 ServiceLens 和 Logs Insights 关联分析

创建结合了指标小组件、X-Ray 服务地图和 Logs Insights 查询（例如，filter status >= 500 | stats count() by apiOperation, appVersion）的仪表板。
原因：单一窗格的关联分析加速了对哪个操作和客户端版本出现性能衰退的诊断。

通过 Firehose 将日志集中到 OpenSearch 和 S3

配置订阅筛选器到一个中央 Firehose，通过 Lambda 转换来规范化、脱敏 PII 并使用账户/区域信息进行丰富。将日志交付到 OpenSearch 用于 7 天的热数据搜索，并交付到 S3 用于持久保留和 Athena 查询。
原因：实现对当前问题的快速、跨团队搜索，并能进行低成本的历史分析。

使用 EventBridge 实现自动化检测和修复

为 CloudWatch 警报状态变化和选定的 CloudTrail 写入 API 事件（例如，安全组修改）创建 EventBridge 规则。目标：使用 Lambda 进行安全回滚（例如，恢复功能标志），使用 Step Functions 进行多步修复。
原因：事件驱动的控制循环缩短了 MTTR（平均修复时间）并强制执行护栏。

集成 AWS Health 和维护处理

为影响 EC2、EKS 或网络的 aws.health 事件添加 EventBridge 规则。目标：使用 SSM Automation 来隔离/排空节点或转移流量。
原因：主动缓解计划内或运营性问题，减少停机时间。

通过 CloudTrail 组织跟踪和完整性验证来强化治理

启用一个组织级别的、多区域的跟踪，包含 S3 和 Lambda 的数据事件，使用 SSE-KMS 加密，并开启日志文件验证。将其流式传输到 CloudWatch Logs 和 OpenSearch，用于异常发现和调查。
原因：完整、防篡改的审计满足合规性要求并加速 RCA（根因分析）。

通知和运维集成

将关键事件路由到 SNS 和待命系统，创建附带运行手册的 OpsCenter OpsItems，并为警报附加所有权和严重性标签。
原因：明确的所有权和自动化的运行手册提高了响应质量和速度。

选择此设计是为了结合低延迟、维度丰富的指标 (CloudWatch + EMF)、深度跟踪关联 (X-Ray + ServiceLens)、大规模搜索 (OpenSearch + S3/Athena)、事件驱动的修复 (EventBridge + Lambda/SSM/Step Functions) 以及可审计的治理 (CloudTrail 完整性验证)。它通过采样、分层保留和反映真实用户影响的目标性警报，在成本和保真度之间取得了平衡。

← 基础架构即代码和配置管理 · 所有领域 · 安全、合规性和治理 →

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