随着数据中心的增长和管理人员的缩减，对计算资源使用有效监视工具的需求变得比以往更加迫切。术语监视 在应用到数据中心时可能会让人混淆，因为它的含义会根据具体的说话者和听众而有所不同。例如：
在集群中运行应用程序的人员会思考：“我的作业什么时候运行？它什么时候会完成？以及与上一次相比，它是怎样执行的？” 网络运营中心（NOC）的操作员会思考：“什么时候会出现表示需要解决问题的红灯并安排服务电话？” 系统工程部的人员会思考：“我们的机器如何执行？所有服务是否运行正常？我们可以看到哪些趋势以及如何更好地利用计算资源？”面对如此多的定义，您必须查找大量的代码才能监视您真正想要监视的内容，不仅如此，还存在无数的产品和服务。可是幸运的是，许多监视工具都是开源的 —— 实际上，某些开源工具的表现比尝试完成同样工作的某些商业应用程序还要好。
使用开源监视工具最困难的部分是实现适合环境的安装和配置。使用开源监视工具的两个主要问题是：
没有一个工具可以按照期望的方式监视所需的所有内容。为什么？因为不同的用户将以不同的方式定义监视（正如我刚才所述）。 由于存在第一个问题，因此要让工具完全按照期望在数据中心中工作可能需要完成大量自定义。为什么？因为不管多么地标准，每一个环境也都是独一无二的。顺便说一句，商业监视工具也同样存在这两个问题。
因此，我将介绍 Ganglia 和 Nagios，这是两个用于监视数据中心的工具。这两个工具被大量用于高性能计算（HPC）环境中，但是它们对于其他环境也具有很大的吸引力（例如云、呈现集群和托管中心）。此外，两者对监视的定义也采取了不同的侧重点。Ganglia 更多地与收集度量数据并随时跟踪这些数据有关，而 Nagios 一直致力于成为一种报警机制。
随着独立项目的发展，逐步出现了交叠。例如：
Ganglia 过去要求代理运行在每台主机上以从中收集信息，但是现在可以通过 Ganglia 的欺骗机制获得度量数据。 Nagios 过去也是仅用于从目标主机中轮询信息，但是现在提供了在目标主机上运行代理的插件。虽然这些工具在某些功能领域里已经发生交叠，但是两者之间还是有许多不同之处，可以让您从运行这两个工具中获益。同时运行两个工具可以相互弥补不足：
Ganglia 没有内置通知系统，而 Nagios 在这方面表现杰出。 Nagios 似乎没有适合目标主机的可伸缩内置代理（这是一个争议点），而 Ganglia 在设计之初就考虑到这点。还有其他开源项目也可以完成这两个工具完成的工作，并且有些项目在某些领域做得比其他项目好。常用开源监视解决方案包括 Cacti、Zenoss、Zabbix、Performance Copilot（PCP）和 Clumon（而且我相信您已经有了自己喜欢的选择）。这些工具（包括 Ganglia 和一些 Nagios 插件）中的许多工具在底层都使用了 RRDTool 或 Tobi Oetiker 的 MRTG（Multi Router Traffic Grapher），以生成漂亮的图形和存储数据。
尽管用于监视数据中心的开源解决方案如此众多，我却经常惊讶地发现许多向外扩展的计算中心在开发自己的解决方案，而忽略其他人已经完成的工作。
在这个两部分文章中，我将讨论 Ganglia 和 Nagios，因为有一些事实证据表明这些工具是最常用的。尽管将两者集成在一起是非常普遍的实践（尤其是在一些大型的 HPC 实验室和大学里），但是我发现很少有文章对此进行介绍。
学完本系列，您应当能够安装 Ganglia 并与 Nagios 绑定在一起，并且可以回答不同的用户组向您询问的监视问题。这只是一个开始，但是应当可以帮助您了解基础知识并逐步把握集群的整体情况。
在本文中，我将指导您完成：
我们的目标 —— 设置 HPC Linux® 集群的基准监视系统，在其中可以在某个程度上解决上面所述的三个不同监视意图：
应用程序人员可以看到队列的排队情况如何，并可以看到运行作业的可用节点。 NOC 可以收到系统故障报警或者在 Nagios Web 界面上看到一个闪亮的红色错误指示灯。如果节点出现故障或者温度过高，他们也可以通过电子邮件收到通知。 系统工程师可以绘制数据曲线图、报告集群利用情况并决定未来采购哪些硬件。Ganglia 是 UC Berkeley 发起的一个开源监视项目，设计用于测量数以千计的节点。每台计算机都运行一个收集和发送度量数据（如处理器速度、内存使用量等）的名为 gmond 的守护进程。它将从操作系统和指定主机中收集。接收所有度量数据的主机可以显示这些数据并且可以将这些数据的精简表单传递到层次结构中。正因为有这种层次结构模式，才使得 Ganglia 可以实现良好的扩展。gmond 带来的系统负载非常少，这使得它成为在集群中各台计算机上运行的一段代码，而不会影响用户性能。
所有这些数据收集会多次影响节点性能。网络中的 “抖动（Jitter）” 发生在大量小消息同时出现时。我们发现通过将节点时钟保持一致，就可以避免这个问题。
