请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 213|回复: 0

分布式系统应该监控哪4 个黄金指标

[复制链接]
发表于 2020-12-5 23:34:25 | 显示全部楼层 |阅读模式
监控系统的4个黄金指标分别是延迟、流量、错误和饱和度(saturation)。如果我们只能监控用户可见系统的 4个指标,那么就应该监控这 4个。

. C# {2 ^, o( `
延迟
服务处理某个请求所需要的时间。这里区分成功请求和失败请求很重要。例如,某个由于数据库连接丢失或者其他后端问题造成的HTTP 500错误可能延迟很低。计算总体延迟时,如果将500回复的延迟也计算在内,可能会产生误导性的结果。但是,"慢"错误要比"快"错误更糟! 因此,监控错误回复的延迟是很重要的。
9 a/ o# E4 A8 B1 K
流量
使用系统中的某个高层次的指标针对系统负载需求所进行的度量。对 Web服务器来说,该指标通常是每秒HTTP请求数量,同时可能按请求类型分类(静态请求与动态请求)。针对音频流媒体系统来说,这个指标可能是网络I/O速率,或者并发会话数量。针对键值对存储系统来说,指标可能是每秒交易数量,或每秒的读取操作数量。

+ A5 h$ ]& O! M0 |+ H0 T3 o
错误
请求失败的速率,要么是显式失败(例如HTTP 500),要么是隐式失败(例如HTTP200 回复中包含了错误内容),或者是策略原因导致的失败(例如,如果要求回复在 1s内发出,任何超过Is的请求就都是失败请求)。当协议内部的错误代码无法表达全部的失败情况时,可以利用其他信息,如内部协议,来跟踪一部分特定故障情况。监控方式也非常不一样∶在负载均衡器上检测 HTTP 500 请求可能足够抓住所有的完全失败的请求,但是只有端到端的系统才能检测到返回错误内容这种故障类型。
3 H0 P$ z9 ^; R5 v
饱和度
服务容量有多"满"。通常是系统中目前最为受限的某种资源的某个具体指标的度量。(在内存受限的系统中,即为内存;在I/O受限的系统中,即为I/O)。 这里要注意,很多系统在达到100%利用率之前性能会严重下降,增加一个利用率目标也是很重要的。

% h# p- Q9 L5 I* T/ G/ W- m
在复杂系统中,饱和度可以配合其他高层次的负载度量来使用∶该服务是否可以正常处理两倍的流量,是否可以应对10%的额外流量,或者甚至应对当前更少的流量?对没有请求复杂度变化的简单服务来说(例如,"返回一个随机数"服务,或者是"返回一个全球唯一的单向递增整数"服务),根据负载测试中得到的一个固定数值可能就足够了。但是正如前文所述,大部分服务都需要使用某种间接指标,例如CPU利用率,或者网络带宽等来代替,因为这些指标通常有一个固定的已知的上限。延迟增加是饱和度的前导现象。99%的请求延迟(在某一个小的时间范围内,例如一分钟)可以作为一个饱和度早期预警的指标。

/ K) \% \; E! Y% |  S7 d) C
最后,饱和度同样也需要进行预测,例如"看起来数据库会在4个小时内填满硬盘"。
0 l' I4 }* O9 M9 L# X
如果我们度量所有这4个黄金指标,同时在某个指标出现故障时发出警报(或者对于饱和度来说,快要发生故障时),能做到这些,服务的监控就基本差不多了。
. y3 Z) F- k; R4 s2 R




上一篇:监控系统应该解决两个什么问题
下一篇:度量分布式系统监控的指标时采用怎样合适的精度

本版积分规则

本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-1-22 04:27 , Processed in 0.145437 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表