分布式系统应该监控哪4 个黄金指标
监控系统的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个黄金指标，同时在某个指标出现故障时发出警报（或者对于饱和度来说，快要发生故障时），能做到这些，服务的监控就基本差不多了。
页:
[1]