📚 课程目录第2章 AWS可观测性服务全景

2. AWS可观测性服务全景

在 AWS 上做可观测性，最容易踩的坑不是“工具不够”，而是“工具太多、边界不清”。同一个故障现象，有人先去看 CloudWatch 指标，有人去翻 CloudTrail 事件，有人去查 Config 变更记录，最后发现大家看的根本不是同一层信息。要建立可诊断的体系，第一步不是接更多数据源，而是先把每个服务的职责边界划清楚，再理解它们如何协同。

五个服务，五种“看问题的角度”

可以把这套体系理解为对同一个系统从五个不同切面进行观测：

CloudWatch：面向“运行状态”的指标、日志与告警中枢。它回答的是“现在系统表现如何”——CPU、内存、延迟、错误率、日志内容、阈值告警。
X-Ray：面向“请求链路”的分布式追踪。它回答的是“一个请求经过了哪些服务、在哪一跳变慢或失败”。
CloudTrail：面向“控制面操作”的审计日志。它回答的是“谁在什么时候对 AWS 资源做了什么 API 调用”。
Config：面向“资源配置状态”的合规与变更记录。它回答的是“资源当前配置是什么、是否符合规则、何时被改过”。
Distro for OpenTelemetry（ADOT）：面向“数据采集与标准化”的开放采集层。它回答的是“如何用统一协议把指标、日志、追踪送到后端”。

关键区别在于：CloudWatch 和 X-Ray 关注数据面（请求、性能、日志），CloudTrail 和 Config 关注控制面（API 调用、资源配置），而 ADOT 是横跨两者的采集与传输层。很多排障混乱，正是因为把控制面问题当成数据面问题查，或者反过来。

职责边界：什么时候该看哪个服务

把边界落到排障动作上，可以用一个简单的判断链：

如果现象是“接口变慢、错误率上升、资源打满”，先看 CloudWatch 的指标和日志，确认异常的时间窗口和影响范围。
如果 CloudWatch 显示某个服务延迟高，但不知道慢在哪一段，用 X-Ray 追踪具体请求，看是下游调用、数据库还是自身处理耗时。
如果怀疑是“有人改了配置”或“某个 API 调用触发了异常”，查 CloudTrail，按时间窗口过滤事件，找到操作者和操作内容。
如果怀疑“资源配置不符合预期”或“安全组被意外放开”，用 Config 查看配置时间线，确认变更前后的资源状态。
如果以上数据分散、采集方式不统一，用 ADOT 统一采集层，把指标、日志、追踪用 OTLP 协议标准化后分发。

边界口诀：CloudWatch 看“表现”，X-Ray 看“路径”，CloudTrail 看“操作”，Config 看“配置”，ADOT 管“采集”。前两者是数据面，后两者是控制面，ADOT 是横跨两面的采集管道。

协同关系：从告警到根因的完整链路

单独看每个服务都不难，难的是把它们串成一条可执行的排障链路。下面用一个典型场景说明协同方式。

假设某电商应用在 14:05 出现订单接口 P99 延迟从 200ms 飙升到 2.3s。排障过程如下：

第一步：CloudWatch 告警触发。订单服务的 TargetResponseTime 指标越过 1s 阈值，SNS 发出告警。同时查看该服务的日志组，发现大量 TimeoutException，时间集中在 14:03–14:08。
第二步：X-Ray 定位慢调用。在 X-Ray 服务地图中，订单服务到库存服务的边显示为红色，平均响应时间 2.1s。展开 Trace 详情，发现库存服务的 GetItem 子段耗时 2.0s，而数据库查询本身只占 50ms，剩余耗时在连接获取阶段。
第三步：CloudTrail 查同期变更。在 CloudTrail 事件历史中按 14:00–14:10 过滤，发现 14:02 有一次 UpdateFunctionConfiguration 调用，操作者是某个 CI/CD 角色，修改了库存服务的 Lambda 并发配置。
第四步：Config 确认配置漂移。在 Config 中查看该 Lambda 函数的配置时间线，确认 ReservedConcurrentExecutions 从 100 被改为 10，导致并发不足、请求排队。
第五步：ADOT 验证采集一致性。如果该应用使用 ADOT 采集，可以在 ADOT Collector 的指标中确认追踪数据与 CloudWatch 指标的时间戳对齐，排除采集延迟造成的误判。

这条链路的价值在于：CloudWatch 告诉你“出了问题”，X-Ray 告诉你“问题在哪”，CloudTrail 告诉你“谁改了什么”，Config 告诉你“改成了什么状态”。四者缺一，根因定位就会断链。

ADOT 的定位：不是替代，而是统一

很多团队会问：既然 CloudWatch Agent 和 X-Ray SDK 已经能采集数据，为什么还需要 ADOT？答案在于标准化与可移植性。

CloudWatch Agent 主要采集指标和日志，X-Ray SDK 主要做追踪，两者配置方式、数据格式、部署模型都不同。当应用同时需要指标、日志、追踪，并且未来可能切换到其他后端（如 Prometheus、Jaeger、Datadog）时，维护多套 Agent 的成本会迅速上升。

ADOT 的做法是：用 OpenTelemetry Collector 作为统一采集层，应用通过 OTLP 协议发送数据，Collector 再根据配置将数据路由到 CloudWatch、X-Ray 或其他后端。这样应用侧只需要一套埋点，后端切换时只改 Collector 配置，不改应用代码。

# ADOT Collector 配置片段（示例）
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  awsxray:
    region: ap-northeast-1
  awscloudwatch:
    region: ap-northeast-1
    namespace: MyApp

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [awsxray]
    metrics:
      receivers: [otlp]
      exporters: [awscloudwatch]

这段配置的含义是：Collector 监听 4317 端口的 OTLP gRPC 数据，追踪数据导出到 X-Ray，指标数据导出到 CloudWatch。应用侧只需要配置 OTLP Endpoint 指向 Collector，不需要分别集成 X-Ray SDK 和 CloudWatch Agent。

注意：ADOT 是采集层，不是分析层。它不替代 CloudWatch 的告警能力，也不替代 X-Ray 的服务地图。它的价值在于“统一入口、统一协议、统一路由”，让数据面信号的采集不再碎片化。

边界混淆的典型反模式

实际工作中，以下几种混淆最常见：

反模式	表现	正确做法
用 CloudTrail 查性能问题	在 CloudTrail 里找延迟原因，发现只有 API 调用记录，没有请求耗时	性能问题看 CloudWatch 指标和 X-Ray 追踪，CloudTrail 只用于查操作审计
用 CloudWatch 查配置变更	在日志里搜索“谁改了安全组”，日志中没有 API 调用者信息	配置变更查 CloudTrail 和 Config，CloudWatch 日志不记录控制面操作者
用 X-Ray 查资源合规	想确认 S3 桶是否开启加密，X-Ray 中只有请求链路，没有资源配置	资源配置和合规检查用 Config，X-Ray 只关注请求路径
多套 Agent 并行采集	同时部署 CloudWatch Agent、X-Ray Daemon、自定义采集器，配置冲突、资源浪费	用 ADOT 统一采集，按 pipeline 分发到不同后端

建立协同排障的最小闭环

要让这套体系真正可用，不需要一开始就全部接入。可以先建立最小闭环：

CloudWatch 告警 + 日志：确保核心服务的错误率和延迟有告警，日志集中到 CloudWatch Logs。
X-Ray 追踪：在关键请求路径上启用追踪，至少覆盖入口服务和核心下游。
CloudTrail 开启：确保管理事件记录到 CloudTrail，并保留至少 90 天。
Config 记录：对关键资源（安全组、IAM、Lambda 配置）开启配置记录。
ADOT 按需引入：当采集配置开始碎片化时，引入 ADOT 统一采集层。

这个顺序的逻辑是：先有“发现问题的能力”（CloudWatch），再有“定位问题的能力”（X-Ray），然后有“追溯变更的能力”（CloudTrail + Config），最后才是“优化采集架构”（ADOT）。跳过前几步直接上 ADOT，只会让采集更统一，但排障链路依然断裂。