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

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