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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1305|回复: 0

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

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

延迟
服务处理某个请求所需要的时间。这里区分成功请求和失败请求很重要。例如,某个由于数据库连接丢失或者其他后端问题造成的HTTP 500错误可能延迟很低。计算总体延迟时,如果将500回复的延迟也计算在内,可能会产生误导性的结果。但是,"慢"错误要比"快"错误更糟! 因此,监控错误回复的延迟是很重要的。

流量
使用系统中的某个高层次的指标针对系统负载需求所进行的度量。对 Web服务器来说,该指标通常是每秒HTTP请求数量,同时可能按请求类型分类(静态请求与动态请求)。针对音频流媒体系统来说,这个指标可能是网络I/O速率,或者并发会话数量。针对键值对存储系统来说,指标可能是每秒交易数量,或每秒的读取操作数量。

错误
请求失败的速率,要么是显式失败(例如HTTP 500),要么是隐式失败(例如HTTP200 回复中包含了错误内容),或者是策略原因导致的失败(例如,如果要求回复在 1s内发出,任何超过Is的请求就都是失败请求)。当协议内部的错误代码无法表达全部的失败情况时,可以利用其他信息,如内部协议,来跟踪一部分特定故障情况。监控方式也非常不一样∶在负载均衡器上检测 HTTP 500 请求可能足够抓住所有的完全失败的请求,但是只有端到端的系统才能检测到返回错误内容这种故障类型。

饱和度
服务容量有多"满"。通常是系统中目前最为受限的某种资源的某个具体指标的度量。(在内存受限的系统中,即为内存;在I/O受限的系统中,即为I/O)。 这里要注意,很多系统在达到100%利用率之前性能会严重下降,增加一个利用率目标也是很重要的。

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

最后,饱和度同样也需要进行预测,例如"看起来数据库会在4个小时内填满硬盘"。

如果我们度量所有这4个黄金指标,同时在某个指标出现故障时发出警报(或者对于饱和度来说,快要发生故障时),能做到这些,服务的监控就基本差不多了。





上一篇:监控系统应该解决两个什么问题
下一篇:度量分布式系统监控的指标时采用怎样合适的精度
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础、专家、大师级认证、长河ITIL实战沙盘、DevOps认证、ITSS服务经理认证报名
ITIL(R) is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. The Swirl logo is a trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

QQ|ITIL ( 粤ICP备11099876号 )|appname

GMT+8, 2023-9-26 21:44 , Processed in 0.097451 second(s), 25 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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