CloudWatch 警报分诊

问题：警报响起，但没人知道是哪次部署惹的祸

CloudWatch 里堆了成百上千条告警，CPUUtilization 超阈值、Lambda 错误率飙升、DynamoDB 节流频现。真正棘手的不是“报警了”这件事本身，而是排查时的几个连环坑：

• 告警是孤立的：describe_alarms 只告诉你“现在处于 ALARM 状态”，不告诉你什么时候开始、持续多久、和什么同时发生。
• 缺少上下文链路：一个 5XX 告警背后可能是一次有问题的发布，也可能是下游依赖抖动，光看指标曲线很难区分。
• 日志和指标各说各话：CloudWatch Logs 里的错误堆栈和 CloudWatch Metrics 的异常曲线分属两个系统，人工对齐时间线既慢又容易漏。

这个技能做什么

它把三类数据拉到一起，用统一的分诊流程回答“这条告警到底是怎么回事”：

• 指标层：调用 boto3 的 CloudWatch.describe_alarms 获取告警的状态、时间戳、阈值与维度，确定告警的真实起止和当前评估值。
• 日志层：用 CloudWatch Logs Insights 查询关联日志组，在告警时间窗内过滤错误、异常和自定义事件，把“指标异常”落地成可读的具体错误。
• 链路层：通过 xray-sdk 读取 AWS X-Ray 的 trace 数据，找出慢请求、错误 trace 以及服务拓扑中受影响的下游节点。

关键步骤

1. 拉取告警列表，按状态、时间戳和告警名做初步分组，识别是持续性故障还是瞬时抖动。
2. 用 Logs Insights 在告警起止时间窗口内查询对应日志，抽取错误类型、频次和首见时间。
3. 查 X-Ray trace，定位错误率最高的下游依赖或具体 Segment。
4. 把告警触发时间与部署事件对齐：这是分诊的核心动作。当告警窗口和某次发布的时间线吻合，就可以把矛头指向这次变更，而不是继续大海捞针。

适用边界

• 不是自动修复工具：它做诊断和归因，不会自动回滚或修改告警阈值。
• 依赖可观测性基建：X-Ray 需要服务已埋点并启用 tracing，Logs Insights 需要目标日志已接入 CloudWatch Logs；没有这些数据源，相应分析步骤会返回空结果。
• 部署事件来源需自行打通：技能提供关联的方法论，但部署时间线数据需要来自你的 CI/CD 系统或 CodeDeploy 事件，上游资料里没有内置这部分数据源。
• 上游资料是 Node.js 示例：boto3 与 xray-sdk 分属 Python 和 Node.js 生态，迁移到自己的技术栈时需要对应调整。