许多监控框架的重点都是故障检测，即检测是否发生了特定的系统事件或处于什么状态（这是Nagios的风格）。当收到有关特定系统事件的通知时，我们通常会查看收集到的任何指标，以找出发生的确切情况及其原因。在这个思路下，指标被视为故障检测的副产品或者补充。
正确使用指标可以提供基础设施的动态实时信息，帮助你管理和做出有关系统的最佳决策。此外，通过异常检测和模式分析，指标有可能在故障或问题发生之前，或者是在特定系统事件导致系统瘫痪之前就有所察觉。
我们通常以固定的时间间隔收集数据，该时间间隔被称为颗粒度（granularity）或分辨率（resolution），取值可以从1秒到5分钟，甚至到60分钟或更长。正确地选择指标的颗粒度至关重要，若选择得太粗糙，则很容易错过某些细节。
第一种指标类型是测量型（gauge），这种类型是上下增减的数字，本质上是特定度量的快照。常见的监控指标如CPU、内存和磁盘使用率等都属于这个类型。
第二种类型是计数型（counter），这种类型是随着时间增加而不会减少的数字。虽然它们永远不会减少，但有时可以将其重置为零并再次开始递增。应用程序和基础设施的计数型示例包括系统正常运行时间、设备收发包的字节数或登录次数。
第三种类型直方图（histogram）是对观察点进行采样的指标类型，可以展现数据集的频率分布。将数据分组在一起并以这样的方式显示，这个被称为“分箱”（binning）的过程可以直观地查看数值的相对大小。
USE是使用率（Utilization）、饱和度（Saturation）和错误（Error）的缩写，该方法是由Netflix的内核和性能工程师Brendan Gregg开发的。USE方法建议创建服务器分析清单，以便快速识别问题。
USE方法可以概括为：针对每个资源，检查使用率、饱和度和错误。该方法对于监控那些受高使用率或饱和度的性能问题影响的资源来说是最有效的。
资源：系统的一个组件。在Gregg对模型的定义中，它是一个传统意义上的物理服务器组件，如CPU、磁盘等，但许多人也将软件资源包含在定义中。
使用率：资源忙于工作的平均时间。它通常用随时间变化的百分比表示。
饱和度：资源排队工作的指标，无法再处理额外的工作。通常用队列长度表示。
错误：资源错误事件的计数。
Google的四个黄金指标主要关注的不是系统级的时间序列数据，更多是针对应用程序或面向用户的部分：
延迟：服务请求所花费的时间，需要区分成功请求和失败请求。例如，失败请求可能会以非常低的延迟返回错误结果。
流量：针对系统，例如，每秒HTTP请求数，或者数据库系统的事务。
错误：请求失败的速率，要么是HTTP 500错误等显式失败，要么是返回错误内容或无效内容等隐式失败，或者基于策略原因导致的失败——例如，强制要求响应时间超过30ms的请求视为错误。
饱和度：应用程序有多“满”，或者受限的资源，如内存或IO。这还包括即将饱和的部分，例如正在快速填充的磁盘。
要建立一个出色的通知系统，需要考虑以下基础信息：
- 哪些问题需要通知
- 谁需要被告知
- 如何告知他们
- 多久告知他们一次
- 何时停止告知以及何时升级到其他人
