2. AWS可观测性核心服务概览
在AWS上做可观测性与故障诊断，最容易踩的坑不是“工具不够”，而是“工具用错”。同一个问题，用CloudWatch查指标可能只看到CPU飙高，用CloudTrail却能发现是某个IAM策略变更导致权限被拒，用X-Ray才能定位到是下游Lambda冷启动拖慢了整条链路。因此，理解每个服务的功能边界，比记住它们的名字更重要。
我们可以把AWS可观测性服务按“观测对象”和“回答的问题”两个维度来划分。CloudWatch回答“系统现在运行得怎么样”，CloudTrail回答“谁在什么时候做了什么操作”，X-Ray回答“一个请求在分布式链路中慢在哪一段”，VPC Flow Logs回答“网络层哪些IP和端口在通信、是否被拒绝”，Config回答“资源配置是否符合预期、何时发生了变更”。这五个服务覆盖了指标、日志、链路、网络、配置五个不同的观测面，彼此互补而非替代。
从图中可以清晰看到，五个服务各自对应一个观测面，且底部给出了从“故障现象”反推“该用哪个服务”的决策路径。接下来逐一说明每个服务的功能边界和典型使用场景。
CloudWatch：指标、日志与告警的中枢
CloudWatch是AWS可观测性的默认入口。它接收三类数据：指标（Metrics）、日志（Logs）和事件（Events）。EC2的CPU使用率、ALB的请求数和延迟、Lambda的调用次数和错误数、SQS的队列深度，都会自动以指标形式进入CloudWatch，默认保留15个月，粒度从1分钟到1天可调。日志方面，应用可以通过CloudWatch Logs Agent或SDK把日志推送到日志组，Lambda则自动把每次调用的日志写入/aws/lambda/<函数名>日志组。
CloudWatch最实用的能力是告警（Alarm）。告警基于指标阈值触发，可以绑定SNS主题发邮件、触发Auto Scaling、或调用Lambda做自动修复。例如，为ALB的HTTPCode_ELB_5XX_Count设置“5分钟内求和大于10”的告警，就能在5xx错误集中出现时第一时间通知。需要注意的是，CloudWatch指标是聚合数据，它告诉你“出了问题”，但不告诉你“为什么出问题”——后者需要日志和链路追踪来补充。
CloudTrail：API操作的审计底账
CloudTrail记录的是“控制平面”操作：谁通过控制台、CLI、SDK或AWS服务调用了哪个API，在什么时间、从哪个IP、请求参数是什么、返回结果如何。默认情况下，CloudTrail在创建AWS账户时自动开启，保留90天的管理事件历史。要长期保留或分析数据事件（如S3对象级操作），需要创建跟踪（Trail）并把日志投递到S3桶。
在故障诊断中，CloudTrail的价值在于“变更追溯”。比如某台EC2突然无法访问，CloudWatch显示CPU正常、网络正常，但应用报权限错误。此时查CloudTrail，可能会发现10分钟前有人调用了ModifyInstanceAttribute修改了安全组，或者调用了DetachRolePolicy移除了实例角色策略。CloudTrail不直接告诉你“服务挂了”，但它能告诉你“谁在什么时候动了什么”，这是排查人为变更类故障的关键证据。
AWS X-Ray：分布式调用链的显微镜
X-Ray解决的是“一个请求跨多个服务时，慢在哪一段、错在哪一段”的问题。它通过在应用代码中集成X-Ray SDK，为每个请求生成Trace ID，并在服务间传递。每个被追踪的片段称为Segment，子片段称为Subsegment。X-Ray把这些片段聚合成服务地图（Service Map），直观展示调用关系和每段的耗时、错误率。
典型场景：API Gateway → Lambda → DynamoDB 的请求延迟升高。CloudWatch只能看到API Gateway的总体延迟和Lambda的Duration指标，但无法区分是Lambda冷启动、DynamoDB查询慢，还是网络往返耗时。X-Ray的Trace详情会显示每个Subsegment的耗时，比如DynamoDB的GetItem耗时800ms，而Lambda自身逻辑只有50ms，问题就定位到了DynamoDB的查询效率或容量配置上。X-Ray默认采样率为每秒1个请求加5%的额外请求，高流量场景下需要调整采样规则以控制成本。
VPC Flow Logs：网络层的通断证据
VPC Flow Logs捕获的是VPC内弹性网卡（ENI）的IP流量元数据，包括源IP、目的IP、源端口、目的端口、协议、包数、字节数以及ACCEPT/REJECT状态。它不记录包内容，只记录“谁和谁在通信、是否被允许”。Flow Logs可以投递到CloudWatch Logs或S3，前者便于实时查询，后者便于长期存储和Athena分析。
排查网络问题时，Flow Logs的REJECT记录是最直接的线索。例如，EC2无法连接RDS，安全组看起来配置正确，但Flow Logs显示从EC2到RDS 3306端口的记录状态为REJECT，说明流量被某个安全组或NACL规则拒绝。此时再对照安全组规则和NACL规则，就能快速定位是哪条规则拦截了流量。需要注意的是，Flow Logs只覆盖VPC内的ENI流量，不覆盖VPC对等连接、Transit Gateway或本地网关的流量，这些场景需要结合其他工具。
AWS Config：资源配置的合规与变更时间线
Config持续记录AWS资源的配置状态和变更历史，并可以基于规则（Config Rules）自动评估资源是否符合合规要求。例如，可以定义规则“所有S3桶必须开启版本控制”或“所有安全组不得允许0.0.0.0/0访问22端口”。当资源配置发生变化时，Config会记录变更前后的配置快照，并触发规则评估，标记为COMPLIANT或NON_COMPLIANT。
在故障诊断中，Config的“配置时间线”功能非常实用。当某个资源行为异常时，可以查看它的配置变更历史，确认是否有人修改了关键参数。比如Lambda函数突然报超时，Config的时间线可能显示有人把超时时间从30秒改成了3秒。Config不直接采集指标或日志，但它提供了“配置是否正确、何时被改”的维度，与CloudTrail的操作审计形成互补：CloudTrail记录“谁调用了API”，Config记录“调用后资源配置变成了什么”。
选型依据与组合使用
选择哪个服务，取决于你要回答的问题。如果问题是“系统当前性能如何”，用CloudWatch；如果问题是“谁改了什么”，用CloudTrail；如果问题是“请求慢在哪一段”，用X-Ray；如果问题是“网络通不通”，用VPC Flow Logs；如果问题是“配置是否符合预期”，用Config。实际故障排查中，这五个服务往往需要组合使用。
举一个组合排查的示例：某API的5xx错误率突然升高。第一步，CloudWatch告警触发，显示ALB的5xx指标异常；第二步，用X-Ray查看Trace，发现错误集中在调用下游Lambda时；第三步，查CloudTrail，发现有人在该时间段调用了UpdateFunctionConfiguration修改了Lambda的环境变量；第四步，用Config查看该Lambda的配置时间线，确认环境变量被改成了错误的数据库地址；第五步，如果涉及网络连接，再用VPC Flow Logs确认Lambda到数据库的流量是否被拒绝。这样一条证据链，单靠任何一个服务都无法完成。
掌握这五个服务的功能边界后，下一步需要理解它们各自的数据采集方式、保留策略和成本模型，这样才能在实际架构中合理部署，既保证可观测性覆盖，又避免不必要的费用。