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

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