多种形式的系统自查是集群级软件构架的重要组成部分。工作负载和硬件构架的尺度与复杂性使得监控框架成为任何此类部署的基本组件之一。本节将对此进行详细描述。

　　1.服务级仪表盘

　　系统运维人员应该时刻监控一项Internet服务的运行状态以保证其服务级别达标。这些监控信息应该是即时更新的，这样运维人员 (或者自动化系统)才能及时 (以秒计，而不是以分钟计)采取修正措施并避免服务中断。幸运的是，最重要的信息往往只是很少的几个需要从前端服务器上收集的信号，如用户请求的延迟和带宽统计数据。一个最简单的监控系统可以仅仅只是一个脚本，这个脚本每隔几秒就从所有的前端服务器上收集所需的信号，并将其显示在仪表盘上。

　　大型服务通常需要更加复杂和可扩展的监控支持，因为前端服务器的数最可能会非常庞大，并且描述服务的运行状态也需要更多的信号。例如，只收集信号本身可能还不够，还必须要收集这些信号相对于时间的导数。监控系统可能还要监测除了延迟和带宽之外其他业务的相关参数。监控系统可能还需要支持一种简单的编程语吉，以使操作人员能够创建基于被监控基本信号的导出量。最后，监控系统可能还需要根据被监控的变量和阅值对应急运维人员发出警告。对一个报告/报警系统进行优化是件很不容易的事情。因为如果误报太多，操作员就会忽略真的警报。而如果警报只在最极端的条件下才被触发，那么可能就会使操作员在注意到警报时巳经太晚了，导致无法解决根源问题。

　　2.性能调试工具

　　虽然服务级仪表盘能够让运维人员快速识别服务级问题，但是它们常常缺乏一些运维人员分析服务运行缓慢或是不达标原因时必需的详细信息。运维人员和服务设计人员都需要一种工具便于了解大量程序之间复杂的交互关系 (这些服务有可能运行在数百台服务器上)，进而能让他们确定性能异常的根源并找出瓶颈之所在。与服务级仪表盘不同的是，性能调试工具不需要为在线操作产生实时的信息，它的功能相当于一数据中心的cpu分析器 (用来分析哪些函数调用在程序运行总时间申占得最多)。

　　曾经有人提议使用分布式系统追踪工具来满足这个需要。分布式系统追踪工具尝试从一个分布式系统中找出所有为某一发起者 (如一个用户请求)所做的工作，并且详细描述各个参与组件之间的因果或时间关系。

　　分布式系统追踪工具一般倾向于两种宽泛的分类，即黑箱监控系统和应用程序/中间件度量系统。WAP5系统【208】和 Sherlock系统[210]是典型的黑箱监控系统。它们使用的手段包括观察系统组件之间的网络流量，然后使用统计学的方法推断组件之间的因果关系。因为它们将所有的系统组件 (除了网络流量)都视为黑箱，这些手段的优点是即使不了解系统或者没有来自应用或软件构架的协助，也能工作。然而，这种手段必然会降低信息的准确性，因为组件之间的关系只能使用统计学方法推断。收集并分析更多的通信数据能够提高准确度，但随之而来的却是监控开销的增加。

　　基于度最的跟踪方案，如Pip【207】、Magpie[211]和X-trace[206]，利用了显式修改应用或中间件库的能力，以便在模块之间或机器之间传递跟踪信息。这些加过注释的模块一般都 会同时向本地磁盘记录日志信息，以便日后由外部的性能分析程序读取。因为不需要进行

　　推断，这些系统的准确性一般都相当高。但只有在一个分布式系统的所有组件都能够被度 量的前提下，这些系统才能够收集较为全面的数据。由Google开发的Dapper系统就是基于注释的跟踪系统的一个例子，这个系统通过只度最很少的几个被所有程序链接的关键模块，来达到对应用级软件几乎完全透明的效果 (即应用程序不需要做任何修改)，这些模块一般包括消息传递、控制最及线程库。

　　将获得CPU、内存及锁竞争信思的能力在开发阶段就加入程序的可执行文件 (或运行时系统)是非常有用的。这可以避免在要调查性能问题时还要重新部署新的可执行文件的烦琐。

　　3·平台级监控

　　分布式系统追踪工具和服务级仪表盘都可检测应用的性能和健康状况。这些工具可以推测某个硬件组件的工作性能，但这仍然只能是一种间接评价。此外，因为集群级构架和应用级构架都被设计成能够容忍硬件组件故障，在这些级别进行的监控可能漏掉大量的底层硬件问题;使得这些问题不断积累直到超过软件的容错能力，甚至导致服务中断。这时就需要一种能够持续直接监测硬件的工具来了解并分析硬件和系统软件的故障。

责任编辑：GOCN