指标物语¶

监控系统中的四个黄金指标，所描述的是如果我们只能监控用户可见系统的最有效的四个指标，就应该监控这四个。

延迟

服务处理某个请求所需要的时间，通常会区分为2个请求： success 与 failed。

例如：某个由于数据库连接丢失或后端问题造成 HTTP500 错误可能延迟很低. 计算总体延迟时，如果把500错误也计算在内的话，可能会产生错误性的引导。但是，慢 错误往往要比 快错误带来的影响更大，所以，监控错误的延迟至关重要。

流量

使用系统中的某个高层次的指标针对系统负载需求所进行的度量。

对web服务器来说，这个指标通常是指每秒HTTP请求数量，同时也可能会按照请求类型划分为 静态 动态

针对音频流媒体这类系统来说，指标可能是网络I/O速率，或者并发会话数量。

针对键值对存储系统来说，指标可能是每秒的交易数量或每秒的读取操作数量。

错误

请求失败的速率，要么是显示失败，例如： HTTP500，要么是隐式失败，例如： HTTP200 返回中包含的error信息；或者是策略原因导致的失败，例如：定义某个服务的策略为为在1s内必须完成的某个请求操作，任何请求操作超过1s的都视为失败；当协议内部的错误代码无法表达全部的失败错误情况时，可以利用其它信息，比如内部协议，来追踪一部分特定故障事件。

监控方式也不一样：在LB上检测 HTTP500 请求可能足够抓取到所有的完全失败的请求，但是这种故障类型，只有端到端的系统才能检测到返回错误内容。

饱和度

服务器所要消耗的资源容量的到底有多 满，通常是指系统中目前最为受限的某种资源的某个具体指标的度量。

例如内存受限的系统中，即为 内存。I/O 系统中，即为 IO。需要注意的是，大部分系统在达到100%利用率之前，性能会严重下降。增加利用率指标是至关重要的。

在复杂的系统中，饱和度可以配合其他高层次的负载度量来使用，例如：该服务是否可以正常处理俩倍的流量，是否可以应对10%的额外流量，或者甚至应对当前更少的流量？对没有请求复杂度变化的简答服务来说，例如：'返回一个随机数' 服务或者是 '返回一个自定义的唯一单向递增整数' 服务。根据负载测试中得到固定的数值可能就足够了。但是，大部分的服务都需要使用某种间接指标，例如CPU利用率，或者网络带宽来替代，因为这些指标通常都有一个固定的已知上限；

延迟增加也是饱和度的前导现象，99%的请求延迟，比如：在某一个比较小的时间范围内，例如一分钟，可以作为一个饱和度阈值预警的指标。

饱和度同时也需要进行预测，比如：MySQL可能会在在4个小时内把磁盘空间耗尽，Redis可能会在5个小时内把内存耗尽等等。

如果我们度量用这个4个指标，同时某个指标出现故障发出警报，这个指标指的是饱和度达到阈值而触发的警报，能做到到这些，服务的基本监控基本上差不多了，但是，对于多维度和立体化监控，仅仅做到这个4个指标还是远远不够的，下面，我们来讲讲其他的指标问题。

长尾问题

构建监控系统时，大部分人是倾向于采用某种量化指标的平均值：延迟平均值、各个节点的CPU平均使用率，数据库容量平均值，在后面的2个问题很明显， CPU跟数据库的利用率肯定波动很大，但是同样道理也可以应用于延迟，如果某个WEB或者APP服务每秒处理1000个请求，平均请求延迟为100ms，那么 1% 的请求可能会占用5s时间。如果用户依赖几个这样的服务渲染页面，那么某个后端请求的延迟99%可能会成为后端延迟的中位数。

区分平均值的 慢 与长尾值的 慢 ，最简单的方法就是把请求按照延迟分组计数，可以用来制作直方图：延迟为0-10ms之间的请求数是多少，30-100ms之间的请求数是多少，100-300ms之间的请求数是多少等。将直方图的边界定义为指数型增长，此处的举例说明的倍数是3，这就是直观展现请求分布的最好方式。

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

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

观察一分钟内的CPU平均负载，可能会错失导致长尾延迟过高在某种较长时间的CPU峰值现象。
对于一个每年停机维护时间小于9小时的web服务来说，每分钟检测1次或2次的监控频率都是属于频繁的。
对于目标可用率为99%的某个服务每1分钟或者2分钟检测一次磁盘剩余空间可能都是多余的。

应该仔细设计度量指标的精确度。每秒收集CPU负载信息可能会产生一些有意思的数据，但是这种高频率的收集、存储、分析可能会成本很高。如果我们监控模板需要提高精确数据，但是却不需要低级的延迟，可以通过一些内部采样机制外部汇总的方式降低成本。

当前CPU使用率按秒记录
按5%颗粒度分组，讲对应CPU使用率计数+1
将这些值每分钟汇总一次

这种方式使得我们可以观测到短暂的CPU热点，又不需要为此付出高额成本进行收集和保留高精确数据。

简化指标，直到山穷水尽

之前所有需求累加起来可能会构建成一个非常复杂的监控系统，复杂度的案例：

不同的延迟阈值，在不同的百分位上，基于各式各样的指标进行告警。
检测跟提示可能会发生的故障原因
给各种可能的原因以可视化形式展现

对于复杂一词，是没有止境的，就像软件一样，监控系统可能会变的过于复杂，以至于经常出现问题，变更非常困难，维护起来难度同样很难。