20151030淡然

续上




五、扩展

关于nagios的扩展我们可以从两个方面去思考：1、自己编写插件2、module模块的编写。

其实围绕nagios的开发，已经相当完善了，除了我们上文图中提到的五大模块，我们从官网上还了解到其他的一些nagios插件。

自己编写适合自己的插件。尽管nagios已经提供了大部分的服务监测，但是说实话，很多都是通用的插件，针对自己特殊的服务，不一定适合。我们可以根据自己的需求，去编写自己的插件，增加或者替换以前的插件。

       关于module模块的开发，nagios是基于事件驱动的，所以模块的开发是很重要的，这部分看的不是很详细，不好妄加评论，但是可以肯定的是这部分是可以扩展的。以下是摘自nagios module中的注释，它简短的说明了module的编写：

（This is an example of a very basic module.  It does nothing useful other

* than logging some messages to the main Nagios log file when it is initialized

* (loaded), when it is closed (unloaded), and when aggregated status updates

* occur.  I would not call that too useful, but hopefully it will serve as a

* very basic example of how to write a NEB module...）

       另外我个人觉得关于nagios的开发，我想扩展并不是一条很好的路径，就像前面提到的，围绕nagios的开发已经很成熟了。Nagios其实并不缺什么，该有的插件都有，该实现的功能都已经实现了。但是nagios有值得改进的地方，例如nagios读写文件，如果监视主机数量很大的话，io将是一个机器不小的开销，另外在最终形成服务器可读文件之前，nagios经过了冗余的步骤，在读写文件不停的打转，cpu和内存都有不小的消耗。

技术文档2：nagios流程分析

  在大部分环境中，nagios是不需要优化的，一来监控这个东西大家都不觉得很重要，二来nagios本身已经是个很轻量级的软件，架构比较合理，三来现 在的机器配置都很恐怖，一台普通的pc机撑起上千台host，上三四千service的监控那是小菜一碟，实际环境中有这么大量监控需求的地方本来就不 多，就算有这么大量监控需求的公司，用nagios的并不多数吧！

   但是某些情况下，还是偶尔碰到需要优化的情况。我需要监控的机器数量就超过了1000台，而且用的nagios，用了被动检查的架构以后，撑起这么多的监 控本来是没有问题，但是上周的时候，做nagios和ndotuils 的集成就出现了性能瓶颈，凌晨5点左右，把ndotuils架到两台nagios上之后，应用启动什么的都正常，但是到了上午8点就发现了问题，看到检查 结果的last_check时间从7:20到8:20不等，而且是均匀分布，没有办法，只好把ndomod关掉，到了上午10点左右，就恢复正常了。

   既然nagios出现了瓶颈，就不妨拿源码来看一下，配置文件的选项优化，在nagios的文档里说了很多，但是还是感觉不是很直观，分析源码，只是属于个人兴趣，这里把流程跟大家分享一下，至于优化方案，还是需要大家多多指点了。                  nagios安装

一、nagios在启动以后，载入成daemon，整个的步骤如下：

1、读入配置文件（read_main_config_file）
2、初始化event_broker
3、载入所有broker_mod（ndomod包括在这里面）
4、读入object信息（包括service，host，servicegroup，hostgroup，contact，contactgroup等等）
5、告诉broker，我启动了
6、初始化daemon（例行工作，fork进程，修改根目录，设置信号量等等）
7、打开cmd文件（nagios.cmd）
8、初始化status数据（status.dat）
9、读取保存数据（retention.dat）
10、读取注释数据
11、读取downtime数据
12、读取性能数据
13、初始化event_timing循环
14、初始化check_stats
15、生成status.dat（空的，不写数据）
16、传输event_loop_start信息到broker(ndo：获取scheduling_info中数据)
17、开始event_execution_loop，检查数据，直到捕获重启或者关闭信号

如果接到了重启或者关闭的信号，则继续往下执行
18、通知broker_mod，我要关闭了，或者我要重启了
19、保存retention文件
20、清理性能数据
21、清理downtime数据
22、清理注释数据
23、如果是关闭信号，清理status.dat
24、如果是关闭信号，删除cmd文件                            开源监控软件

   步骤比较简单，其中比较重要的有两个，一个是13，初始化循环，另一个就是17，nagios在作为daemon运行的过程中，就是在不断的执行这个循环。

二、初始化循环
   nagios是个基于事件的监控系统，所有的操作都是由事件触发器触发的。

   nagios启动的时候，会启动一个init_timing_loop函数，来进行事件循环的初始化。
   init_timing_loop主要流程如下：

1、建立scheduling_info表，表的内容有：
        总service数（在时间表外的也算）
        已经在表中的service数
        总host数（时间表外的也算）
        在列表中的host数
        单个host平均service数（总service数/总host数）
        列表中单个host的service数（列表中service数/列表中host数）
        平均service检查时间间隔（service检查总间隔/列表中service数）
        service检查总间隔
        平均service检查延时
        host检查总间隔
        平均host检查延时

      
2、计算最优service检查间隔
        人工设定（配置文件中service_inter_check_delay_method选项）
        智能计算（平均service检查间隔/列表中总service数） ps：呵呵，很傻的办法                   nagios配置
3、将service检测插入event队列
4、计算最优host检查间隔（同2）
5、将host检测插入event队列
6、插入misc事件
        a、重新排列列表（auto_reschedule_checks）
        b、收集检测结果（check_result_reaper_frequency）
        c、检查孤儿service和host（配置文件选项：check_for_orphaned_services，check_for_orphaned_hosts）
        d、检查service新鲜度（针对被动检测，配置文件选项：check_service_freshness）
        e、检查host新鲜度（针对被动检测，配置文件选项：check_host_freshness）
        f、回收检查结果到status文件（status_update_interval，配置文件中频率设置选项为：status_update_interval）
        g、检查cmd文件（command_check_interval，配置文件中检查频率设置选项为：command_check_interval）
        h、日志滚动事件
        i、检查结果保存（retention_update_interval，配置文件中保存频率设置选项为：retention_update_interval）

nagios先将初始化的检查插入misc事件链表中，等待nagios完全启动后，主循环对它进行处理。                  监控软件


三、主循环（event_execution_loop）

   nagios在进入守护状态以后，会一直运行一个循环event_execution_loop，nagios所有的操作全部在这个循环中得到实现。

   循环会不断检查两个event队列，一个是高优先级，包括nagios的除了检查之外的所有任务，另外一个是低优先级，包括host和service的检 测。循环会先检测高优先级的event队列，然后一个一个执行完毕，最后再判断下host和service的检测是不是有必要，然后再对其进行检测。在执 行event队列的时候，用的函数都是一样的，名字是handle_timed_event，当每个handle_timed_event执行完以后返 回，然后再执行下一个事件任务。

   handle_timed_event函数的开始是个case语句，对事件进行分类处理，具体event_type如下：              nagios实施

1、event_service_check（检查service）
2、event_host_check（检查host）
3、event_command_check（检查cmd文件，被动监控，cgi发送的命令都会送到cmd文件中）
4、event_log_rotation（日志滚动）
5、event_program_shutdown（nagios关闭）
6、event_program_restart（nagios重启）
7、event_check_reaper（检查结果回收）
8、event_orphan_check（检查孤儿host和service）
9、event_retention_save（保存检查结果到retention.dat，关闭nagios不删除此文件）
10、event_status_save（保存检查结果到status.dat，关闭nagios会删除）
11、event_scheduled_downtime
12、event_sfreshness_check（检查service新鲜度？）              nagios培训
13、event_hfreshness_check（检查host新鲜度？）

待续：http://ITIL-foundation.cn/thread-53040-1-1.html
本帖关键字:Nagios

20151030淡然

续上




五、扩展

关于nagios的扩展我们可以从两个方面去思考：1、自己编写插件2、module模块的编写。

其实围绕nagios的开发，已经相当完善了，除了我们上文图中提到的五大模块，我们从官网上还了解到其他的一些nagios插件。

自己编写适合自己的插件。尽管nagios已经提供了大部分的服务监测，但是说实话，很多都是通用的插件，针对自己特殊的服务，不一定适合。我们可以根据自己的需求，去编写自己的插件，增加或者替换以前的插件。

       关于module模块的开发，nagios是基于事件驱动的，所以模块的开发是很重要的，这部分看的不是很详细，不好妄加评论，但是可以肯定的是这部分是可以扩展的。以下是摘自nagios module中的注释，它简短的说明了module的编写：

（This is an example of a very basic module.  It does nothing useful other

* than logging some messages to the main Nagios log file when it is initialized

* (loaded), when it is closed (unloaded), and when aggregated status updates

* occur.  I would not call that too useful, but hopefully it will serve as a

* very basic example of how to write a NEB module...）

       另外我个人觉得关于nagios的开发，我想扩展并不是一条很好的路径，就像前面提到的，围绕nagios的开发已经很成熟了。Nagios其实并不缺什么，该有的插件都有，该实现的功能都已经实现了。但是nagios有值得改进的地方，例如nagios读写文件，如果监视主机数量很大的话，io将是一个机器不小的开销，另外在最终形成服务器可读文件之前，nagios经过了冗余的步骤，在读写文件不停的打转，cpu和内存都有不小的消耗。

技术文档2：nagios流程分析

  在大部分环境中，nagios是不需要优化的，一来监控这个东西大家都不觉得很重要，二来nagios本身已经是个很轻量级的软件，架构比较合理，三来现 在的机器配置都很恐怖，一台普通的pc机撑起上千台host，上三四千service的监控那是小菜一碟，实际环境中有这么大量监控需求的地方本来就不 多，就算有这么大量监控需求的公司，用nagios的并不多数吧！

   但是某些情况下，还是偶尔碰到需要优化的情况。我需要监控的机器数量就超过了1000台，而且用的nagios，用了被动检查的架构以后，撑起这么多的监 控本来是没有问题，但是上周的时候，做nagios和ndotuils 的集成就出现了性能瓶颈，凌晨5点左右，把ndotuils架到两台nagios上之后，应用启动什么的都正常，但是到了上午8点就发现了问题，看到检查 结果的last_check时间从7:20到8:20不等，而且是均匀分布，没有办法，只好把ndomod关掉，到了上午10点左右，就恢复正常了。

   既然nagios出现了瓶颈，就不妨拿源码来看一下，配置文件的选项优化，在nagios的文档里说了很多，但是还是感觉不是很直观，分析源码，只是属于个人兴趣，这里把流程跟大家分享一下，至于优化方案，还是需要大家多多指点了。                  nagios安装

一、nagios在启动以后，载入成daemon，整个的步骤如下：

1、读入配置文件（read_main_config_file）
2、初始化event_broker
3、载入所有broker_mod（ndomod包括在这里面）
4、读入object信息（包括service，host，servicegroup，hostgroup，contact，contactgroup等等）
5、告诉broker，我启动了
6、初始化daemon（例行工作，fork进程，修改根目录，设置信号量等等）
7、打开cmd文件（nagios.cmd）
8、初始化status数据（status.dat）
9、读取保存数据（retention.dat）
10、读取注释数据
11、读取downtime数据
12、读取性能数据
13、初始化event_timing循环
14、初始化check_stats
15、生成status.dat（空的，不写数据）
16、传输event_loop_start信息到broker(ndo：获取scheduling_info中数据)
17、开始event_execution_loop，检查数据，直到捕获重启或者关闭信号

如果接到了重启或者关闭的信号，则继续往下执行
18、通知broker_mod，我要关闭了，或者我要重启了
19、保存retention文件
20、清理性能数据
21、清理downtime数据
22、清理注释数据
23、如果是关闭信号，清理status.dat
24、如果是关闭信号，删除cmd文件                            开源监控软件

   步骤比较简单，其中比较重要的有两个，一个是13，初始化循环，另一个就是17，nagios在作为daemon运行的过程中，就是在不断的执行这个循环。

二、初始化循环
   nagios是个基于事件的监控系统，所有的操作都是由事件触发器触发的。

   nagios启动的时候，会启动一个init_timing_loop函数，来进行事件循环的初始化。
   init_timing_loop主要流程如下：

1、建立scheduling_info表，表的内容有：
        总service数（在时间表外的也算）
        已经在表中的service数
        总host数（时间表外的也算）
        在列表中的host数
        单个host平均service数（总service数/总host数）
        列表中单个host的service数（列表中service数/列表中host数）
        平均service检查时间间隔（service检查总间隔/列表中service数）
        service检查总间隔
        平均service检查延时
        host检查总间隔
        平均host检查延时

      
2、计算最优service检查间隔
        人工设定（配置文件中service_inter_check_delay_method选项）
        智能计算（平均service检查间隔/列表中总service数） ps：呵呵，很傻的办法                   nagios配置
3、将service检测插入event队列
4、计算最优host检查间隔（同2）
5、将host检测插入event队列
6、插入misc事件
        a、重新排列列表（auto_reschedule_checks）
        b、收集检测结果（check_result_reaper_frequency）
        c、检查孤儿service和host（配置文件选项：check_for_orphaned_services，check_for_orphaned_hosts）
        d、检查service新鲜度（针对被动检测，配置文件选项：check_service_freshness）
        e、检查host新鲜度（针对被动检测，配置文件选项：check_host_freshness）
        f、回收检查结果到status文件（status_update_interval，配置文件中频率设置选项为：status_update_interval）
        g、检查cmd文件（command_check_interval，配置文件中检查频率设置选项为：command_check_interval）
        h、日志滚动事件
        i、检查结果保存（retention_update_interval，配置文件中保存频率设置选项为：retention_update_interval）

nagios先将初始化的检查插入misc事件链表中，等待nagios完全启动后，主循环对它进行处理。                  监控软件


三、主循环（event_execution_loop）

   nagios在进入守护状态以后，会一直运行一个循环event_execution_loop，nagios所有的操作全部在这个循环中得到实现。

   循环会不断检查两个event队列，一个是高优先级，包括nagios的除了检查之外的所有任务，另外一个是低优先级，包括host和service的检 测。循环会先检测高优先级的event队列，然后一个一个执行完毕，最后再判断下host和service的检测是不是有必要，然后再对其进行检测。在执 行event队列的时候，用的函数都是一样的，名字是handle_timed_event，当每个handle_timed_event执行完以后返 回，然后再执行下一个事件任务。

   handle_timed_event函数的开始是个case语句，对事件进行分类处理，具体event_type如下：              nagios实施

1、event_service_check（检查service）
2、event_host_check（检查host）
3、event_command_check（检查cmd文件，被动监控，cgi发送的命令都会送到cmd文件中）
4、event_log_rotation（日志滚动）
5、event_program_shutdown（nagios关闭）
6、event_program_restart（nagios重启）
7、event_check_reaper（检查结果回收）
8、event_orphan_check（检查孤儿host和service）
9、event_retention_save（保存检查结果到retention.dat，关闭nagios不删除此文件）
10、event_status_save（保存检查结果到status.dat，关闭nagios会删除）
11、event_scheduled_downtime
12、event_sfreshness_check（检查service新鲜度？）              nagios培训
13、event_hfreshness_check（检查host新鲜度？）

待续：http://ITIL-foundation.cn/thread-53040-1-1.html
本帖关键字:Nagios