icinga ido2db

nebcallbacks.h 定义不同的回调类型
nebmods.c .h加载各个模块，初始化回调列表，将回调函数注册到回调列表,调用某个回调函数（一般都有相反的操作函数，比如卸载模块，销毁回调列表）
idomod.c .h将各个回调函数注册到回调列表里，不同回调函数的实现，回调函数就是把icinga产生的数据发送到ido2db进程入库处理，将配置文件的数据也发送到ido2db入库
broker.c .h将构造不同的回调参数组成不同的结构发送到回调函数里

1、分析启动icinga的参数，如果是检验配置参数，检验完就退出，如果是测试，测试完也退出
2、读取主配置文件read_main_config_file(config_file)，包括初始化一些列表，比如主机列表，服务列表，命令列表，模块列表等等
3、读取各个模块的配置信息read_object_config_data(config_file,READ_MODULES,FALSE,FALSE)，加载各个模块add_module_objects_to_neb()到模块列表
4、删除权限，设置相应的权限
5、初始化回调函数的列表，然后加载各个模块的函数neb_load_all_modules()到回调列表neb_callback_list，neb_load_module使用动态链接库的方式取得各个模块的自己的初始化函数nebmodule_init，然后调用idomod_register_callbacks注册类型的回调函数，其实所有的都是调用idomod_broker_data函数，在改函数内根据类型进行分发处理，neb_callback_list列表的每个类型是一个列表
neb_callback_list[callback_type]=new_callback，注册时会根据优先级插入相应的列表中
6、读取所有的对象信息read_all_object_data(config_file)，包括service，host，servicegroup，hostgroup，contact，contactgroup等等
7、发送信息到ido2db，告诉他icinga启动了
8、初始化daemon，fock子进程，父进程退出不让子进程成为僵尸进程，让子进程变为会话进程，将进程的id写到锁文件，重定向三个标准流
9、打开命令文件icinga.cmd，初始化命令文件的工作线程init_command_file_worker_thread，使用poll函数监控命令文件的变化，有输入的话，告诉线程读取命令然后作为事件
10、read_initial_state_information读取retention.dat文件初始化主机、服务的状态信息放到内存，并将数据发送给ido2db入库
11、initialize_comment_data读取注释数据
12、initialize_downtime_data读取downtime数据
13、initialize_performance_data读取性能数据
14、init_timing_loop初始化事件信息，包括每个主机，服务定期检查事件，检查新鲜度的事件，收集检查结果的事件，定期保存状态数据的事件status.dat，检查外部命令的事件，转换日志事件定期保存状态信息到retention.dat事件
15、统计当前的状态信息
16、更新所有的状态信息，记录状态信息到status.dat
17、开始事件的死循环event_execution_loop，检查要执行的事件，直到捕获重启或关闭信号等

捕获到信号：
18、通知broker_mod，我要关闭了，或者我要重启了
19、保存retention文件
20、清理性能数据
21、清理downtime数据
22、清理注释数据
23、如果是关闭信号，清理status.dat
24、如果是关闭信号，删除cmd文件

初始化循环的操作：
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：呵呵，很傻的办法
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）

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


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

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

handle_timed_event函数的开始是个case语句，对事件进行分类处理，具体event_type如下：
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（icinga关闭）
6、event_program_restart（icinga重启）
7、event_check_reaper（检查结果回收）
8、event_orphan_check（检查孤儿host和service）
9、event_retention_save（保存检查结果到retention.dat，关闭icinga不删除此文件）
10、event_status_save（保存检查结果到status.dat，关闭icinga会删除）
11、event_scheduled_downtime
12、event_sfreshness_check（检查service新鲜度？）
13、event_hfreshness_check（检查host新鲜度？）
14、event_expire_downtime
15、event_reschedule_checks（重新编排event列表，与上文说的初始化循环类似）
16、event_expire_comment
17、event_user_function

把结果保存到retention.dat中，主要是为了关闭icinga后再启动，可以读入关闭时候的状态，而用不着重新检查，而结果保存到status.dat中，主要是给cgi读取展示用的

主动监测（event_service_check，event_host_check）：
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），就不会有问题。

结果回收（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再对结果进行处理，这些处理包括了：
更新检查结果到service_list链表，检查抖动，记录状态日志文件，发送状态数据给icinga，报警等等

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的最新的检查结果，很多操作都是基于这两个列表进行的。

对别人劳动给予尊重，以上自己写了部分，很多转自http://www.cublog.cn/u2/89218/showart_2019597.html

ido2db的一些分析：
common.h 一些公共的数据定义或函数
db.h 预处理一些oracle的执行语句缓存在内存中以及其他的一些数据库操作
dbhandlers.h 主要将接受到的数据进行处理，比如转换类型等等
dbqueries.h 数据库的增删改查操作，涉及到oracle的操作一般会使用在db.h中被缓存的数据库操作
ido2db.h 是主要的数据处理进程，包括接受icinga发送过来的数据，在内存中组织数据成一定的结构，然后调用数据库操作函数将数据入库。
它有一个进程来将数据入库，还起了一个线程在一定的时候将一些过期的数据清理掉。所以再查看ido2db这个名字的进程时，会发现一般有4个，一个是监听客户端的链接，
一个是进程与icinga之间的数据传输，主进程与数据库的链接，还有一个线程与数据库的链接
idomod.h 将icinga监控到的数据传输到ido2db进程做入库处理（这个模块共有三种处理数据的方式，记录到文件里或输出到文件描述符为1的输出设备、tcpsocket、unixsocket，
如果连接有问题会将数据先保存到一个文件，然后在可以连接的时候将数据发送出去）
io.h 一些文件的读写操作
protoapi.h 定义了客户端与服务器之间数据通信的协议
utils.h 工具函数

协议例子：
213: --> IDO_API_XXX -->这个协议是干什么的 213是IDO_API_SERVICESTATUSDATA代表服务状态数据
1=1202 --> IDO_DATA_TYPE对那个表执行什么操作，在broker.h定义
2=0 --> IDO_DATA_FLAGS
3=0 --> IDO_DATA_ATTRIBUTES
4=1310698403.249130 --> IDO_DATA_TIMESTAMP
53=cmrelaytobj02 -->从这个开始以下的数据属性
114=check_linuxdisk_03
95=/home used 87% [ Used/Total---189423M/218065M---Current left 28642M ] (>75%) : WARNING
125=
99=
27=1
51=1
115=1
25=1
76=1
61=1310698402
83=1310698522
12=0
63=1310567362
57=1310567362
56=1
66=1307756280
70=1310698402
67=0
64=1310256606
121=1
62=0
84=8
85=0
88=0
101=0
7=0
26=0
97=1
38=1
9=1
47=1
54=0
98=0.00000
71=0.19700
42=0.15526
113=0
45=1
103=1
93=1
80=0
37=
11=check_linuxdisk!L97iDuba!75!90!/home
86=2.000000
109=1.000000
209=24x7
999 --> IDO_API_ENDDATA结束