SRE指导思想之系统监控

Posted 2021-05-12 城喵

Google SRE团队在构建监控体系和报警系统方面遵循一些核心思想和最佳实践

术语

1. 监控
   收集、处理、汇总和展示系统的实时量化指标
2. 白盒监控
   依靠系统内部暴露的一些性能指标进行监控
3. 黑盒监控
   通过测试某种外部用户可见的系统进行监控
4. 监控台页面
   展示服务核心指标的应用程序
5. 警报
   目标是某个人发向某个系统（Email\短信等）的通知
6. 根源问题
   系统中的某种缺陷
7. 节点或者机器
   物理机、虚拟机或者容器内运行的代码实例
8. 推送
   关于某个服务正在运行的软件或者配置文件的任何改动（不明白这是在指哪个过程）

为什么需要监控

• 分析长期趋势
• 时间范围或者对照组的区别
• 新版本更新的影响（时间范围）
• AB测试组对照（对照组）
• 报警
• 某项东西即将出现故障
• 某项东西已经出现故障
• 服务指标展示
  控制台页面能够回答有关服务的一些基本问题，包括后面的4个黄金指标

避免狼来了效应：紧急报警会占用程序员的宝贵时间，频繁的报警会容易让人忽略掉正在发生的故障。同时无效信息太多，分析修复会变慢，故障时间增加。高效的警报系统应该提供足够的信息，并且较低的误报。

监控的作用

监控系统应该解决两个问题：

1. 现象：哪里出现了故障？
2. 原因：为什么出现故障？

这一点看起来很难啊，该如何去做呢？现象很容易发现，怎么通过现象自动发现原因，甚至直接定位到根本问题上？可能依赖于多方面的日志和指标的综合考虑

黑盒与白盒监控

黑盒监控是面向现象，代表正在发生的问题（不是即将发生的）
白盒监控大量依赖系统内部信息的检测（系统日志、指标信息），可以检测到即将发生的问题或者问题的根源。

4个黄金指标

4个最重要的指标

1. 延迟
   服务器处理某个请求（区分成功请求和失败请求）所需的时间。

2. 流量
   对系统负载进行的高层次度量指标。通常是HTTP请求数量

3. 错误
   请求失败的数量和速率。

   错误分为两种错误：显式错误如HTTP 500错误；隐式错误指HTTP状态码为200，但在响应体内包装了错误信息。前者在负载均衡上就可以检测到，后者则需要应用自身检测。

4. 饱和度
   系统中通用资源的某些具体指标的度量，如磁盘、CPU和内存等等。

长尾问题

构建监控系统时，警惕某些量化指标的平均值。如延迟平均值，可能会存在少量请求贡献了极高的延迟。
区分平均值的‘慢’和长尾值的‘慢’的一个最简单方法就是按照延迟分组计数。

度量指标选择合适精度

系统不同部分应该以不同精度进行度量

• 较长的时间精度可能会丢失少量突发的负载上升
• 较短的时间精度会增加收集、存储和分析的成本

如果监控目标需要高精度的数据，可以通过内部采样机制外部汇总的方式降低成本。

最近在思考和实践如何做系统的监控和报警，希望能借鉴到Google的一些经验。