Alert

Alert

• 警报应当是紧急的、重要的、可操作的，并且是真实的。
• 它们应该代表服务中持续存在或即将出现的问题。
• 应该避免过度监控导致的噪音警报，因为过度监控比欠缺监控更难解决。
• 你几乎总应该能够将问题归类为以下一种：
  • 可用性和基础功能性
  • latency
  • 正确性（数据的完整性、新鲜度和持久性）
  • 特定功能的问题。
• 症状是以更全面和更少的努力捕获更多问题的更好方法。
• 应该在基于症状的页面或仪表板上包括基于原因的信息，但避免只关注原因。

处理警报

症状为本的监控

1. 警报系统需要处理需要及时响应的问题，但不一定是紧迫的问题。
2. 每次接到警报时，应该有紧迫感地做出反应。
3. 每个页面的警报都应该是可操作的，不能只是简单地记录“这个页面又警报了”。
4. 每个页面的警报都应该需要智能来处理，不能有机械式或可脚本化的回应。

警报规则

在处理警报规则时，应该问自己以下几个问题：

1. 这条规则是否能检测到以前未发现的紧急、可操作和活动的问题？
2. 我是否能忽略这条规则，知道它是良性的？
3. 它是否确定会伤害用户？
4. 我能对这个警报采取行动吗？行动是否紧急？
5. 是否有其他人同时收到警报？他们会解决问题吗？

追踪和责任制度

跟踪页面和警报是保证警报有效性的关键。如果一个页面触发警报，人们只是说“我看了一下，没有问题”，这是一个警报系统的红旗。 警报准确度低于50%的应该被认为是损坏的，需要修正或以其他方式彻底收集数据。 实施定期检查（例如，所有页面的周检查和季度统计）有助于把握整体情况，识别通常在页面移交时丢失的模式。