×

扫描二维码登录本站

QQ登录

只需一步,快速开始

Nagios分析文档(4)

标签: 暂无标签
本帖最后由 monicazhang 于 2015-10-30 21:27 编辑

20151030淡然
续上




14、event_expire_downtime
15、event_reschedule_checks(重新编排event列表,与上文说的初始化循环类似)
16、event_expire_comment
17、event_user_function

   对于普通的nagios来说,最常用的只有以下几个:1,2,7,10。                                  nagios安装

   如果设置的是被动监控,那会频繁用到3,孤儿host和service我没玩过,所以也不清楚,把结果保存到retention.dat中,主要是为了关 闭 nagios后再启动,可以读入关闭时候的状态,而用不着重新检查,而结果保存到status.dat中,主要是给cgi读取展示用的。downtime 和comment这两个东西我也没玩过。


四、主动监测(event_service_check,event_host_check)

   因为主动监测的函数结构,流程都大致相同,所以这两个可以放到一起分析。
   我只看了event_service_check,因为相比较起来,肯定是service的检查更复杂,host的检测只会简单。

   event_service_check调用了run_scheduled_service_check函数, 然后再调用函数run_async_service_check。

   检查的过程其实就是fork一个进程,执行配置好的命令进行检测,然后将检查结果返回,生成check文件,并且将文件名添加到check_result_queue中,生成check.ok文件,等待reaper回收。                                开源监控软件

   如果在配置文件中开启了use_large_installation_tweaks选项,那么在检查的时候,会fork两次子进程,父进程并不会等待检 查进程返回结果,只要fork的进程数量不超过配置文件中设置的最大进程数量(max_service_check_spread和 max_host_check_spread),就不会有问题。

   很奇怪的是,run_async_service_check函数中没有调用 event_broker的地方,也没有将检查结果进行obsessive,这点很出乎我的意料(看到这里的时候,我才意识到我们的监控架构是不合理的, 在最后我会稍微说一下,希望大家不要重蹈覆辙)。

五、结果回收(event_check_reaper)

   event_check_reaper调用reap_check_results函数,读取所有检查结果,并且在循环中依次调用process_check_result_queue进行结果回收。

   process_check_result_queue负责把保存在文件中的检查结果读出,并且插入check_result_list中,删除结果文件。
   然后handle_async_service_check_result再对结果进行处理,这些处理包括了:                           nagios配置

   更新检查结果到service_list链表,obsessive检查结果,event_broker,报警等等

   handle_async_host_check_result_3x 用来检查host状态,和service类似。

   如果在reap_check_result中时间超过max_check_reaper_time,则退出循环。        max_check_reaper_time的默认值为30s,在nagios.cfg中,可以通过设置 max_check_result_reaper_time来进行设置。

!!!最终!!!
   我们得到了两个链表:host_list和service_list,里面存储了我们所有host和service的最新的检查结果。

   在这一步才发现了obsessive结果和event_broker,只拿event_broker来讲,我们的ndomod就是在执行 event_broker的时候被回调的,如果ndo慢了,那回收的结果肯定就慢,如果需要回收的结果很多,回收不过来,那肯定就会超过 max_check_reaper_time,然后退出循环,但是因为送回来的检查结果频率是相同的,所以下一次reaper还是不会检查完的,只能导致 待回收的结果越来越多,如果是一台只有主动监控的机器,那就会看到checkresult目录下的文件越来越多,甚至会发现一个小时以前的文件,但是如果 是一台在被动监控集群中用来做展示和报警用的机器,检查结果的累积就只能在内存中查看了。                                                监控软件

   我上周遇到的,看到检查的 last_check事件在一个小时的时间段内平均分布,应该就是这个原因了,那时候我不停的修改配置文件,加大它写status文件的频率,但是一直不 见好转,现在终于知道原因,是因为handle_timed_event函数还在check_reaper中没有出来,不会再去执行下一条 time_event。

六、结果输出(event_status_save)

   event_status_save比较简单,就是将host_list和service_list中的数据同步到status.dat中,不过是全部同 步,如果检查结果很多的话,像我每次要写 30M+的文件,虽然不知道具体要占用多少io,但是如果对于数据在页面上的展示没有需求的,只需要检查,处理报警(或许还需要入库)的,就没必要再来这 么一步了。

event_status_save执行过程中不会对event_broker进行操作。                           nagios实施

七、分析:

   我们的监控会用几台机器专门用来进行check,然后将检查结果obsessive到另外一台机器上,由这台机器来进行报警,展示,但是现在看来,这种架 构是有问题的,因为在check的时候并不会做任何提交,而是在回收结果的时候才会进行提交,而且在提交之前已经进行了报警,写checkresult文 件,读checkresult文件等大量操作,到了主nagios上之后,又要重新进行一次检测报警,造成的资源浪费还是很不小的,而且检查的时间和最后 报警的时间相隔比较大。                               nagios培训

   可以看出来的是,真正花时间的并不是主动监测,因为主动监测只需要fork进程就可以了。





本帖关键字:Nagios





上一篇:Nagios分析文档(3)
下一篇:Nagios的安装与配置(1)
monicazhang

写了 2297 篇文章,拥有财富 12859,被 21 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部