SRE 方法论之监控设计

监控的 4 个黄金指标

《SRE：Google 运维解密》中提出，监控系统的四个黄金指标是：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。

• 延迟：服务处理某个请求所需要的时间。在微服务中通常提倡快速失败，服务不要憋着，这些延迟请求要尽快反馈给开发人员分析，这些缓慢的错误会消耗系统性能，所以需要对这些错误延迟进行长期跟踪处理。

• 流量：当前系统的数据流入流出的数据统计，用来衡量服务的承载能力，不同系统的流量有不同的含义，比如对 web 服务来说，流量指每秒的 HTTP 请求数。

• 错误：当前系统发生错误请求的数量，一般单纯看数量不太直观，经常会对错误进行计算处理，换算成错误率。

• 饱和度：饱和度用来衡量当前服务的承载能力，一般是使用率和空闲率。如果系统主要受内存影响，那就主要关注系统的内存状态，如果系统主要受限与磁盘 I/O，那就主要观测磁盘 I/O 的状态。因为通常情况下，当这些资源达到饱和后，服务的性能会明显下降。同时还可以利用饱和度对系统做出预测，比如，当前内存使用率已经达到 80% ，很快就要满了，这时就可以发出告警及时处理。

监控指标设计原则

长尾问题

假设一个 web 服务的 http 请求平均耗时为 100ms,单看这个数据觉得服务性能没问题，但可能有 1%的请求耗时超过 5s，而这 1%的请求就有可能引发用户投诉或其它风险。由于是计算的平均值而容易被忽略，最好的方法是将请求延迟分段统计。

采用合适的精度

监控数据的高频率收集、存储、分析成本很高，要根据监控对象以及监控目标合理设置监控周期、监控频率等。

减少告警误报

现在很多公司抱着“宁可错杀一万，也不能放走一个”的原则制定监控标准，这样做的后果就是运维人员疲于奔命，时间一长就会造成"狼来了"的后果。增加新的监控规则时，可以遵循以下原则：

• 收到紧急告警时，应该立即需要进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。

• 紧急告警都应该是可以具体操作的。

• 紧急告警的回复都应该需要某种智力分析过程。如果某个紧急告警只是需要一个固定的机械动作，那么它就不应该成为紧急告警。

• 紧急告警都应该是关于某个新问题的，不应该彼此重叠。

监控系统建设原则

以上关于监控指标的讨论累加起来就会形成一个复杂的监控系统。

监控系统尽量简化

复杂是没有止境的，过于复杂的监控系统维护起来麻烦，而且经常出问题。

• 那些最能反映真实故障的规则应该越简单越好。

• 那些不常用的数据收集、汇总，以及告警配置应该定时删除。

• 收集到的信息，但是没有暴露给任何监控台，或者被任何告警规则使用的应该定时删除。

监控系统应作为一个独立的系统运行

保持监控系统相对独立、清晰简单。和其他系统保持松耦合，可以采用 API 来收集性能数据。

监控系统需要长期维护

监控系统需要跟随不断演变的软件一起变化，软件经常重构，负载特性和性能目标也经常变化。现在的某个不常见的、自动化比较困难的告警可能很快就会变成一个经常触发、需要一个临时的脚本来应对的问题。这时，应该去寻找和消除背后的根源问题：如果这种解决办法不可行，那么这条告警的应对就必须要完全自动化。