如何做好分布式系统的监控
Google的SRE团队在构建监控系统和报警系统方面遵循一些核心思想和最佳实践。本章在决定何时需要人工干预（发出紧急警报）的问题上提供了一些指导意见，同时也讨论了如何应对那些不那么严重的警报。在讨论监控系统时，目前几乎没有通用的术语。即使在 Google内部，不同的团队也在使用不同的术语，以下是绝大部分通用的术语。
监控（monitoring）收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和类型，错误的数量和类型，以及处理用时，应用服务器的存活时间等。
白盒监控（white-box monitoring）依靠系统内部 的一些性能指标进行监控。包括日志分析、Java 虚拟机提供的监控接口，或者一个列出内部统计数据的 HTTP接口进行监控。
黑盒监控（black-box monitoring）通过测试某种外部用户可见的系统行为进行监控。
监控台页面（dashboard）提供某个服务核心指标一览服务的应用程序（一般是基于Web的）。该应用程序可能会提供过滤功能（fiter）、选择功能（selector）等，但是最主要的功能是用来显示系统最重要的指标。该程序同时可以显示相应团队的一些信息，包括目前工单的数量、高优先级的 Bug列表、目前的on-call工程师和最近进行的生产发布等。
警报（alert）目标对象是某个人发向某个系统地址的一个通知。目的地可以包括工单系统、E-mail地址，或者某个传呼机。相应的，这些警报被分类为∶工单、E-mail警报"'，以及紧急警报（page）。
根源问题（root cause）指系统（软件或流程）中的某种缺陷。这个缺陷如果被修复，就可以保证这种问题不会再以同样的方式发生。某一个故障情况可能同时具有多个根源问题∶例如，有可能自动化程度不够，软件在异常输入下崩溃，以及对生成配置文件的脚本测试不足等。这里每一个因素都是一个根源问题，并且每一个都需要被修复。
节点或者机器（node/machine）这里的两个术语是可以互换的∶指在物理机、虚拟机，或者容器内运行的某个实例。某个单独的物理机器上可能有多个服务需要监控，这些服务可能具有如下特点。
● 相互关联的服务∶例如 Web 服务器与对应的缓存服务器。● 不相关的服务，它们仅仅共享硬件∶例如代码仓库和把文件存放在代码仓库中的配置管理系统的主进程。例如Puppet（ /puppet/puppet-open-source）和 Chef（ /chef/）。
推送（push）关于某个服务正在运行的软件或者其配置文件的任何改动。
页:
[1]