Icinga - 分佈式環境中非常高的檢查延遲
我有一個分佈式 Icinga 設置，如下所示：
中央
僅接收被動檢查結果
分佈式A
227 台主機
835 服務
分佈式 B
67 台主機
243 項服務
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 伺服器位於相同的物理基礎架構上，儘管虛擬機不同。
我不確定這是否能完全解決您的問題，但這裡有一些地方可以查看。
您似乎正在使用 Icinga v1，這意味著您有一個完全順序的 Icinga 核心。這意味著它會在檢查後執行檢查。如果您的檢查花費了太多時間，則會產生延遲。此外，如果您在檢查後要執行一些操作，這也會延遲下一次服務檢查（如 NSCA 發送或其他），以至於它確實可以完全扼殺您的性能。因此，這是您不會直接測量的東西，因為這不是機器負載的問題，而是 Icinga 負載的問題。
釋放 Icinga 實例負載的解決方案之一是使用額外的工具。例如，為了分發支票，您可以使用mod gearman。這通常用於製作 nagios/icinga 設置比例。如果您使用 NSCA，我們開發了一個工具來使發送非同步以釋放 Icinga 的這種負擔。
我希望這將有所幫助。