CloudWatch 的 1 分钟指标和 5 分钟指标为何并存 - 监控粒度与成本的权衡
详细介绍 CloudWatch 基本监控（5 分钟）和详细监控（1 分钟）分开设置的技术和经济原因、指标保留期的分阶段聚合以及自定义指标的高分辨率模式。
5 分钟间隔作为默认值的原因
EC2 的基本监控以 5 分钟间隔收集指标。为什么不是 1 分钟而是 5 分钟呢？原因有两个。第一是数据量和存储成本。AWS 收集数百万台 EC2 实例的指标。如果改为 1 分钟间隔，将产生 5 分钟间隔 5 倍的数据点，存储成本和处理成本增加 5 倍。为了免费提供基本监控，5 分钟间隔是合理的折中方案。第二是大多数工作负载不需要 1 分钟粒度。Web 服务器的 CPU 使用率在 5 分钟内的变化通常足以触发 Auto Scaling。需要更细粒度监控的工作负载可以启用详细监控（每个实例每月约 2.10 美元）。
指标保留期与分阶段聚合
CloudWatch 的指标数据永久保留，但分辨率会随时间推移逐步降低。1 秒间隔的数据点保留 3 小时。1 分钟间隔的数据点保留 15 天。5 分钟间隔的数据点保留 63 天。1 小时间隔的数据点保留 455 天（约 15 个月）。这种分阶段聚合在存储效率和长期趋势分析之间取得了平衡。最近 3 小时可以看到秒级细节，15 天内可以看到分钟级变化，超过 63 天只能看到小时级趋势。
自定义指标的高分辨率模式
CloudWatch 的自定义指标默认为 1 分钟间隔，但使用高分辨率模式（High-Resolution）可以以 1 秒间隔发送数据点。只需将 PutMetricData API 的 StorageResolution 参数设为 1 即可。高分辨率指标在需要实时性的用例中发挥威力。例如 API 的延迟监控、游戏服务器的帧率监控、金融交易系统的处理时间监控等。高分辨率指标的费用与标准指标相同（每个指标每月 0.30 美元），但数据点数量增加会影响 GetMetricData API 的调用成本。
告警的评估周期与 M of N 设置
CloudWatch 告警在指标超过阈值时发送通知，但评估逻辑有需要了解的细节。告警的评估周期（Period）是聚合指标数据点的时间窗口。将评估周期设为 5 分钟时，5 分钟内的平均值（或最大值、最小值、总和）与阈值进行比较。「M of N」设置（Datapoints to Alarm）指定在最近 N 个评估周期中有 M 个超过阈值时触发告警。例如「5 个周期中有 3 个超过阈值」的设置可以忽略瞬时峰值，仅在持续异常时触发告警。
CloudWatch 费用意外增高的模式
CloudWatch 费用中最容易被忽视的是 GetMetricData API 的调用费用。每次打开 CloudWatch 仪表板时，都会对显示的所有指标调用 GetMetricData API。一个包含 10 个小部件各显示 5 个指标的仪表板，以自动刷新（1 分钟间隔）显示 8 小时，每天约产生 24,000 次 API 调用。每 1,000 次请求的指标收费 0.01 美元，看似微不足道，但多个仪表板和多个用户同时使用时会累积。Dashboard API 调用费用可通过减少自动刷新频率和限制每个仪表板的指标数来控制。