监控系统的那些事儿1——部署了开源监控后

本文属于个人的一些零碎的想法的集合，可能有些跳跃，各位看官海涵。

某些观点可能不专业，如果你有其他见解不吝提出，共同学习，谢谢！

背景

由于庞大的HP Openview监控系统一个人实在是没有时间搞，刚好也被交出去了，所以索性搞了一套开源监控。

在开源监控的选择上，在测试了将近半年后，决定正式使用Icinga和Cacti。

用了很久的Icinga——或者说Nagios的衍生版，也用了Cacti，这两个软件在我眼中两者各有所长。

在我的使用环境中，两者没有做集成，由于资源有限，各跑在一台虚拟机上，磁盘I/O性能相当差。

Nagios

Nagios系擅长事件处理，扩展性能极强，基本上你能想到的功能都可以实现。

这里顺便说说我是用的Icinga的情况。

目前，Icinga上面有7xx台设备，1xxx个服务被监控，均为主动服务。后期根据需求，逐渐加入了PNP4Nagios，NagTrap等组件，运行良好。

后来，邮件系统的大规模纳入，造成了PNP4Nagios绘图数量的直线上升，直接导致Load由<1增长至>4，由于设置的报警阈值是8，时不时会给我发一个报警。

除此之外，负载的升高也导致检测延迟的增大，最大之前曾看到过有6xx秒。

这还不是主动发现的，是有一次告警，同事说快处理完故障后才发出的消息，这时我才发现出现了问题。

在调查原因的时候，iotop显示I/O很低，理论上并不会造成读写的问题，所以一开始是被忽略的。

在逐渐根据Nagios官方手册调优的时候，在文件配置时的一次失误，反而帮我揭开了谜团——PNP4Nagios性能处理文件目录配置错了，于是就没有读写RRD了，这时候负载迅速降低为<1了。

在整个调优过程中，各个步骤都有记录，而且每步我都等待了一段时间来获取Load的数据作为对比——发现只有RRD这一个问题是关键，其余的调整了没有多大变化。

后来，在网上寻求了很多方法，但基本上都没有大的进展。

在知乎上的一个问题，对我如同醍醐灌顶：nagios应该如何优化

这时我才算明白了问题的核心，异步其实就相当于转嫁了等待的工作，以前对并发的理解貌似也有些问题。

Nagios整体是调用机制，而且初期配置时，应该是主动服务最多，此时如果检测的脚本或者调用的命令是同步的、数量较大（或许性能还会很差），就会导致系统负载很高，如同一个连锁反应，最后就会导致检测延迟的增大。最终的结果嘛，监控不及时……

个人认为这应该是为了灵活的扩展性而做出的取舍，甚至可以说是架构上的缺陷？——呵呵，我资源比较紧张……

Cacti

Cacti擅长以SNMP方式检测，以图形方式展示，有一定的扩展性能。

Cacti上面有1xx个设备被监控，图形数量在5xx级别。

经常出现的是Script Host无响应等等问题，不论如何调优，都会有这样的问题。至于升级的问题，由于时间不足，暂不做考虑。

其实想想Nagios，这也应该是一样的问题，也是负载的原因。刚刚又看了一下，CPU利用率在30%左右，CPU负载在3左右，这当然是调整后的。

至于如何调整的呢，是取消了对网络设备CPU和内存的监控，至于为什么取消，是因为：从来没用过，而且占了需要监控内容的地了。

你可能说优化的问题，优化早就在最初系统上线的时候就配置完成了。

当然，也不排除没有找到根本的原因。