你管理的服务器数量越多，你就越不太可能持续地监控好所有的服务器。系统管理员也需要休息睡觉，因此一台警惕性高的计算机就可以帮很大的忙了。它可以协助系统管理员探测系统健康状况，监测性能方面问题。

　　对于监测工具，我个人倾向于Nagios。在市场上有很多不错的监测解决方案（有些解决方案实际上就是基于Nagios的），但我一直以来都很喜欢Nagios，主要是出于它的价格（免费）、完备性还有开源等方面的考虑。

　　Nagios是开源的，其探测器具有模块化的特性，而且它的插件本身非常易于写入，也就是说，如果Nagios不能检测某个属性，我可以轻松地自己写入一个新的脚本以执行检测任务（更可能的是，别人已经写好了）。有很多第三方插件远远不止可以进行系统负载和ping检测，而且还能够进行SAN多路径处理和更高级的Apache监测。

　　在很长一段时间内，我都曾经以为Nagios只是一个监测工具。它可以探测所有服务器，如果某个服务停止或系统负载或其它数据出现异常，会发送警报。直到有一天，当我在寻找可以分析服务器性能数据趋势的解决方案时，我发现除了一些其它可以查询系统数据产品以外（如Cacti），我已经有的Nagios也可以轮询本网络中我所关心的每台服务器。我所需要做的应该是找出如何显示它收集的所有数据。

　　尽管监测服务器最重视的是那些超出正常范围的数据，不过它在每次探测时，都会收集很多有价值的数据。尽管Nagios默认下是不显示性能数据的，但它确实提供了一个收集探测所获数据的机制。要支持Nagios的性能数据收集，Nagios插件基本上只需在标准输出的基础上，额外输出性能数据即可。输出的格式非常直观，为Nagios 3.0做文档备份。插件输出性能数据后，可以对Nagios进行设置，将性能数据存放到一个某种格式的文件，以便分析使用，或者也可以将数据传送到一个第三方程序。有很多程序可以管理这些数据，不过我选用的是一个叫做PNP的程序。PNP将性能数据存储在RRD（Round-Robin Database）文件，这个文件易于用图表显示。

　　使用图表检修服务器系统性能

　　那么，使用图表（graph）显示这些数据到底有什么优点呢？图表不仅仅是为了方便厂商展示，在检查和追踪性能问题时，图表的作用也是非常大的。当你仔细阅读性能数据时会发现，所有的系统数据按照时间顺序被制成图表后，很容易就能检查出问题的所在。

　　不论你是使用Nagios和PNP还是其它图表工具，建立系统之后，你如何使用这些图表追踪性能问题呢？有时你可能很幸运，但这并不总是像找出图表的峰值那么简单。我们看一个最基本的数据例子，这很可能是你会监测并制成图表的数据：系统负载。在Linux和一些其它Unix系统中，显示的系统负载有3个数字：每1分钟、5分钟、15分钟之内的平均运行值或不间断进程数。这些数字在多CPU系统中并不像常规的那样。例如，在单CPU的机器中，平均工作量为1就意味着处理器当前处于百分之百的繁忙状态，但在双CPU的机器中，就意味着平均有一个处理器处于空闲状态。

　　然而，负载平均值中的峰值有可能会误导你。尽管找出由于高负载导致的性能问题很容易，但所有负载平均值真正告诉你的是正在运行的进程数和可能在等待的进程数。这一点很重要，一定要记住。负载平均值并不能说明进程为什么处于等待状态。有很多不同的原因会导致系统负载平均值过高，这些原因可能导致系统性能下降。

　　负载平均值过高的最简单的原因很可能是系统中进程数太多，其中很多进程会占用全部的CPU资源。如果所有的CPU当前都处于完全繁忙的状态，并有新的进程增加，那么每个新增的进程就不得不等待CPU资源。CPU密集型的（CPU-bound）负载有时表现很有趣。根据等待进程中CPU利用较大的进程数不同，系统有可能负载很高，但仍然反应相对灵敏。我见过有的系统有几百个CPU密集型负载，但仍然可以登入检查性能而不会有麻烦。我也见过有的系统负载占用CPU相对较低，却陷入停顿。因为同时运行的负载太多，导致CPU完全被占用。高负载还可能有一个原因，经常是由I/O瓶颈引起的。当进程之间竞争同一磁盘资源时，有些进程就不得不等待。而且在磁盘I/O高峰时，等待的进程队列可能越来越长。以我个人的经验，I/O密集型的负载可能导致系统更加迟缓。I/O密集型负载在负载平均值相对较低的情况下，甚至要比CPU密集型的负载运行还要缓慢。

　　由于负载过高的原因有很多种，有时可以做一些调查性工作，追踪最根本的原因。然而，好的图表工具通常会帮助你更快更准确地找出原因。例如，我监测系统和制图表时有一些测量指标：负载平均值、RAM和数据交换区（swap）使用率、每个峰值点的磁盘I/O和网络I/O。将这些数据制成图表后，你可以轻松地看出负载峰值与其它指标峰值是否具有相关性。如果负载很高时磁盘I/O并不高，那么负载很可能就是CPU密集型的。如果高负载与高磁盘I/O相关，那么就可以肯定负载是磁盘I/O密集型的。如果还发现在负载峰值之前的RAM使用与系统swap一起增加，那么我预感高负载很可能是由于系统用完RAM而依赖于swap所导致的。而且，这还会进一步导致磁盘I/O增加。

　　使用图表追踪性能问题还有一个更大的好处，就是你可以在事后再追踪问题。由于某些原因，有时你无法访问一台正在经历性能问题的机器。等到你收到警报再登陆系统时，可能一切又恢复正常了。很多时候，我可以将图表中的性能问题原因拼凑起来。在图表中，通过系列的磁盘高峰和网络通信高峰，我可以看出每天的备份工作是什么时候完成。在查找性能迟缓原因时，如果需要排除备份工作的可能性，有了这个信息会特别方便。看一眼就知道了，而不必去查阅备份日志文件。

　　随着时间的推移，监测还可以为趋势分析提供一个很好的基础。无论是复杂的数据（如，在高峰期，web服务器使用的Apache进程逐渐增加，以及如何随着RAM使用变化而变化）还是简单的数据（如，几个月内数据库使用磁盘空间情况），良好的图表工具可以为你自动提供数据报告。如果没有这样的工具，你将不得不把精力都耗费在枯燥的数据收集和手动绘制图表上了。另外，合理的组织好这些数据后，可以更轻松地找出各种系统的峰值之间的联系。

　　良好可靠的监测工具结合自动图表绘制和趋势分析工具，这使得耗时枯燥的数据收集和性能瓶颈追踪工作变得简单易行起来。如果你的停机时间是以美元计算的，你就一定要利用这些工具的优势，以便准确快捷地找出性能问题。另外，下次在经理面前做展示时，你还可以利用到它别致的图表外形。

　　关于作者：Kyle Rankin是旧金山湾区的一个系统管理员，已出版多本著作，其中包括O'Reilly Media出版的《Knoppix Hacks》和《Ubuntu Hacks》。