告警阈值怎么设？持续时间、去重与恢复通知
阈值应该对应一个需要处理的状态
“CPU超过某个比例就发消息”容易产生很多通知，却未必告诉值班人员该做什么。设置告警前先写清需要保护的业务、能够采取的动作和响应时限。若只是值得下次容量讨论关注，可以进入日常报告，不一定需要立即打断值班人员。
不同指标适合不同条件。磁盘剩余空间接近耗尽，需要结合增长速度判断；错误率上升需要考虑请求总量；延迟增加则要区分少量异常与持续影响。一个固定数字复制到所有机器，通常无法表达这些差别。
用持续时间过滤瞬时波动
短暂尖峰可能来自正常批处理、采样抖动或发布过程。告警规则可以要求条件持续成立一段时间，再进入通知状态。Prometheus的for机制体现了这种判断方式，并区分等待与触发状态。官方告警规则说明
假设某接口一分钟内只有两次请求，其中一次失败，百分之五十的错误率看起来很高，但样本量很小。可以结合最低请求量、连续时间和外部探测判断；对于低流量但关键的业务，也不能简单因请求少而永远不告警。
持续时间过长又会拖延发现真实故障，因此应根据业务影响选择。服务完全无法连接与容量缓慢增长，不必使用同样的等待窗口。设置理由应写入规则说明，方便之后根据实际误报和漏报调整。
去重与分组减少重复阅读
同一个故障可能让多台实例、多个探测点同时通知。分组可以把具有相同服务或事件属性的告警汇总，去重则减少同一状态反复发送。Alertmanager提供分组、路由、去重、静默和抑制等机制，各自解决的问题不同。Alertmanager官方说明
分组键应保留处理边界。把不同业务全部并成一条“大量故障”，虽然消息少了，却可能让负责人找不到自己的问题。比较合适的分组通常保留服务、环境和告警类型，再把实例明细放进内容中。
重复通知也需要节奏。长期未处理的严重问题应有适当提醒或升级路径，而不是永远只发一次；仍在处理中且状态未变的告警，则不必每分钟占满同一个频道。
抑制依赖告警要谨慎
当一个明确的上游故障已经触发时，可以暂时抑制已知从属告警，减少重复噪声。但依赖关系必须稳定且可解释，不能因为某台数据库异常，就把整个网站的所有独立错误全部隐藏。
假设某机房出口故障已经确认，该范围内的多个节点连接失败可以汇总处理；其他地区同时出现应用错误则应继续显示。抑制规则应该限制服务范围和条件，并在上游恢复后自动回到正常评估。
维护静默同样要有起止时间、原因和负责人。静默的是通知，不应让采集和记录停止。维护期间如果出现范围外的故障，仍需要能够被发现。
恢复通知应证明状态已经回稳
阈值边缘来回波动容易导致“故障—恢复—故障”连续刷屏。可以按工具能力设置持续恢复条件或不同的进入、退出门槛，使状态变化反映稳定趋势。具体机制应在当前监控工具中验证，不能只写在值班文档里。
恢复通知包含事件标识、持续时间和影响范围，帮助值班人员关闭对应事件。它不自动证明业务全部正常，关键故障仍需要实际流程验收。若告警由于数据采集中断而消失，也不能发送误导性的恢复结论。
上线新规则前，用历史数据回看触发情况，再在受控测试中验证通知路由、去重和恢复。定期检查无人响应、长期静默和频繁误报的规则。好的告警体系应让收到消息的人知道为什么现在需要行动，而不是让消息数量成为监控工作的成果。