SRE认知之监控概述

监控

监控理念

当为监控系统和警报系统增加新的规则时，我们应该关注一下问题：

1. 该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的，并且即将发生或者已经发生的用户可见故障？

2. 是否可以忽略该警报？什么情况可能会导致用户忽略该警报，如何避免？

3. 这条警报是否确实显示了用户正在收到影响？是否存在用户没有收到影响也会触发这条规则？例如测试环境和系统维护状态下的警报是否应该被过滤掉？

4. 收到警报后，是否要进行某个操作？是否需要立即执行该操作，还是可以等到第二天早上再进行？该操作是够可以被安全地自动化？该操作效果是长期的还是临时的？

5. 是否也会有其他人收到相关的紧急警报？做这些警报是否是不必要的？

总而言之，要把握如下原则：

• 每当收到紧急警报时，应该立即需要进行某种操作。这样的警报每天只能有几次，太多就会导致敏感度降低产生的“狼来了”效应。

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

• 每个紧急警报都应该有智力分析的过程，如果只是一个机械操作，那么就不应该成为紧急警报。

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

术语定义

监控：收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和类型，错误的数量和类型，以及处理用时，应用服务器的存活时间等。

白盒监控：依靠系统内部暴露的一些性能指标进行监控。包括日志分析、Java虚拟机提供的监控接口，或者一个列出内部统计数据的HTTP接口进行监控。

黑盒监控：通过测试某种外部用户可见的系统行为进行监控。

监控台页面：提供某个服务核心指标一览服务的应用程序。该应用程序可能会提供过滤功能、选择功能等，但最重要的功能是用来显示系统最重要的指标。改程序同时可以显示相应团队的一些信息，包括目前工单的数量、高优先级的Bug列表、目前的on-caller和最近进行的生产发布等。

警报：目标对象是某个人发向某个系统地址的一个通知。目的地可以包括工单系统、E-mail地址、或某个传呼机等。相应的这些警报也被分为：工单、E-mail警报、紧急警报等。

根源问题：系统中的某种缺陷。这个缺陷如果被修复，就可以保证这种问题不再以同样的方式发生。某一个故障情况可能同时具有多个根源问题：例如，有可能自动化程度不够，软件在异常输入下崩溃，以及对生成配置文件的脚本测试不足等。

节点或机器：物理机、虚拟机或者容器内运行的某个实例。某个单独的物理机器上可能有多个服务需要监控，这些服务可能具有如下特点：

• 相互关联的服务：如Web服务器与对应的缓存服务器

• 不相关服务，他们仅仅共享硬件：如代码仓库和把文件存放在代码仓库中的配置管理系统的主进程。如salt

为什么要监控

监控一个系统有很多原因，如下：

分析长期趋势：数据库目前的数据量，以及增长速度、每日活跃用户的数量增长速度等。

跨时间范围比较，观察实验组与控制组之间的区别：比如：使用不同虚拟系统，哪个更快？新增节点后，memcache的缓存命中率是否增加？网站是否比之前速度慢？

报警：某项东西出现故障，需要被立即修复。或某项东西即将出现故障，需要有人尽快查看。

构建监控平台页面：监控台页面应该可以回答有关服务的一些基本问题，通常包含四个“黄金指标”。

临时性的回溯分析（在线调试）：我们的请求延迟刚刚大幅增加，有没有其他的现象同时发生？

现象与原因

监控系统应该解决两个问题：什么东西出故障了？以及为什么出故障了？

我们称“什么东西出故障了”为现象，称“为什么”为原因。（这里的原因不一定是根源，有可能只是中间原因）

黑盒监控与白盒监控

黑盒监控室面向现象的，即目前正在发生的事（而非预测会发生的事），属于系统现有的故障。

白盒监控大量依赖于对系统内部信息的检测，如系统日志、抓取提供指标信息的HTTP节点等。白盒监控更趋向于检测即将发生的问题和重试所掩盖的问题等。

在一个多层系统中，某一个服务的现象是另一个服务的原因。比如：数据库性能问题，数据库读取操作缓慢是数据库SRE检测到的一个现象，然而对于前端SRE来说，他们看到的是网站慢，数据库度操作缓慢则是原因。

黑盒监控可以保证系统某个问题正在发生，并且造成某个现象时才会发出紧急警报。针对没有发生的事，即使是即将发生的问题，黑盒监控也是没有用的。

4个黄金指标

监控系统的4个黄金指标分别是延迟、流量、错误和饱和度。

延迟

服务处理某个请求所需要的时间。这里区分成功和失败请求很重要。把握原则：慢错误要比快错误更糟糕！但是快错误也会产生误导性错误。

流量

使用系统中的某个高层次的指标针对系统负载需求所进行的度量。对Web服务器来说，该指标通常是每秒HTTP请求数量。

错误

请求失败的速率，可能是显式失败，有可能是隐式失败，或者策略原因导致的失败。

饱和度

衡量服务器有多“满”。通常指系统中最为受限的某种资源的某个具体指标的度量。

度量指标时采用合适的精度

系统的不同部分应该以不同的精度进行度量，例如：

• 观察一分钟内的CPU平均负载可能会错失导致长尾延迟过高的某种较长时间的CPU峰值现象。

• 对于一个每年停机时长小于9小时的Web服务来说，每分钟检测1到2次有点过于频繁。

• 对目标可用率为99.9%的某个服务每一分钟检查一次硬盘剩余空间也是没有必要的。

如果我们的监控目标需要高精度数据，但是却不需要极低的延迟，可以通过一些内部采样机制外部汇总的方式降低成本。