3. CloudWatch指标与告警实战

CloudWatch 的告警能力远不止“某个指标超过阈值就发通知”。在真实生产环境中，我们经常需要把业务侧数据变成指标、用秒级精度捕捉瞬时抖动、用数学表达式把多个指标合成一个判断依据、用复合告警抑制告警风暴，还要用异常检测替代固定阈值。本节围绕这五类能力，讲清它们各自解决什么问题、如何配置、以及排错时该看哪里。

一、自定义指标：把业务语义变成可告警的信号

CloudWatch 内置指标覆盖 EC2、RDS、ALB 等 AWS 服务，但“订单支付失败率”“队列积压条数”“第三方接口 P99 延迟”这类业务语义必须通过 PutMetricData 上报。自定义指标的关键约束是：命名空间（Namespace）、指标名（MetricName）、维度（Dimensions）三者共同构成指标的唯一身份。维度一旦写错，指标就会“消失”在另一个时间序列里。

上报时需要注意三点。第一，维度值不要使用高基数变量（如用户 ID、请求 ID），否则会产生海量时间序列并推高费用；应使用 Environment、Service、Region 这类有限集合。第二，单位（Unit）要显式指定，例如 Count、Milliseconds、Percent，否则告警阈值缺乏语义。第三，统计集（StatisticSet）用于一次性上报多个样本，适合批量聚合场景。

aws cloudwatch put-metric-data \
  --namespace "OrderService" \
  --metric-name "PaymentFailureRate" \
  --dimensions Service=Checkout,Environment=Prod \
  --unit Percent \
  --value 2.7

排错时最常见的现象是“指标列表里找不到刚上报的数据”。此时先确认命名空间与维度是否与查询一致，再确认时间范围是否落在指标保留窗口内（高分辨率指标保留 3 小时，标准分辨率 15 个月）。如果使用 IAM 角色上报，还要检查 cloudwatch:PutMetricData 权限以及是否被 Condition 限制了命名空间。

二、高分辨率指标：秒级精度与成本权衡

标准指标的最小采集间隔是 60 秒，而高分辨率指标支持 1、5、10、20、30 秒。它适用于短时突发流量、秒杀场景、瞬时错误率飙升等“60 秒平均会掩盖问题”的情况。启用方式是在 PutMetricData 时把 StorageResolution 设为 1（或 5/10/20/30）。

高分辨率带来两个直接后果：一是告警可以配置 Period 为 10 秒甚至更短，从而更快触发；二是数据点数量成倍增加，费用上升，且高分辨率数据只保留 3 小时，之后自动降采样为 1 分钟。因此建议只对真正需要秒级响应的核心指标开启，而不是全量开启。

三、指标数学表达式：把多个指标合成一个判断

指标数学表达式（Metric Math）允许在告警中引用多个指标并做运算。典型场景包括：用 m1/m2*100 计算错误率、用 m1-m2 计算队列净增长、用 RATE(m1) 计算每秒请求数。表达式中的每个指标用 m1、m2 等标识，最终告警作用于表达式结果。

一个常见错误是直接对两个不同周期的指标做除法，导致结果失真。正确做法是让参与运算的指标使用相同的 Period，并在表达式中显式指定。例如计算 5 分钟内错误率：

m1 = Errors   (Sum, Period=300)
m2 = Requests (Sum, Period=300)
e1 = m1 / m2 * 100

告警阈值作用于 e1，例如“错误率大于 5% 持续 2 个周期”。排错时若发现表达式结果为空，通常是因为某个子指标在该时间段没有数据，CloudWatch 默认会返回空值；此时可用 FILL(m1, 0) 填充缺失值，或调整 TreatMissingData 策略。

四、复合告警：用逻辑组合抑制告警风暴

复合告警（Composite Alarm）把多个子告警用 AND、OR、NOT 组合成一个告警。它的核心价值是减少噪音：例如“CPU 高”单独出现可能只是正常波动，但“CPU 高 AND 请求延迟高 AND 错误率高”才代表真实故障。复合告警的规则语法如下：

ALARM("HighCPU") AND ALARM("HighLatency") AND ALARM("HighErrorRate")

配置时要注意：复合告警本身不直接监控指标，它只引用其他告警的状态。因此子告警的 TreatMissingData 设置会直接影响复合结果。如果子告警在无数据时被判定为 INSUFFICIENT_DATA，复合告警可能无法进入 ALARM 状态。排错时应先确认每个子告警的当前状态，再检查复合规则中的告警名称是否与 ARN 完全匹配。

五、异常检测：让阈值随业务节奏自动调整

固定阈值在流量有明显周期性的业务中很容易误报。异常检测（Anomaly Detection）基于历史数据训练一个带宽模型，自动给出每个时间点的“正常范围”，告警在指标超出该范围时触发。它特别适合日周期、周周期明显的指标，如白天高峰、夜间低谷的请求量。

启用异常检测时，CloudWatch 需要至少两周的历史数据来建立基线。训练完成后，控制台会显示一条带状区间。告警配置中选择“Anomaly detection”作为条件，并设置带宽（例如 2 个标准差）。如果业务发生结构性变化（如大促、架构调整），旧模型可能不再适用，此时需要重新训练或临时切换回固定阈值。

六、配置与排错的关键检查点

把这五类能力串起来看，配置顺序建议是：先确定命名空间与维度，再决定是否需要高分辨率，然后构建数学表达式，接着配置子告警与复合规则，最后验证告警状态流转。排错时按“数据是否存在 → 分辨率是否正确 → 表达式是否为空 → 子告警状态是否正常 → 复合规则是否匹配”的顺序逐层排查，通常能快速定位问题。

最后需要强调的是，告警配置不是一次性的工作。业务流量模式变化、架构调整、大促活动都会影响阈值的合理性。建议定期回顾告警的误报率和漏报率，对固定阈值逐步过渡到异常检测，对高频噪音告警用复合规则收敛，让告警真正成为可信赖的信号，而不是被忽略的背景噪音。