CloudWatch 日志异常扫描器

要解决的具体问题

在 AWS 上排查故障时，日志常分散在多个 CloudWatch 日志组：业务错误、服务延迟尖峰、突发日志洪峰混在一起。手动排障时，工程师要在控制台反复切换日志组、编写临时查询、肉眼比对时间线，既容易漏掉跨日志组的关联异常，也难以把「正常波动」和「真正值得告警的信号」区分开。等到发现问题时，往往已经影响用户请求。

它如何工作

这个技能面向上述排障场景，不追求一站式面板，而是把扫描流程收敛为可复用的脚本化动作。

• 跨日志组扫描：通过 CloudWatch Logs Insights API 对多个日志组执行查询，解析日志流中的字段与时间分布。
• 异常信号识别：结合 CloudWatch Anomaly Detection API，对请求延迟、日志写入量等关键指标建立基线，标记偏离基线的时间窗口。
• 模式归类：把命中结果按类型整理，例如 ERROR 类文本模式、延迟峰值、日志量突增，便于快速判断是应用故障、下游依赖抖动，还是采集侧异常。

使用时，先指定目标日志组与时间范围，再运行扫描；技能会返回结构化结果，告诉你哪些时间段出现异常、属于哪种类别，以及对应的日志样本。工程师可以据此直接跳到最可疑的日志流继续深挖，而不用从海量日志里逐页翻找。

适用边界与注意点

• 扫描结果依赖 CloudWatch 权限边界；若 IAM 角色缺少 Logs Insights 或异常检测相关权限，需要先补齐最小授权。
• 异常检测对基线有假设：刚上线的新指标、样本稀疏的低频接口，可能短期内无法给出稳定判断，建议结合业务周期观察。
• 它更适合已有结构化日志或约定字段的场景；完全自定义、无固定 schema 的日志，需要在扫描前补充解析规则。
• 日志量极大时，建议先用时间窗口和过滤条件收窄范围，避免一次性扫描拖慢响应或产生额外成本。

把重复的跨组查询交给脚本，把判断和决策留给工程师，是这个技能最合适的使用姿势。