CloudWatch 告警分诊器

解决什么问题

在 AWS 环境中，CloudWatch 告警数量可能随服务规模增长而膨胀，单纯依赖告警状态（如 ALARM/OK）难以快速定位根因。运维团队需要人工关联 CloudTrail 事件、EC2 实例健康状态等多维度数据，导致排查效率低且易遗漏关键线索。

技能如何工作

核心能力

• 多源数据关联：通过 boto3 调用 CloudWatch API 获取告警状态变更时间，同步拉取 CloudTrail 事件日志与 EC2 实例健康检查数据，形成时间线关联分析的基础。
• 严重性分级：根据告警类型（如 EC2 状态检查、自定义指标阈值）、影响范围（单实例/集群级）和持续时间，将告警划分为不同严重性等级。
• 根因候选标记：结合 CloudTrail 操作事件（如 RunInstances、TerminateInstances）与 EC2 健康状态（如 ImpairedSystems），标记可能的根因对象（如特定实例 ID 或操作请求 ID）。
• OpsGenie 联动：自动更新 OpsGenie 警报，附带根因候选信息和关联事件 ID，减少人工二次确认的工作量。

关键步骤

1. 定时轮询 CloudWatch 告警状态，捕获 stateChange 事件。
2. 根据告警 ARN 提取关联资源（如 EC2 实例 ID），通过 describe_instances 获取健康状态。
3. 使用 CloudTrail lookup-events 接口，按时间范围过滤相关操作事件。
4. 对齐三者的时间戳，构建关联分析模型，输出根因候选列表。

适用边界与注意点

• 依赖服务：需确保 CloudWatch、CloudTrail、EC2 与 OpsGenie 的 API 权限已正确配置，否则数据拉取会失败。
• 数据延迟：CloudTrail 事件传播可能存在数分钟延迟，紧急告警需结合其他监控手段快速响应。
• 自定义逻辑：严重性分级规则可通过代码扩展，但需团队维护规则与业务需求的一致性。
• 非全自动化：根因候选仅为辅助分析，复杂故障仍需结合人工经验判断。