你的系统稳定吗——监控与警报设计思考

监控指标

监控系统的4个黄金指标分别是

1. 延迟
   处理请求所需要的时间。需要区分成功请求和失败请求的延迟，计算总体延迟时，如果将失败请求的延迟也计算在内，可能会产生误导性的结果。但是，“慢”错误要比“快”错误更糟！因此，监控错误回复的延迟是很重要的。

2. 流量
   对系统负载进行衡量，比如：请求数、并发数、I/O速率

3. 错误
   显式错误：如http表示的系统内部异常状态500、网络超时问题
   隐式错误：如http状态200时回复内容中包含的错误信息

4. 饱和度
   即系统资源利用率，比如内存、CPU、IO带宽、磁盘利用率

监控方式

黑盒监控 是面向现象的，代表了目前正在发生的—而非预测会发生的—问题，即“系统现在有故障”。如以用户的角度检测DNS故障、系统存活状态。
白盒监控 则大量依赖对系统内部信息的检测，如系统日志、抓取提供指标信息的HTTP节点等。

两种方式的区别：白盒是对系统内部状态进行检测，黑盒是在系统外部对系统可提供的服务进行检测。

减少监控误报

当为监控系统和警报系统增加新规则时，回答下列问题可以帮助减少误报：

1. 该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的，并且即将发生或者已经发生的用户可见故障？
2. 是否可以忽略这条警报？什么情况可能会导致用户忽略这条警报，如何避免？
3. 这条警报是否确实显示了用户正在受到影响？是否存在用户没有受到影响也可以触发这条规则的情况？例如测试环境和系统维护状态下发出的警报是否应该被过滤掉。
4. 收到警报后，是否要进行某个操作？是否需要立即执行该操作，还是可以等到第二天早上再进行？该操作是否可以被安全地自动化？该操作的效果是长期的，还是短期的？
5. 是否也会有其他人收到相关的紧急警报，这些紧急警报是否是不必要的？

以上这些问题其实反映了在应对紧急警报上的一些深层次的理念：

1. 每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。
2. 每个紧急警报都应该是可以具体操作的。
3. 每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要一个固定的机械动作，那么它就不应该成为紧急警报。
4. 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。