企业服务器对于企业业务持续性意义重大，系统管理员需要密切关注企业服务器以确保一切正常运行。当发现问题的时候，他们需要知道问题开始出现时的状况，因此调查可以重点放在问题出现的时候，这就意味着定期记录信息以及快速分析信息数据是很必要的，本文将介绍几个web界面的服务器检测工具。

　　每个工具都略有不同的侧重点，所以我们将逐一分析这些工具以帮助你选出适合安装在你的机器上的工具。这些工具执行统计记录所使用的语言和设计模式都可能影响其效率，例如，collectd是用C语言写的并作为守护进程(daemon)在运行，因此collectd不需要创建任何新进程来收集系统信息。其他收集程序可能是用Perl写的，可能你的磁盘缓存中包含Perl翻译器以及收集程序使用的所有Perl模块，系统需要定期产生一个或者多个新程序来收集系统信息。

　　RRDtool

　　这些我们将要分析的工具经常会使用其他工具，例如RRDtool就包括存储时间序列数据工具以及图表工具。

　　RRDtool工具侧重于存储新的时间序列数据，因此不会对磁盘子系统有很大影响，你可能会觉得这没什么大不了的。如果你只是每隔5-10秒钟获取几个值，将它们附加在文件的末尾，在服务器上都不能够明显被察觉，然后你可能会开始监测CPU(负荷、值、核心――每个核心多达16个值)、内存(交换、缓存大小――另外5个值)、磁盘中的剩余空间(20个值?)以及从UPS收集的数据(10个值)。即使不考虑网络流量，每隔10秒钟你都可以从系统中记录50个值。

　　RRDtool能够将这些值以4KB的大小写入磁盘中，而不是4字节或者8字节，因此系统不需要在每个记录间隔都运行工作。如果其他工具想要所有的数据，可以进行刷新输出缓存，以确保RRDtool缓存的所有数据都被存储入磁盘中。由于数据每次都是以4KB大小写入，就不需要总是将数据置于缓存中，只有再次执行分析或者使用RRDtool图表命令时才会启用。

　　由于系统监测工具经常会写入文件，你可能会对存储这些文件的区域进行优化。对于常规spinning disk，文件系统搜寻比按顺序读取很多块更具效率，当Linux内核只需要读取一个块时其他序列块也会进入缓存区以供备用。因为RRDtool文件经常被写入单个磁盘块，你最好关闭readahead的分区进程，你也可以利用util-linux-ng的blockdev程序将区块readahead值缩小为两个磁盘块(使用这样的命令：setra 16 /dev/sdX)。关闭时间更新并对文件系统使用writeback模式，RAID同样也将有助于提高性能。
 

collectd

　　Colletd是专为反复收集系统信息而开发的，而tarball包含分析这些信息的web界面，开发者表示该界面是一个极小的界面示例，那些想要找寻能够分析collectd收集的信息的web界面的人可以考虑使用其他工具(如Cacti)。

　　Debian Etch和Fedora9都附有collectd安装包，openSUSE还提供一键安装collected。该程序是用C语言写入的，并且作为守护进程运行，这使该程序能够在短间隔内记录信息而不会对系统产生较大影响。

　　当你安装collectd包的时候你可能还会想尝试插件包，collectd的重要优势在于能够通过插件支持检测各种各样的系统信息，例如数据库、UPSes、一般系统参数、NFS和其他服务器性能参数。不过，安装插件安装包不是件易事。对于openSUSE，你只需要安装插件完整包即可，而Fedora9( 4.4.x版本)则没有PostgreSQL插件，Debian、 openSUSE和Fedora中都不包含网络USP工具(NUT)插件。

　　解决插件问题的最简单的办法就是从源代码开始建立collectd，配置你想要的插件。一些通常没有被置于安装包中而你可能感兴趣的插件包括NUT、netlink、 postgresql以及iptables。安装collectd遵循如下步骤：配置;生成;sudo产生安装进程，但是如果你指定要编制某些插件的时候，你的配置命令可能会很长。安装程序以及我选择的插件都列在下面的命令中，我使用了contrib目录中的init.d启动文件，并更改了一些路径，因为我使用的是私人副本来保证collectd安装在单一目录树进行。另外，我还复制了iproute2以便在Fedora9的libnetlink库中使用。

　　在你启动collectd前，先看看etc/collectd.conf以确保你想要的插件及其选项能够被启用。该配置文件在LoadPlugin行(指定collectd的哪些插件需要使用)定义了几个通用的选项。每个插件的配置是在...范围内完成的，你也应该检查配置文件是否启用了rrdtool插件以及DataDir参数设置到现有的目录中，该目录中存储着可变数据。.

　　当你检查完插件启用情况以及选项情况后，就可以通过运行服务collectd状态启动collectd。

　　要想查看collectd收集的信息，你需要安装web界面或者其他程序(如Cacti)，以下命令的执行需要安装collectd提供的基本的CGI教本，截图显示了运行脚本的情况。

　　如果你想要在KDE桌面查看collectd数据，可以试试kcollectd，你也可以将生成的RRDtool文件与Cacti整合，虽然安装过程非常繁琐。

　　部署了collectd就可以开始执行系统监测了，而collectd所提供的web界面纯粹只能作为演示示例使用。作为C语言编写的守护进程，collectd也可以作为系统中最小进程运行。
 

Monitorix

　　Monitorix使用三个图表让你对系统信息一目了然：中央左边的图表提供信息概览和右边两个较小的图表提供相关细节信息。Monitorix包含一个Perl守护进程，能够收集系统的统计信息，还包含一个CGI网络界面使你可以分析数据。

　　在Fedora、openSUSE或者Debian中没有Monitorix安装包，Monitorix下载页面提供 noarch RPM文件以及tarball(供non-Red Hat/Fedora基础版本使用)如果你在Debian为基础的系统上安装，在monitorix-1.2.1 tarball中有一个 install.sh文件能够将文件复制到正确的路径，以及un_install.sh文件能够帮助你删除Monitorix。你需要为RRDtool安装Perl绑定程序(Fedora 9中的为rrdtool-perl，Debian中的为librrds-perl，openSUSE 11中的rrdtool)以便使用Monitorix。

　　在正确的位置安装好文件后，不管是通过安装RPM文件还是运行install.sh，你都可以开始运行服务monitorix启动来收集信息了，你应该也能够访问http://localhost/monitorix/来选择图表(或者指明查看所有图表)。

　　Monitorix并不包含插件系统但是内置支持监控CPU、进程、内存、文本切换、温度、风扇速度、磁盘IO、网络流量、需求服务如POP3和HTTP、中断行为和连接到SSH和Samba的用户数量。截图显示的是Monitorix的每日图表

　　你可以通过编辑/etc/monitorix.conf文件来配置Monitorix，而该文件实际上是一个Perl脚本， MNT_LIST选项允许你指定对多达7个文件系统进行监控。REFRESH_RATE设置设定了在查看Monitorix图表时设定了web浏览器多少秒钟内自动刷新其内容，你同样可以使用Monitorix来监测很多设备，而只需要设置MULTIHOST="Y"并将SERV_LIST中你想要监控的服务器列出来即可，如下列命令所示。或者你也可以使用PC_LIST和 PC_IP选项列出整个子网来进行监控。

　　图板组成中左边的主图和右边两个较小的图使Monitorix能够在相对紧凑的空间里显示相当多的相关信息，画面中，负荷被显示在左边的大图中，而积极进程数量和内存分配则显示在右边较小的图中。往下看，图版还显示了网络服务需求，该图板的主图表显示了很多服务，POP3和WWW作为较小图表排在右边。可惜的使，POP3的选择似乎被硬编码在monitorix.cgi的line 2566上，而SERVU2明确地在使用POP3，因此如果你想要监控IMAP邮件服务会是个问题。

　　Monitorix 易于安装和运行，并且它地三图表界面能够更好地查看系统情况。不过美中不足地是，有些程序仍然被硬编码到CGI脚本中，所以修改web界面会受到限制，另外很多安装包中都不附有Monitorix也会减少很多用户。
 

　　Munin

　　Munin 明确其功能主要为收集和分析功能，这可以帮助你收集多个服务器信息并在一个中央服务器上分析所有收集到的信息，Munin安装包也被附在很多系统中，使其安装和更新都相当简单。

　　Munin是用Perl编写的,有很多插件功能，支持Unix操作系统的多种版本，还有可搜索的插件网站。

　　Debian Etch和Fedora9都附有munin安装包，openSUSE11还提供一键安装，该程序提供两种软件包：munin-node，包含所有监控功能，而munin安装包支持从运行munin-node的设备上收集信息，并通过web界面将其图表化。如果你有很多设备，你可能会在大部分设备上安装munin-node而在某一设备上安装munin 以分析所有收集到的数据。

　　munin-node的主要配置文件/etc/munin/munin-node.conf可以让你定义日志文件存放的位置，哪些用户可以运行监控守护进程，守护紧凑可以连接到哪些地址和端口，哪些主机可以连接到地址和端口以下载收集到的数据，在默认情况下，只允许本地主机连接到munin-node。

　　你可以通过个人配置/etc/munin/plugin-conf.d文件配置插件，Fedora的 Munin-node附有约36个插件来监测系统和设备信息。

　　当你访问http://localhost/munin时，Munin会显示一张概览图向你展示所有连接到的节点，包括到节点的具体功能，如磁盘、网络、NFS和进程。点击节点名称会显示两行的图表，每一行都会在左边显示每日统计信息，右边显示每周统计信息，点击这些图表能够提供显示某日、某月的详细信息页面。在这项细节信息页面的底部，显示的是关于数据的更加详细的信息，包括不规则活动通知等。

　　想要知道系统或者服务每天或者每周的运行情况，Munin是最佳选择。不过，它的web界面不能提供数据钻取。

　　Munin的插件网站是相当出色的，在你下载前可以看到很多插件的示例图，而插件网站的缺点就是搜索界面不是很完善。

　　Munin的主要优点就是它能够同时提供收集信息和分析信息的功能，这样你就无需在每个节点上安装一个web服务器，并且详细信息页面底部的附加信息能够帮助你获取一些重要数据的统计信息。

　　结语

　　这四个应用程序中， Cacti能够提供最好的web界面，让你预先设定显示图表的时间间隔，同样也能显示你所感兴趣的明确起始时间间隔内的图表。相比之下，collectd则侧重于监控系统，而其提供的web界面也只能供最基本用途。鉴于收集数据和分析数据可以当作单独的功能，如果将collectd和Cacti结合使用的话，效果将很不错。不过，将Cacti安装到使用collectd生成的文件会是一个冗长的容易出错的过程。Monitorix和Munin都很易于安装，并能够提供快速的概览图，Monitorix的三图表分行图表显示能够为你提供更好的对系统运行情况的概览。

　　哪一种更加适合你哪?如果你花费大量的时间进行分析数据，或者你计划让非管理员查看系统统计信息，Cacti会是你的最佳选择工具;如果你向在承重负荷的系统上收集信息，可以考虑使用collectd，因为它对系统运行的影响最小;如果你需要监控小部分相似的设备，Munin可以帮助你使用不同程序包从很多节点收集信息;如果你有一台服务器并想迅速查看系统情况，Cacti和Monitorix都值得你考虑。