皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

如何理解分布式系统的指标和警报

作者 Beining

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

转自 http://www.infoq.com/cn/news/2017/09/Metrics-alerts-distributed-syste

分享到:更多 ()