分布式nagios的配置

23rfc

分布式的nagios已经用了半年多了，有一些心得写出来和大家分享一下，我不是专家，只能写一些比较粗浅的意见，大家看的有不对的，或者更好的办法，欢迎拍砖。

  分布式的nagios，很多人都在讲，也有很多人在用，或者打算用。我写这个帖子，并不是想写一个教程，分布式nagios的配置很简单，没必要写什么教程，只是单纯的一些想法的交流，二来nagios的分布式有很多种理解，也有很多种实现方式，我只是写我比较感兴趣的那几种而已。

1、什么时候需要用分布式的nagios？

   因为各种各样的原因，用一台nagios无法满足监控的需求，或许你要监控的集群在两个机房，相隔很远，互不相通；或许你监控的机器太多，觉得一台nagios撑不住；或许是其他的原因，总之你必须要两个，或者两个以上的nagios才能满足你的监控需求，这个时候，如果你选择nagios的话，那就要做分布式nagios的配置了。

2、什么才算分布式的nagios？

   单纯的配几个nagios，而不做其他任何的工作，这样的配置个人觉得不是很好，如果你有两台三台，那还凑合，你可以开三个web页面，分别看着三个nagios，也可以维护一张列表，当监控配置变更的时候到三台nagios上去做，但是一旦监控机器多起来，比如十台八台，这个时候，当你需要定位一个错误都要翻开很多很多的web页面去看，就不是很爽了。
   因此，个人对分布式nagios的理解主要有以下几个方面：
   1、分布式检测。这个是最基本的，配分布式主要就是要每个监控机对自己所管理的一个范围内的对象进行监控。
   2、集中式展现。我觉得这个是必须的，当机器多起来的时候，确实需要一个集中式的展示页面，避免我们有3台nagios就要开3个web页面，有10个nagios要开10个web页面。
   3、集中式控制。当我们对单台机器做一些监控方面的变更的时候，比如开关报警、提交检测结果、重新发送报警，最好能统一的做，而不应该跑好多地方去找。
   4、集中式配置。更改配置，也应该是在一起，然后分发到各台分布式的nagios监控机上。
   5、分布式报警。报警任务需要分发到各个分布式的监控机上，以免当出现意外情况，比如内部网络突然断掉，无法登上那台机器，或者那台机器的检查结果无法回来的时候也能进行正常的报警。
   6、最重要的一点：尽量避免分布式。如果你可以避免配置分布式的nagios，那就尽量避免它！nagios是一款很高效的软件，我用了半年多，每次感觉它撑不住了，但是每次结果都发现不是nagios本身的问题，而是我自己配置的问题。不论是哪种分布式实现方式，对于nagios来讲都是一种性能上的损耗。而且，能用一台机器解决的事情，为何要用两台呢？
   总而言之，我们配置的目的，就是很多台nagios在跑，但是需要给人一种感觉，那就是我们总共只有一台nagios在工作。

3、怎样实现上一问所说的分布式？

   具体实现方法有很多，我列举我知道的，欢迎大家补充：
   方法1、使用nagios的被动检测。
   这是最简单的办法，分布式的nagios利用ocsp选项，将检查的结果通过nsca提交到一台总的监控机上，总的监控机也配置nagios，但是自己并不会进行host或者service的检测，所有的检测结果都通过nsca从分布式的nagios获取。实现简单，但是效果最差。
   a、被动检测结果是通过nagios.cmd文件进行提交的，而管道方式的数据传送是一种很低效的方式，而且默认的cmd缓存只有4096行，当然这个值我们可以配置的很大，但是势必会影响回收检查结果的速度。如果设置的太小，那就会有很多检查结果无法回收。而且，所有web页面传回来的命令也是走的nagios.cmd，我们会发现在做了某些操作的时候，很久才会生效，甚至根本没有生效。
   b、集中式的控制需要另外实现，如果报警的功能是在分布式的nagios上实现的，那要控制它就得另外实现。但是如果要在集中式的那台机器上报警，也不是不可以，但是上面的问题就会很突出，万一回收结果溢出被丢弃，那它的报警永远发不出去了。
   c、集中式配置，也需要另外实现。
   方法2、使用ndo，统一入库之后再集中展示。
   一个比较好的解决方案，那就是centreon，centreon是用php和perl写的，利用到了ndo。具体方法是，centreon自己把监控的节点都配好了，存在它的数据库里，然后将这些配置导出成为nagios的配置文件，然后启动nagios，利用ndo将检查结果入到数据库中，centreon再读这个库来进行展示。
   这算是个比较完美的解决方案了，集中控制，集中展现，集中配置，分布式检测和报警都实现了，而且还附送rrd绘图和报表的功能，但是，还是有些地方需要注意的：
   a、配置很麻烦。我只能说配置很麻烦，依赖的东西很多，php、mysql、ndo、还有很多perl的lib，而且有些脚本在安装好以后可能是无法运行的，会抛出大量的错误，需要你一个一个去排查，必要的时候还需要改写脚本。如果你对nagios很熟悉，对perl，php，rrdtool，mysql都有所了解，那建议你用centreon；如果不是，还是请多考虑下，很多情况下都是配着配着就卡在一个地方，再也下不去了。
   b、ndo入库的问题。nagios是款很高效的软件，如果你看过它的源码的话，相信会有这种感触。他从头到尾的实现都在避免任何可能遇到的瓶颈，所以他刻意绕开了数据库，在硬盘读写和等待检查结果两者中取了个很适合的平衡点，它尽量让自己的性能完全取决于处理器的处理能力，而不是低速的硬盘、网络和它无法预知的plugin。这让我觉得，不论是使用ndo，还是使用被动检测，都会对它的性能造成很大的影响。我曾经遇到过这种事情，我的nagios被低速的数据库拖垮，last_check时间平均分布在一个小时的时间段里……
   方法3、靠自己。
            
   完全靠自己来实现，在linux下，这是完全可行的，所有的性能都在自己的掌控中，这种感觉是很奇妙的，而且难度并没有想象的那么大。
   a、集中展示
   集中展示是靠nagios的cgi来实现的。nagios的cgi展示的时候要读取几个文件，主配置文件nagios.cfg；objects.cache文件，存放nagios的对象信息；status.dat文件，存放状态信息。我们只要提供给它这三个文件，它就会把我们需要的结果乖乖的展示出来。
    主配置文件不说，objects.cache这个文件，可以通过nagios -pvnagios.cfg来生成objects.precache，它会读取所有object的配置文件生成一个包含所有object配置的文件。然后直接mv到objects.cache就可以。
    status.dat这个文件可以通过各种手段来生成，用nfs也好，scp也好，或者别的办法，定时的把分布式nagios的status.dat收集到主nagios上，然后通过一个脚本将这些文件中包含的状态信息综合到一个status.dat里。本来nagios通过status.dat的展示就是异步的展示，我们再做一次异步，展示的时间可能不是很及时，但是nagios毕竟是以报警为主的，一般来讲，等你收到了报警的时候，再上去看web页面那应该早展示出来了。
    这样，我们就完成了一次欺骗，我们欺骗了nagios的cgi，让它以为，这台机器上确实有一个nagios在后台跑着，但是实际上这只是一种错觉而已。而且，异步的工作，对nagios本身的性能影响最小。
    b、集中配置
    集中配置其实也没什么难点，既然这台机器要生成你所有需要的object的总配置文件，那这台机器上就需要有所有的object的配置，你可以通过各种办法，scp，svn，将这些配置文件分发到各个分布式的nagios上，然后ssh过去重启一下，这些都是可以固化到一个脚本里实现的，object的配置文件可以按照分布式nagios的不同放在不同的文件夹下，到时候只要拷贝这个文件夹过去就可以了。
    c、集中控制
    集中控制是这个方案中最麻烦的一点，nagios的控制，是通过cmd.cgi写nagios.cmd来实现的，你有多个nagios，就有很多的nagios.cmd，首先我们要知道需要写哪个cmd文件，然后我们要想办法把控制信息写到这个cmd文件上去，更头疼的是这些个文件分布在不同的机器上，也许相隔很远。但是办法总是有的，幸好我是在linux下，呵呵。我的办法还是采用nagios自带的cgi实现，就是cmd.cgi，我先判断，我操作的host或者service是在哪个nagios上，然后我访问它的cmd.cgi就可以了。
    首先，我们需要一张列表，我们至少要明白，在哪个nagios上跑了哪些host和service，这样，当我们做出控制的时候，就可以先读取这张列表，知晓我们需要到哪台机器上做控制。这个列表可以放在配置分发脚本中实现，每次配置改动，就重新生成。当然，这个是需要一些自己定义的规范，规范不一样，脚本也不一样。
    然后，我们要让主nagios上的cgi读取这个文件，调用cmd.cgi的是extinfo.cgi，我们需要做一些源码上的改动，当它调用cmd.cgi的时候，就先读取列表文件，知晓了它要操作的对象所属的nagios主机名，或者ip地址，总之是一个标识，然后，将这个标识表现在调用的url中。
    接下来，就是apache干的活了，通过这个标识的不同，来进行重定向，将cmd.cgi重定向到和它相对应的主机上，这样控制就实现了。对于没有外网地址的nagios，可以利用apache的反向代理或者其他。这就不属于我们讨论的范围了。
    这种办法，灵活性很高，我们可以选择我们喜欢的方式，而且刻意绕过了数据库，对nagios本身的性能基本上没什么影响，如果nagios的log对你很重要的话，可以选择让各个nagios每天滚一次日志，然后每天晚上将log收集起来，合并成一个nagios日志，这样nagios的日志分析工具也可以用了。当然也有一些实时的方法，欢迎大家提供，呵呵。