《数据中心设计与运营实战》——2.6 监控基础设施

本节书摘来自异步社区《数据中心设计与运营实战》一书中的第2章，第2.1节,作者： 【美】luiz andré barroso , 【美】jimmy clidaras , 【瑞士】urs hölzle 更多章节内容可以访问云栖社区“异步社区”公众号查看。

各种形式的系统内控是集群级基础架构软件层的一个重要部分，因为无论是工作负载还是硬件基础架构，其规模和复杂性都决定了监控框架应成为系统最基本组成部分，如接下来的内容所阐述的。

2.6.1 服务级仪表盘

系统操作员需要监测互联网服务是否达到设定的服务水平。监测信息必须是非常即时的，这样操作员（或自动系统）才能以秒（而不是分钟）为单位采取快速准确的反应以避免巨大的灾难。幸运的是，监测只需要有限的几个关键信息，例如延迟、用户需求的吞吐量分析，这些都可以从前端服务器收集到。这样的监测系统简单说就是一个脚本文件，每隔几秒收集所有前端服务器的适当信息，并发送到系统操作员的仪表盘上。由于大规模服务的前端信息数量可能是很大的，而且也需要大量的信息来验证服务正常运行，因此需要更加成熟的和可扩展的监测支持。例如，不但收集到的信息本身很重要，信息随时间产生的变化也相当重要。再比如，系统也会需要监测延迟和吞吐量以外的其他特定的业务参数。监测系统可能还需要支持一种简单的语言，让系统操作员在监测到的基础信息的基础上生成衍生参数。

最后，系统还需要根据监测到的数据和阀值进行自动报警，呼叫操作员。不过要想让报警系统达到完美并非易事，因为如果误报太频繁有可能使操作员忽略了真正的报警；但如果只在极端情况时才触发报警，则有可能耽误了解决问题的最佳时机。

2.6.2 性能调试工具

虽然服务级仪表盘可以使操作员快速识别服务层的问题，但却缺乏问题的详细信息以了解服务变慢或者无法满足要求的原因。运维人员和服务设计人员都需要一些工具的帮助以了解运行在数百台服务器上的许多程序间的复杂关系，使他们能确定性能异常的根本原因，并找出瓶颈。不同于服务级仪表盘，性能调试工具不需要为在线运行产生实时信息。可以把它看成是一个数据中心的模拟cpu分析器，用来确定哪些功能调用导致了大部分的程序时间开销。

分布式系统跟踪工具可以满足上述需要。这些工具模拟某一发起者（例如一个用户请求），跟踪一个分布式系统内的所有工作过程，并详细列出所涉及的各组成部分之间的因果或时间关系。

分布式系统跟踪工具的实现方式分两大类：黑盒监控系统和应用/中间件仪表系统。wap5【128】和sherlock【11】系统就属于黑盒监控工具。这种系统采用的方法包括观测系统组件间网络流量和通过统计推断方法推断因果关系。这种方法把所有系统组件（除了网络接口）都看作为黑盒子，因此优势在于不需要任何对应用或软件基础架构部件的了解或辅助就能工作。不过这种方式牺牲了信息的准确性，因为所有的关系都是通过统计推断出来的。收集和分析更多的消息数据可以提高准确性，但却造成监管开销的增加。

基于工具的跟踪系统，例如pip 【127】、magpie 【15】和x-trace 【54】，利用显式修改应用或中间件函数库的能力可用来传递被追踪的跨机器组信息及机器组内跨边界跨模块的信息。带注释的应用模块通常也在本地硬盘记录追踪信息，后续由外部的性能分析程序收集。这些系统很准确，因为它们不需要推理，但要求分布式系统的所有部件能支持通过指令收集全面的追踪数据。google开发的dapper【141】系统就是一个基于注解的追踪工具实例，通过指令关联所有应用的一些关键模块，如消息、控制流和线程库，来对应用级软件保持有效的透明。

基于硬件性能计数器采样的cpu分析器已经在帮助程序员理解微架构的性能和现象方面取得了显著的成功。google wide profiling（gwp）基础架构【125】选择随机一组机器来收集短期的整机和每个进程配置文件的数据，并结合所有google二进制符号特征信息库，生成集群范围的配置文件视图。gwp回答了诸如“哪个程序是google最常执行的？”以及“哪个程序是内存的最大用户？”等问题。

2.6.3 平台层监控

分布式系统追踪工具和服务级仪表盘都能对应用的健康及性能进行检测。这些工具可以推断出一个硬件组件可能发生错误，但这仍然属于间接评估。而且由于集群级基础架构和应用级软件的设计都是硬件容错的，在这个级别进行监控将错失大量的底层硬件细节问题，可能累积至软件容错无法处理，导致严重的服务中断。持续和直接监测计算平台健康的工具需要能理解和分析硬件和系统软件的故障。我们会在第7章详细讨论这些工具以及这些工具在google基础架构上的应用。