AWS CloudWatch 异常检测器

为什么需要异常检测

在云上架构里，CloudWatch 指标往往不是平滑上涨，而是伴随着业务峰值、下游抖动和突发流量一起出现。如果所有告警都按固定阈值配置，要么在凌晨被无意义的峰值叫醒，要么在真正的小概率异常上漏报。

异常检测的价值在于把“人肉猜阈值”这个环节交给统计模型。当某个指标偏离自身的正常行为太多时再触发告警，能明显减少误报，也能让值班同学更快定位真实的抖动来源。

这个技能做什么

技能直接封装了 AWS CloudWatch 的异常检测能力，核心逻辑只有三步：

• 调用 PutAnomalyDetector API：在指定的 CloudWatch 指标上创建异常检测带，后续 CloudWatch 会根据历史数据生成动态上下限。
• 与 SNS 集成：当指标超出检测带范围时，CloudWatch 可以主动推送通知到 SNS Topic，再由 SNS 分发到邮件、短信或 IM。
• 结合 CloudWatch Synthetics：用金丝雀脚本模拟关键业务流程，把合成的指标也纳入异常检测，覆盖业务层面的“正常运行时间”。

使用上需要已经准备好 AWS 凭证，并且有权限操作 cloudwatch:PutAnomalyDetector 和相关的 SNS、Synthetics 资源。技能本身不负责这些前置配置，需要你在环境中提前搞定。

适用边界与注意点

• 数据质量决定效果：异常检测依赖历史数据。如果指标本身太新、周期性波动太大，或者存在大量节假日效应，初始的检测带可能不准，需要一段时间的校准。
• 成本要考虑：异常检测是 CloudWatch 的计费功能，开启检测器和监控频次都会带来成本。建议先在非核心指标上试运行，观察误报率和成本后再扩大范围。
• 通知要收敛：SNS Topic 里的订阅者如果过多，一条异常可能会触发很多消息。建议在 Topic 上做消息过滤或聚合，避免通知风暴。

适合的场景是已经重度依赖 CloudWatch，且希望用更精细的方式管理告警的团队。如果你的指标本身就是完全确定的阶梯式变化，固定阈值反而更简单可控。