2. AWS可观测性服务矩阵
AWS 的可观测性能力并不是由某一个“全能服务”提供的，而是由一组职责互补的服务共同构成。很多团队在排障时容易陷入一个误区：只打开 CloudWatch 看指标，或者只翻 CloudWatch Logs 找日志，结果在跨服务、跨账户、跨调用链的问题上反复碰壁。要真正把可观测性用起来，第一步不是学某个服务的按钮在哪，而是先建立一张“服务矩阵”的心智地图——每个服务负责哪一类信号、覆盖哪一段生命周期、在什么场景下应该被优先调用。
可以把这七个服务按“信号类型”和“职责层次”两个维度来理解。信号类型回答“它产出什么数据”，职责层次回答“它管的是资源状态、调用行为还是配置与审计”。下面这张图给出了它们之间的定位与协作关系。
从图中可以看出，左侧是“信号从哪里来”，中间是“谁来采集、存储和关联”，右侧是“拿这些数据做什么”。七个服务并不是并列的七个工具，而是分布在三个层次上，各自承担不同的职责。
CloudWatch 与 CloudWatch Logs：指标与日志的双支柱
CloudWatch 是可观测性的“指标中枢”。它接收来自 EC2、Lambda、RDS、ELB 等服务的原生指标，也支持自定义指标。指标是带时间戳的数值序列，天然适合做阈值判断和趋势观察。例如，你可以为某个 Lambda 函数设置一个告警：当 Errors 指标在 5 分钟内累计超过 10 次时触发。CloudWatch 还提供仪表盘，把多个指标放在同一时间轴上对比，这是判断“是单点抖动还是系统性劣化”的关键手段。
CloudWatch Logs 则负责日志。日志组（Log Group）通常按应用或服务划分，日志流（Log Stream）对应具体实例或容器。它的价值不只是“存日志”，更在于 Logs Insights 的查询能力。比如排查一次超时，可以先用下面的查询统计各接口的耗时分布：
fields @timestamp, @message
| filter @message like /timeout/
| stats count() by bin(5m)
| sort @timestamp desc更实用的是“指标过滤器”：把日志中出现的特定关键字（如 ERROR、OutOfMemory）转换成 CloudWatch 指标，这样日志里的异常就能像指标一样被告警和绘图。这一步是把“日志”接入“指标告警体系”的关键桥梁。
X-Ray 与 ADOT：调用链与统一采集
当问题跨越多个服务时，单看指标和日志会非常吃力。X-Ray 解决的是“一次请求到底经过了哪些服务、每一段花了多久、在哪一段出错”。它通过 Trace 记录请求在服务间的传播，并生成 Service Map，直观展示服务依赖和错误率。典型用法是在 Lambda 或 ECS 任务中启用 X-Ray 追踪，然后在控制台按 Trace ID 下钻，定位到具体是下游数据库慢，还是某个函数冷启动导致延迟。
AWS Distro for OpenTelemetry（ADOT）的定位与 X-Ray 不同。它是一个基于 OpenTelemetry 标准的采集器发行版，负责“统一采集”指标、日志和追踪，并导出到多个后端（CloudWatch、X-Ray、第三方 APM 等）。如果你的架构里既有 AWS 托管服务，又有自建 Kubernetes 集群，ADOT 能避免为每种信号单独部署一套采集代理。它更像是“数据管道层”，而 X-Ray 是“追踪数据的分析层”。
EventBridge、Config、CloudTrail：事件、配置与审计
这三个服务常被归为“治理类”，但在故障诊断中同样关键。EventBridge 是事件总线，负责把 AWS 服务状态变化、自定义应用事件路由到目标。例如，当 EC2 实例状态变为 stopped 时，EventBridge 规则可以触发 Lambda 发送通知，或调用 SSM 执行修复脚本。它让“事件”成为自动化的触发器。
Config 记录资源配置项及其变更历史。当有人修改了安全组规则导致服务不可达时，Config 能告诉你“谁在什么时间把哪条规则从允许改成了拒绝”。它回答的是“配置层面发生了什么变化”。CloudTrail 则记录 API 调用审计，回答“谁调用了什么 API、来自哪个 IP、结果如何”。两者结合，就能把“配置变更”和“操作行为”串成一条完整的时间线。
协作关系：从告警到根因的典型路径
把七个服务串起来看，一次典型的生产故障排查大致是这样的：CloudWatch 告警触发，提示某服务错误率上升；你打开 CloudWatch Logs 查看错误日志，发现大量超时；接着用 X-Ray 追踪具体请求，定位到某个下游依赖变慢；同时用 Config 检查该依赖的配置是否近期被修改，用 CloudTrail 确认是否有异常 API 调用；如果确认是配置漂移，可以用 EventBridge 触发自动化修复。ADOT 则在整个过程中负责把指标、日志、追踪统一采集，避免数据孤岛。