CENTRAL
Receives passive check results only
DISTRIBUTED A
227 hosts
835 services
DISTRIBUTED B
67 hosts
243 services
CENTRAL服务器始终低于1秒的平均检查延迟. DISTRIBUTED B目前的平均检查延迟约为10秒,但即便如此,我们会增加更多检查.
DISTRIBUTED A有一些严重的检查延迟问题(有时多达700秒,更少,只是在重新加载后但它会重建),我似乎无法确定.这是当前的icingastats输出:
Icinga Stats 1.10.3 Copyright (c) 2009 Nagios Core Development Team and Community Contributors Copyright (c) 1999-2009 Ethan Galstad Last Modified: 02-11-2014 License: GPL CURRENT STATUS DATA ------------------------------------------------------ Status File: /var/lib/icinga/status.dat Status File Age: 0d 0h 0m 3s Status File Version: 1.10.3 Program Running Time: 1d 17h 30m 44s Icinga PID: 1160 Used/High/Total Command Buffers: 0 / 11 / 4096 Total Services: 839 Services Checked: 839 Services Scheduled: 839 Services Actively Checked: 839 Services Passively Checked: 0 Total Service State Change: 0.000 / 6.250 / 0.007 % Active Service Latency: 644.742 / 776.293 / 729.813 sec Active Service Execution Time: 0.010 / 20.163 / 0.720 sec Active Service State Change: 0.000 / 6.250 / 0.007 % Active Services Last 1/5/15/60 min: 18 / 274 / 717 / 839 Passive Service Latency: 0.000 / 0.000 / 0.000 sec Passive Service State Change: 0.000 / 0.000 / 0.000 % Passive Services Last 1/5/15/60 min: 0 / 0 / 0 / 0 Services Ok/Warn/Unk/Crit: 835 / 2 / 1 / 1 Services Flapping: 0 Services In Downtime: 0 Total Hosts: 227 Hosts Checked: 227 Hosts Scheduled: 227 Hosts Actively Checked: 227 Host Passively Checked: 0 Total Host State Change: 0.000 / 0.000 / 0.000 % Active Host Latency: 0.000 / 772.310 / 726.904 sec Active Host Execution Time: 0.006 / 0.338 / 0.030 sec Active Host State Change: 0.000 / 0.000 / 0.000 % Active Hosts Last 1/5/15/60 min: 14 / 22 / 196 / 227 Passive Host Latency: 0.000 / 0.000 / 0.000 sec Passive Host State Change: 0.000 / 0.000 / 0.000 % Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0 Hosts Up/Down/Unreach: 227 / 0 / 0 Hosts Flapping: 0 Hosts In Downtime: 0 Active Host Checks Last 1/5/15 min: 14 / 28 / 192 Scheduled: 14 / 26 / 188 On-demand: 0 / 2 / 4 Parallel: 14 / 27 / 190 Serial: 0 / 0 / 0 Cached: 0 / 1 / 2 Passive Host Checks Last 1/5/15 min: 0 / 0 / 0 Active Service Checks Last 1/5/15 min: 31 / 276 / 702 Scheduled: 31 / 276 / 702 On-demand: 0 / 0 / 0 Cached: 0 / 0 / 0 Passive Service Checks Last 1/5/15 min: 0 / 0 / 0 External Commands Last 1/5/15 min: 0 / 0 / 0
这似乎不是一个外部检查缓冲区问题,因为它总是0.我已经玩了收割机设置,并尝试了各种组合的最大收割机检查时间(5,10,30)和收割机频率(1,5,10)似乎什么都没有带来时间.
检查status.dat,并不是说某些检查正在推动平均值上升.所有服务检查和主机检查都显示平均延迟(700秒).检查全面的执行时间是否很低.绝大多数是> 1秒.从那里,有143个检查需要超过1秒但不到2秒.有50个检查需要4秒. 4点检查超过这一点,分别为8秒,10秒,17秒和20秒.这些数字似乎并不表示实际的检查时间问题.
服务器本身并不是资源方面的困难,cpu和内存都很好.另外值得注意的是,CENTRAL和DISTRIBUTED A服务器位于相同的物理基础架构上,尽管是不同的VM.
您似乎正在使用Icinga v1,这意味着您有一个完全顺序的Icinga核心.这意味着它在检查后运行检查.如果您的检查花费的时间过多,则会产生延迟.此外,如果您在检查后要执行某些操作,这也会延迟下一次服务检查(如NSCA发送或其他),以至于它确实可以完全杀死您的表现.所以,这是你不会直接测量的东西,因为这不是机器负载的问题,而是Icinga负载的问题.
释放Icinga实例负载的解决方案之一是使用额外的工具.对于分发检查,您可以使用mod gearman.这通常用于制作nagios / icinga设置比例.
如果您使用NSCA,我们开发了a tool以使发送异步从此负担释放Icinga.
我希望这将有所帮助.