John Corrigan在他的文章中对分布式系统的指标和警报进行了提纲挈领的分析。

分布式系统的指标和警报允许运维人员检测分布式系统的故障，并帮助他们快速诊断出错位置。

指标

指标是按特定时间间隔收集的系统信息；指标存储后可以进一步处理，例如进行可视化或触发警报等。

作者认为，指标可以分为3类：输入指标、输出指标和过程指标。

输入指标对系统的入口进行度量，例如，用户请求数、请求的某个特征（资源/项目/产品）的数量，以及请求的来源、数据包大小等。 输出指标对系统的输出进行度量，例如，成功订单数、不成功订单数、大家关心的用户请求响应时间等。好的输出指标可以近似为每分钟系统赚取的利润。过程指标对系统内部操作进行度量，例如平均负载、可用内存、可用磁盘空间、可用inode数等，也可以对某个程序进行度量，例如某个API的重试次数等。

作者指出，有时指标间没有明确的界限：以HTTP代码为例，2xx和5xx代码是输出指标，4xx一般是输入指标，但是如果错误是对之前请求的数据进行操作后造成的，也可以当做输出指标。3xx的类别完全取决于应用程序。在多个模块、组件、服务等组成的大型系统中，每个模块都可以有自己的3种指标。

作者认为，各个指标的用途不同：输出指标代表问题是否存在以及确定问题的严重程度；输入指标可以指出问题的位置是本系统还是上游系统；一旦确定故障点，可以通过过程指标深入了解问题。

作者强调，所有的指标都应该定期汇总，而且应当可以快速反映问题。好的指标在运行正常时不会出现波动，在出现问题时应反应灵敏。

警报

如果出现故障，系统应该报警：某个指标出现了异常的变化。

作者对警报进行了分级：

SEV 1：故障如果不及时处理会严重影响业务连续性，造成大量利润损失或者违反法律法规 SEV 2：故障会影响业务，例如订单成功率下降10%，客户响应慢了10倍，导致部分员工不能工作等 SEV 3：故障导致系统出现严重问题，例如服务器严重过载，部分请求出现错误，但是不影响业务，输出看起来比较正常 SEV 4：故障导致了一些异常但不严重

作者认为，对警报相对应的反应是：

SEV 1：呼叫整个团队，立即组织人马处理，开始公关，迅速debug，申请大量资金。这种情况下最好不需要大量人手处理 SEV 2：呼叫有权限和经验的相关人员，将debug作为最高优先事项 SEV 3：在Slack上记录或开工单，尽快解决问题 SEV 4：除非资源足够否则不干预，更多关注的是导致这种事件的数量、频率等指标：这些深层次问题可以成为SEV 3事件

总结

作者总结道，整个系统需要至少一个输出指标，最好是每分钟赚取利润的近似值：例如，每分钟投放的广告、每分钟的页面展示数、每分钟的流量、每小时上传的图片等。在响应中包含用时也是好办法。

作者对数据的理解是：对于汇总指标，例如某些值的总和或平均值以及客户请求的平均延迟，应该生成数个指标。记得要记录指标包含的数据点数量，也可以考虑包括分位数（p0、p25、p50、p75、p90、p99和p100等）。有时，众数和中位数也有用。如果输入值呈正态分布，指标应包括标准差。

作者指出，对于SEV 1和SEV 2事件应当提供可预见的警报：

指标干净，不会被随机噪声淹没。在更长的时间内进行平均处理有可能可以降低噪声，也可以动态修改平均值； 影响显著，不能由噪音引起； 必须人为干预才能恢复，对于短时间自动恢复的问题不需要呼叫人员； 和故障强相关的时序指标，例如，MySQL的历史列表不断加长在几个小时后几乎一定会演变为故障。指标与故障的相关性必须极强，以免造成告警疲劳。在SEV 2 的情况下，如果故障概率是50%而工程师在睡觉，那么可以等到故障发生时再进行呼叫。

作者提醒，如果某台主机出现负载、CPU占用、磁盘空间、内存空间等指标报警，考虑是否出现架构弱点：不要为此设置警报，在此之前就把冗余和灾备做好。

查看英文原文：Operational Metrics and Alerts for Distributed Software Systems