来自：网络

【2013年2月22日 51CTO外电头条】自从加入37Signals公司以来，我一直在努力改善企业的监控基础设施。

我们的主要监控方案采用的是[  /art/201301/376725.htm]Nagios[/url]，它与老款沃尔沃倒有几分神似——也许外观不够漂亮、也许速度不够惊人，但它易于使用、而且绝不会让人束手无策。

下面聊几句背景信息。2009年1月时，我们拥有350项Nagios服务。而到了2010年9月，我们所使用的服务数量上升至797项，目前则已经达到7566项之巨。       nagios安装

在数字迅猛增长的同时，我们还大幅降低了故障警报的出现频率，现在几乎很少会有管理员会被大半夜拉起来处理紧急情况。

当然，整个过程也出现过一些波折，但这一切都是为了实现更好的监控效果。在本文中，我希望与大家分享一些在使用Nagios过程中总结出的实用提示，进而帮助各位在扩展及改进监控系统时获得一些引导。        开源监控软件

与37signals公司中的大多数方案一样，我们的[  /art/201301/378373.htm]Nagios环境[/url]也由Chef平台牢牢掌控。当新的主机配置完成后，它们会被自动添加到监控系统当中。一年多之前，我们只能以自动化方式监控主机上的少数事务：磁盘使用率、负载以及内存等。          nagios配置

扩大监控范围

为了扭转局面，我们做的第一件事就是安装Check_MK。Check_MK是一款Nagios插件，能够自动清查主机、收集性能数据，并且提供了一套更友善的UI。在Check_MK的帮助下，我们现在能够以自动化方式在每台主机上监控20项指标；由Postfix队列发往开放TCP连接的所有信息都能受到监控。Check_MK还提供了一套非常实用的后端，即mk_livestatus，允许我们向Nagios查询实时主机、服务信息以及即将发送的处理指令。举例来说，我们利用Livestatus来训练Campfire机器人接收警报并设定停机时间。通过Tally，现在我们几乎可以通过Campfire完成全部Nagios交互工作。

我们还逐步在Nagios中添加了大量针对特定应用程序的监控方案——我们利用statsd追踪响应时间、错误代码及其它各种有助于衡量应用程序性能的指标，此外MySQL、Redis以及Memcached统计数字也被纳入了进来。要想在客户发现问题前将其消灭在萌芽阶段，这些监控手段是必不可少的。额外检查项目的加入使我们对系统运行状态有了更为直观的了解，但凡事有利就有弊：由于监控方案的大幅加强，我们安装并运行Nagios的主机在性能方面承受着很大压力。       监控软件

存在的问题

对于中小型使用环境而言，Nagios的开箱即用效果非常突出；但我们很快发现了一些局限性，而这给我们带来不小的麻烦。首先，由于Nagios常常拿不出足够的资源执行检查工作，因此在设定检查与执行检查之间往往存在45秒的延迟。为了降低这种延迟，我们对安装配置做出了大量调整，其中一项效果明显，直接将平均延迟时间压缩至0.3秒以内。遗憾的是由此带来的主机负载也同样明显——Nagios在给定时段中的检查活动数量受到影响，延迟检查出于资源节约考虑而被自动忽略掉了。在放开这一性能瓶颈后，我们的负载强度由5%上升到30%左右（我们的主监控服务器采用两块至强E5530处理器）。         nagios实施

最后，我决定在负载失控之前进行检查数量缩减。经过实践，我们发现缩减使用频率最高的check_mk代理检查对于负载的影响微乎其微，但将其它几项活动检查的执行频繁降低一半则大大减轻了主机负载——由30%下降至10%以下。由此我们可以看出，主动服务才是节约性能的最大敌人，必须不惜一切代价予以消除。

Nagios服务上手指南

• 主动服务是指那些由可执行shell脚本所定义、能够由Nagios直接执行的检查项目。这项服务需要进行时间间隔设定，进入调度程序后会根据进程启用情况自动执行。Nagios必须进行shell释放、执行检查脚本、等待结果、分析结果、将结果添加到命令缓冲区然后处理结果等一系列工作，且在整个检查过程中该线程会保持运行并不能用于任何其它工作。        
  nagios培训
• 被动服务是指那些由Nagios（例如check_mk代理检查）或其它机制所触发、但不会被Nagios服务器主动启用的检查项目。在存在被动检查结果时，外部进程会直接将结果添加至命令缓冲区中，并由Nagios将其作为主动检查结果进行处理。Nagios并不会对此类检查进行调度或者利用资源加以执行，因此这些检查所占用的资源也少得多。
  

我们的大多数主动服务都会向内部仪表板应用发送HTTP请求，旨在获取前文提到过的应用及数据库指标。由于Nagios主动检查指标的方案会占用过多硬件资源，我们决定定期通过网页接口推送来自Statsd的更新信息（这一机制由Slanger库实现）。要做到这一点，我们在Chef上创建一个配置文件，其中包含我们所需要的指标、相关阈值以及简洁的后台订阅描述。这样检查结果数据就会定期被发送至Livestatus处，并被添加到命令缓冲区中进行处理。我们还将这些来自仪表板的推送检查与其它脚本检查加以整合。

结果汇总

与我们的预期一致，将服务转为被动属性大大降低了Nagios的CPU使用率，具体情况如下图所示：

[  /files/uploadimg/20130222/1004580.jpg][/url]

总而言之，我们将主动服务的数量由1900降低到745。幸存下来的检查项目大多必须采取主动状态——例如ping检查、Check_MK代理以及应用程序HTTP检查等。因为只有这样我们才能在项目出现问题时及时得到警告。

[  /files/uploadimg/20130222/1004581.jpg][/url]

从某种程度来说，这只是种负载转移过程——某些负载被转嫁到其它主机当中，并通过检查脚本或者后台推送程序将结果传递给Nagios。不过这种收益还是相当显著且顺理成章的（将负载分摊到服务器闲置资源中），我们还通过对检查脚本的重新编写改装最系统全局执行效率、消除了成千上万HTTP请求所带来的资源占用。更重要的是，我们在恢复原有检查间隔的同时还添加了一些新的监控项目，并且始终将负载控制在3%、延迟控制在0.5秒以下。

希望我在打理监控基础设施方面的经验能帮助大家找到实际问题的解决办法。过去那种“添加其它可执行脚本”的方式实在太过狭隘，其实我们完全能以其它方式更好地搞定难题。从某种意义上说，即使各位的监控系统并没有出问题，这篇文章也能在进一步提升性能表现方面有所借鉴。

想做Nagios， Zabbix,Cacti,iTop各种交流的，可以进入开源监控工具Nagios交流  QQ群号 ：476809427

来自：网络

【2013年2月22日 51CTO外电头条】自从加入37Signals公司以来，我一直在努力改善企业的监控基础设施。

我们的主要监控方案采用的是[  /art/201301/376725.htm]Nagios[/url]，它与老款沃尔沃倒有几分神似——也许外观不够漂亮、也许速度不够惊人，但它易于使用、而且绝不会让人束手无策。

下面聊几句背景信息。2009年1月时，我们拥有350项Nagios服务。而到了2010年9月，我们所使用的服务数量上升至797项，目前则已经达到7566项之巨。       nagios安装

在数字迅猛增长的同时，我们还大幅降低了故障警报的出现频率，现在几乎很少会有管理员会被大半夜拉起来处理紧急情况。

当然，整个过程也出现过一些波折，但这一切都是为了实现更好的监控效果。在本文中，我希望与大家分享一些在使用Nagios过程中总结出的实用提示，进而帮助各位在扩展及改进监控系统时获得一些引导。        开源监控软件

与37signals公司中的大多数方案一样，我们的[  /art/201301/378373.htm]Nagios环境[/url]也由Chef平台牢牢掌控。当新的主机配置完成后，它们会被自动添加到监控系统当中。一年多之前，我们只能以自动化方式监控主机上的少数事务：磁盘使用率、负载以及内存等。          nagios配置

扩大监控范围

为了扭转局面，我们做的第一件事就是安装Check_MK。Check_MK是一款Nagios插件，能够自动清查主机、收集性能数据，并且提供了一套更友善的UI。在Check_MK的帮助下，我们现在能够以自动化方式在每台主机上监控20项指标；由Postfix队列发往开放TCP连接的所有信息都能受到监控。Check_MK还提供了一套非常实用的后端，即mk_livestatus，允许我们向Nagios查询实时主机、服务信息以及即将发送的处理指令。举例来说，我们利用Livestatus来训练Campfire机器人接收警报并设定停机时间。通过Tally，现在我们几乎可以通过Campfire完成全部Nagios交互工作。

我们还逐步在Nagios中添加了大量针对特定应用程序的监控方案——我们利用statsd追踪响应时间、错误代码及其它各种有助于衡量应用程序性能的指标，此外MySQL、Redis以及Memcached统计数字也被纳入了进来。要想在客户发现问题前将其消灭在萌芽阶段，这些监控手段是必不可少的。额外检查项目的加入使我们对系统运行状态有了更为直观的了解，但凡事有利就有弊：由于监控方案的大幅加强，我们安装并运行Nagios的主机在性能方面承受着很大压力。       监控软件

存在的问题

对于中小型使用环境而言，Nagios的开箱即用效果非常突出；但我们很快发现了一些局限性，而这给我们带来不小的麻烦。首先，由于Nagios常常拿不出足够的资源执行检查工作，因此在设定检查与执行检查之间往往存在45秒的延迟。为了降低这种延迟，我们对安装配置做出了大量调整，其中一项效果明显，直接将平均延迟时间压缩至0.3秒以内。遗憾的是由此带来的主机负载也同样明显——Nagios在给定时段中的检查活动数量受到影响，延迟检查出于资源节约考虑而被自动忽略掉了。在放开这一性能瓶颈后，我们的负载强度由5%上升到30%左右（我们的主监控服务器采用两块至强E5530处理器）。         nagios实施

最后，我决定在负载失控之前进行检查数量缩减。经过实践，我们发现缩减使用频率最高的check_mk代理检查对于负载的影响微乎其微，但将其它几项活动检查的执行频繁降低一半则大大减轻了主机负载——由30%下降至10%以下。由此我们可以看出，主动服务才是节约性能的最大敌人，必须不惜一切代价予以消除。

Nagios服务上手指南

• 主动服务是指那些由可执行shell脚本所定义、能够由Nagios直接执行的检查项目。这项服务需要进行时间间隔设定，进入调度程序后会根据进程启用情况自动执行。Nagios必须进行shell释放、执行检查脚本、等待结果、分析结果、将结果添加到命令缓冲区然后处理结果等一系列工作，且在整个检查过程中该线程会保持运行并不能用于任何其它工作。        
  nagios培训
• 被动服务是指那些由Nagios（例如check_mk代理检查）或其它机制所触发、但不会被Nagios服务器主动启用的检查项目。在存在被动检查结果时，外部进程会直接将结果添加至命令缓冲区中，并由Nagios将其作为主动检查结果进行处理。Nagios并不会对此类检查进行调度或者利用资源加以执行，因此这些检查所占用的资源也少得多。
  

我们的大多数主动服务都会向内部仪表板应用发送HTTP请求，旨在获取前文提到过的应用及数据库指标。由于Nagios主动检查指标的方案会占用过多硬件资源，我们决定定期通过网页接口推送来自Statsd的更新信息（这一机制由Slanger库实现）。要做到这一点，我们在Chef上创建一个配置文件，其中包含我们所需要的指标、相关阈值以及简洁的后台订阅描述。这样检查结果数据就会定期被发送至Livestatus处，并被添加到命令缓冲区中进行处理。我们还将这些来自仪表板的推送检查与其它脚本检查加以整合。

结果汇总

与我们的预期一致，将服务转为被动属性大大降低了Nagios的CPU使用率，具体情况如下图所示：

[  /files/uploadimg/20130222/1004580.jpg][/url]

总而言之，我们将主动服务的数量由1900降低到745。幸存下来的检查项目大多必须采取主动状态——例如ping检查、Check_MK代理以及应用程序HTTP检查等。因为只有这样我们才能在项目出现问题时及时得到警告。

[  /files/uploadimg/20130222/1004581.jpg][/url]

从某种程度来说，这只是种负载转移过程——某些负载被转嫁到其它主机当中，并通过检查脚本或者后台推送程序将结果传递给Nagios。不过这种收益还是相当显著且顺理成章的（将负载分摊到服务器闲置资源中），我们还通过对检查脚本的重新编写改装最系统全局执行效率、消除了成千上万HTTP请求所带来的资源占用。更重要的是，我们在恢复原有检查间隔的同时还添加了一些新的监控项目，并且始终将负载控制在3%、延迟控制在0.5秒以下。

希望我在打理监控基础设施方面的经验能帮助大家找到实际问题的解决办法。过去那种“添加其它可执行脚本”的方式实在太过狭隘，其实我们完全能以其它方式更好地搞定难题。从某种意义上说，即使各位的监控系统并没有出问题，这篇文章也能在进一步提升性能表现方面有所借鉴。

想做Nagios， Zabbix,Cacti,iTop各种交流的，可以进入开源监控工具Nagios交流  QQ群号 ：476809427