跳转至

指标物语

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

延迟

服务处理某个请求所需要的时间,通常会区分为2个请求: successfailed

例如:某个由于数据库连接丢失或后端问题造成 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热点,又不需要为此付出高额成本进行收集和保留高精确数据。

简化指标,直到山穷水尽

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

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

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