CloudWatch 调查：您的 AI 驱动的故障排除助手
Source: Dev.to
记得那些凌晨 3 点的故障吗？当你在仪表盘之间疯狂切换、翻阅日志，却仍在犹豫是否该直接重启所有服务？
我们都曾在非工作时间、周末或深夜排查生产问题——这是一项极度消耗精力的任务。
如果在这个生成式 AI 时代，我们拥有一个 24 × 7 全天候工作的 AI 助手，能够在混乱中为我们指引方向呢？
引入 CloudWatch Investigations，一项由生成式 AI 驱动的功能，正在改变我们在 AWS 环境中处理事故的方式。
工作原理
当出现故障时，您不必在 CloudWatch 指标、日志、部署历史、CloudTrail、X‑Ray 和健康仪表板之间来回切换，CloudWatch Investigations 会为您完成第一轮侦查工作。
它使用 生成式 AI 来扫描系统的遥测数据，并快速呈现：
- 可疑指标
- 相关日志
- 最近的部署或配置更改
- 可能的根本原因假设（尤其是在涉及多个资源时）
所有这些都以可视化方式展示，让您能够 看到 各项之间的关联，而不是盲目猜测。它就像拥有一位额外的团队成员，24 / 7 盯着您的系统架构。
入门
- 打开控制台 – 在 AWS 控制台中转到 CloudWatch → AI Operations（左侧面板）。
- 首次设置 – 如果这是您首次配置账户，系统会提示您设置一个 调查组。
创建调查组
| 设置 | 描述 |
|---|---|
| 保留天数 | 调查保留的时长。注意：保留期限设置后无法更改。 |
| 自定义加密 | 使用客户管理的 KMS 密钥进行加密。确保已为该密钥授予所需权限。 |
| IAM 角色 | CloudWatch Investigations 会创建一个具有所需 只读 权限的角色。您也可以创建自定义角色。默认会附加： • AIOpsAssistantPolicy • AmazonRDSPerformanceInsightsFullAccess • AIOpsAssistantIncidentReportPolicy |
创建组后，您将看到 可选的增强配置 选项。
增强集成选项
- 应用标签 – 包含与您的应用程序相关的标签，以帮助 CloudWatch 缩小调查范围。
- CloudTrail 访问 – 使服务能够发现相关的变更事件。
- 可选数据源 – X‑Ray、Application Signals 和 EKS 访问条目。
Source: …
演示
示例应用
本演示使用一个简单的 事件预订 应用：
- 用户流程 – 用户通过提供详细信息并选择可用时段来预约。
- 管理员流程 – 管理员批准或拒绝请求。
引入故障
-
修改 Lambda 角色 – 从 Lambda 执行角色中移除 KMS 权限。
-
模拟中断 – 用户在尝试查看时段时开始看到错误，管理员也无法看到任何预约。
-
初步调查 – 应用的入口点是 CloudFront。检查 CloudFront 时发现 5xx 错误激增。
(继续使用 CloudWatch Investigations 进行调查——它会自动显示缺失的 KMS 权限，指出受影响的 Lambda，并提供补救步骤建议。)
回顾
- CloudWatch Investigations 利用生成式 AI 将原始遥测数据转化为可操作的洞察。
- 它通过自动化首步侦查，降低平均检测时间 (MTTD) 和平均解决时间 (MTTR)。
- 该功能与现有 AWS 服务（CloudWatch、CloudTrail、X‑Ray 等）集成，并可通过标签和可选数据源进行微调。
下次在凌晨 3 点被拉入事故时试一试——让 AI 完成繁重的工作，你专注于根因修复。
开始调查
-
在 CloudWatch 指标 5xx 下，您可以启动调查以找出服务返回 5xx 错误的原因。
视图会自动选择最近的时间戳，但如果需要可以调整开始时间。
-
调查启动后，需要 10‑15 分钟 完成。您可以观看进度，或利用这段时间与用户/业务沟通或开展其他并行活动。
-
调查完成后，会清晰显示 出了什么问题以及为何出现 5xx 错误 🥳🥳🥳
在 根本原因摘要 中，问题被确定为 IAM 配置问题。
分析 – 该失败模式代表 IAM 配置问题，而非服务降级，证据包括特定的 KMS 权限错误以及 “NEW” 发生模式，表明最近的权限更改影响了 eventap 预发布服务组件。
