让查询来得更猛烈些吧，让寻呼机永远保持沉默!

—— SRE 谚语

监控，处于整个生产环境需求金字塔模型的最底层。监控是运营一个可靠的稳定服务不│可缺少的部分。服务运维人员依靠监控数据对服务的情况做出理性判断，用科学的方法应对紧急情况。同时，监控数据也可以用来确保服务质量与产品目标保持一致（参见第6章）。

不管一个服务目前是否由 SRE 运维，该服务都应该建立起对应的监控系统。SRE由于长期负责保障 Google生产环境的运维，对支撑监控系统的基础设施非常了解。

监控一个大型系统本身是一项非常具有挑战性的工作∶

● 大型系统中组件数量特别多，分析工作繁杂繁重。

● 监控系统本身的维护要求必须非常低。

Google的监控系统不仅要分析一些简单的系统指标（比如一台在欧洲 Web服务器的平均响应时间），还需要分析更高抽象级别的指标（例如整个欧洲地区 Web服务器的响应时间分布情况）。这类更高级的抽象指标可以帮助我们寻找导致延迟长尾效应的问题所在。

在我们这种系统部署规模下，任何一个单机问题的报警都没有任何意义，因为这样的报警发生的次数太频繁，没有任何可操作性。我们采用的是另外一套方法∶设计我们运维的系统使其能够更好地应对所依赖系统的故障。一个大型系统不应该要求运维人员持续关注其中使用的无数个小组件，而是应该自动汇总所有的信息，自动抛弃其中的异常情况。监控系统应该主要从高级服务质量目标层面进行报警，但是也应该保持足够的粒度，可以追踪到某个具体组件。

Google 的监控系统经过10 年的发展，从传统的探针模型（使用脚本测试，检查回复并且报警）与图形化趋势展示的模型已经演变为一个新模型。这个新模型将收集时间序列信息作为监控系统的首要任务，同时发展了一种丰富的时间序列信息操作语言，通过使用该语言将数据转化为图表和报警取代了以前的探针脚本。

Borgmon 的起源

在Google的任务管理系统 Borg（参见文献【ver15】）2003年面世之后不久，工程师就创造了一个新的监控系统，Borgmon。

Google之外的时间序列监控系统

这一章描述了Google内部使用了10年的监控工具的架构和编程接口。但是读者们一定想知道在 Google 外部如何使用它呢?

近年来，监控系统也经历了一次类似神武纪生物系统大爆炸的爆发式增长∶Riemann、Heka、Bosun、Prometheus 都是开源软件中与 Borgmon 基于时间序列数据报警理念类似的系统。Prometheus注'与 Borgmon十分类似，尤其是当你对比其中的规则计算语法时。变量收集和规则计算的理念在所有这些项目中都很类似。希望借助这些工具，读者可以自行试验、部署本章内描述的一些想法。

Borgmon 不使用特定的脚本来判断系统是否正常工作，而是依靠一种标准数据分析模型进行报警。这就使得批量、大规模、低成本的数据收集变得可能，而且不需要执行复杂的子进程以及建立特殊的网络连接。我们将这种监控称之为白盒监控（参见第6章，有关"白盒监控"和"黑盒监控"的对比）。

收集回来的数据同时用来渲染图表和报警。报警规则用简单的数学表达式形式表达。因为数据收集过程不再是一个短暂的一次性过程，所有收集回来的数据历史都可以被用来作为报警规则的计算元素。

这些功能满足了第6章提到的简单性要求。它们使得整个监控系统的运行维护成本很低，从而可以保障运维服务人员有精力和资源应对服务规模的扩大以及部署变更带来的监控系统的调整。

为了更好地进行批量收集工作，我们为监控指标制定了一个标准格式。利用对varz的一次HTTP请求，我们就可以收集到一个监控对象的所有监控指标。例如，如果想要查看 webserver 的所有监控指标，可以使用如下命令∶

% curl [ ttp://webserver/varz]http://webserver:80/varz[/url]

http_requests37

errors_total12

Borgmon也可以从其他Borgmon实例上收集信息，所以我们可以建立起一套和服务部署模型类似的层级体系。这样我们就可以逐级汇总监控指标，同时在每一级抛弃无用的信息。一般来说，运维团队在每个集群中会运行一个Borgmon实例，在全球范围（global）内再运行两个对等的 Borgmon 实例。

一些部署规模非常大的服务甚至在集群内部部署了一些专门收集信息的 Borgmon 实例（scraper），这些实例用于收集信息，而集群实例则用于汇总。

让查询来得更猛烈些吧，让寻呼机永远保持沉默!

—— SRE 谚语

监控，处于整个生产环境需求金字塔模型的最底层。监控是运营一个可靠的稳定服务不│可缺少的部分。服务运维人员依靠监控数据对服务的情况做出理性判断，用科学的方法应对紧急情况。同时，监控数据也可以用来确保服务质量与产品目标保持一致（参见第6章）。

不管一个服务目前是否由 SRE 运维，该服务都应该建立起对应的监控系统。SRE由于长期负责保障 Google生产环境的运维，对支撑监控系统的基础设施非常了解。

监控一个大型系统本身是一项非常具有挑战性的工作∶

● 大型系统中组件数量特别多，分析工作繁杂繁重。

● 监控系统本身的维护要求必须非常低。

Google的监控系统不仅要分析一些简单的系统指标（比如一台在欧洲 Web服务器的平均响应时间），还需要分析更高抽象级别的指标（例如整个欧洲地区 Web服务器的响应时间分布情况）。这类更高级的抽象指标可以帮助我们寻找导致延迟长尾效应的问题所在。

在我们这种系统部署规模下，任何一个单机问题的报警都没有任何意义，因为这样的报警发生的次数太频繁，没有任何可操作性。我们采用的是另外一套方法∶设计我们运维的系统使其能够更好地应对所依赖系统的故障。一个大型系统不应该要求运维人员持续关注其中使用的无数个小组件，而是应该自动汇总所有的信息，自动抛弃其中的异常情况。监控系统应该主要从高级服务质量目标层面进行报警，但是也应该保持足够的粒度，可以追踪到某个具体组件。

Google 的监控系统经过10 年的发展，从传统的探针模型（使用脚本测试，检查回复并且报警）与图形化趋势展示的模型已经演变为一个新模型。这个新模型将收集时间序列信息作为监控系统的首要任务，同时发展了一种丰富的时间序列信息操作语言，通过使用该语言将数据转化为图表和报警取代了以前的探针脚本。

Borgmon 的起源

在Google的任务管理系统 Borg（参见文献【ver15】）2003年面世之后不久，工程师就创造了一个新的监控系统，Borgmon。

Google之外的时间序列监控系统

这一章描述了Google内部使用了10年的监控工具的架构和编程接口。但是读者们一定想知道在 Google 外部如何使用它呢?

近年来，监控系统也经历了一次类似神武纪生物系统大爆炸的爆发式增长∶Riemann、Heka、Bosun、Prometheus 都是开源软件中与 Borgmon 基于时间序列数据报警理念类似的系统。Prometheus注'与 Borgmon十分类似，尤其是当你对比其中的规则计算语法时。变量收集和规则计算的理念在所有这些项目中都很类似。希望借助这些工具，读者可以自行试验、部署本章内描述的一些想法。

Borgmon 不使用特定的脚本来判断系统是否正常工作，而是依靠一种标准数据分析模型进行报警。这就使得批量、大规模、低成本的数据收集变得可能，而且不需要执行复杂的子进程以及建立特殊的网络连接。我们将这种监控称之为白盒监控（参见第6章，有关"白盒监控"和"黑盒监控"的对比）。

收集回来的数据同时用来渲染图表和报警。报警规则用简单的数学表达式形式表达。因为数据收集过程不再是一个短暂的一次性过程，所有收集回来的数据历史都可以被用来作为报警规则的计算元素。

这些功能满足了第6章提到的简单性要求。它们使得整个监控系统的运行维护成本很低，从而可以保障运维服务人员有精力和资源应对服务规模的扩大以及部署变更带来的监控系统的调整。

为了更好地进行批量收集工作，我们为监控指标制定了一个标准格式。利用对varz的一次HTTP请求，我们就可以收集到一个监控对象的所有监控指标。例如，如果想要查看 webserver 的所有监控指标，可以使用如下命令∶

% curl [ ttp://webserver/varz]http://webserver:80/varz[/url]

http_requests37

errors_total12

Borgmon也可以从其他Borgmon实例上收集信息，所以我们可以建立起一套和服务部署模型类似的层级体系。这样我们就可以逐级汇总监控指标，同时在每一级抛弃无用的信息。一般来说，运维团队在每个集群中会运行一个Borgmon实例，在全球范围（global）内再运行两个对等的 Borgmon 实例。

一些部署规模非常大的服务甚至在集群内部部署了一些专门收集信息的 Borgmon 实例（scraper），这些实例用于收集信息，而集群实例则用于汇总。