如何做好分布式系统的监控

姚明

Google的SRE团队在构建监控系统和报警系统方面遵循一些核心思想和最佳实践。本章在决定何时需要人工干预（发出紧急警报）的问题上提供了一些指导意见，同时也讨论了如何应对那些不那么严重的警报。

在讨论监控系统时，目前几乎没有通用的术语。即使在 Google内部，不同的团队也在使用不同的术语，以下是绝大部分通用的术语。

监控（monitoring）

收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和类型，错误的数量和类型，以及处理用时，应用服务器的存活时间等。

  A! s# V* G6 V5 K, i2 n/ z

白盒监控（white-box monitoring）

依靠系统内部暴露的一些性能指标进行监控。包括日志分析、Java 虚拟机提供的监控接口，或者一个列出内部统计数据的 HTTP接口进行监控。

8 }& E4 W4 l/ x2 G% `% J1 V( D; b

黑盒监控（black-box monitoring）

通过测试某种外部用户可见的系统行为进行监控。

3 b  g) n; C$ Z4 y7 O! b

监控台页面（dashboard）

提供某个服务核心指标一览服务的应用程序（一般是基于Web的）。该应用程序可能会提供过滤功能（fiter）、选择功能（selector）等，但是最主要的功能是用来显示系统最重要的指标。该程序同时可以显示相应团队的一些信息，包括目前工单的数量、高优先级的 Bug列表、目前的on-call工程师和最近进行的生产发布等。

2 {; D- D1 O1 `2 d4 `0 v6 v7 C' ^

警报（alert）

目标对象是某个人发向某个系统地址的一个通知。目的地可以包括工单系统、E-mail地址，或者某个传呼机。相应的，这些警报被分类为∶工单、E-mail警报"'，以及紧急警报（page）。

' q8 S* L- p3 [  e
& ^7 Y8 `# h2 W7 Q8 G

根源问题（root cause）

指系统（软件或流程）中的某种缺陷。这个缺陷如果被修复，就可以保证这种问题不会再以同样的方式发生。某一个故障情况可能同时具有多个根源问题∶例如，有可能自动化程度不够，软件在异常输入下崩溃，以及对生成配置文件的脚本测试不足等。这里每一个因素都是一个根源问题，并且每一个都需要被修复。

节点或者机器（node/machine）

这里的两个术语是可以互换的∶指在物理机、虚拟机，或者容器内运行的某个实例。某个单独的物理机器上可能有多个服务需要监控，这些服务可能具有如下特点。

● 相互关联的服务∶例如 Web 服务器与对应的缓存服务器。

● 不相关的服务，它们仅仅共享硬件∶例如代码仓库和把文件存放在代码仓库中的配置管理系统的主进程。例如Puppet（htps∶/puppetlabs.com/puppet/puppet-open-source）和 Chef（htps∶/www.chef.io/chef/）。

推送（push）

关于某个服务正在运行的软件或者其配置文件的任何改动。