延时（latency），流量（traffic），错误（error）和饱和度（saturation）是系统监控的4个黄金信号。如果只让你选择监控4项指标的话，就选这四个吧。
系统完成一个请求所用的时间。特别注意要分开监控成功请求的延时与失败请求的延时。例如由于丢失了数据库的链接等错误，系统非常迅速地返回一个HTTP 500给请求方，如果我们直接把这个请求响应时长纳入延迟监控指标的计算那就有点儿问题了：它毕竟是一个错误，对它的处理没有代表性。但与此同时也要注意：缓慢给出出错反馈要比迅速给出更差！所以也不能简单把出错请求排除在统计之外，它们也是值得追踪的。
这个指标用于衡量对系统的需求量，使用高层次的系统特定标准来衡量。
对于一个Web服务，这个指标往往是每秒接到的请求数，也可能按照请求的类别分开统计，例如区分针对静态的和动态内容的请求。
对于一个音频流系统，这个指标往往聚焦网络I/O或者同时存在的会话数量。
对于一个名值对存储系统，这个指标可能是每秒交易数量或读取数量。
这是指请求的失败率，这些失败可以是明确出错了 - 例如返回了HTTP 500；也可以是隐性失败 - 例如虽然返回HTTP 200但内容却不对；亦或是违背了规则 - 例如违反你的规则“请求处理时长超过1秒都会返回错误给客户端”。当协议的请求响应代码不足以表达全部失败条件时，可能需要启用内部协议来追踪部分失败情形。监控这些错误的方式千差万别：在负载均衡器上就可以很好地完成对HTTP 500类错误的抓取；但可能只有用端到端测试才能探知系统返回的内容不正确。
就是说你的服务有多么的“满”。这是一个侧重受限资源的指标 - 例如在内存密集型系统内，衡量内存；在一个I/O密集性系统内，衡量I/O。我们要注意，许多系统在资源占用达到100%之前就开始出现反应低效的情况了，所以制定一个消耗限度挺重要的。
在复杂系统中，饱和度可以作为高层次负载指标的补充：你的服务能良好处理现在两倍的流量吗？还是只能再额外处理10%，亦或是流量增加会降低处理效率？对于简单的服务来说，它没有提供什么参数让请求可以影响到对处理的复杂度，那么通过静态的压力测试就可以知道系统随着负载的增加将表现如何；但绝大多数服务没这么简单，需要依赖CPU、网络带宽等有明确上限的资源所发出的信号去做出判断。处理的延迟往往是饱和度在增加的首要信号，在一个短时间窗口内（例如1分钟），统计99%请求的处理时间可以给出一个较早的系统饱和信号。
最后，饱和度指标在预测系统即将饱和上也很有用处，例如“看起来你的数据将在4小时后写满磁盘“。
如果你可以量化所有四个黄金信号，当一个信号报警时（如果是饱和度，不必真正出问题才报，只要预测快要出问题就报）去通知负责人，那就意味着你的服务具被很好地监控着。