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秒以上です。そこから、1秒以上2秒未満かかる143のチェックがあります。 4秒以上かかる50のチェックがあります。 4つのチェックがこのポイントを上回り、それぞれ8、10、17、20秒かかります。これらの数値は、実際のチェック時間の問題を示しているようには見えません。
サーバー自体はリソースに関して苦労していません。CPUとメモリの両方に問題はありません。また、VMが異なっていても、CENTRALサーバーとDISTRIBUTEDAサーバーが同じ物理インフラストラクチャ上にあることも注目に値します。
これで問題が完全に解決されるかどうかはわかりませんが、ここにいくつかの場所があります。
Icinga v1を使用しているようです。つまり、完全にシーケンシャルなIcingaコアがあります。これは、チェックの後にチェックを実行することを意味します。チェックに少し時間がかかりすぎると、待ち時間が発生します。さらに、チェック後に実行するアクションがある場合、これにより、次のサービスチェック（NSCA送信など）が遅延し、実際にパフォーマンスが完全に停止する可能性があります。したがって、これはマシンの負荷の問題ではなく、Icingaの負荷の問題であるため、直接測定することはできません。
Icingaインスタンスの負荷を解放するための解決策の1つは、追加のツールを使用することです。小切手を配布するには、たとえば mod gearman を使用できます。これは、nagios/icingaセットアップスケールを作成するためによく使用されます。 NSCAを使用する場合、Icingaをこの負担から解放するために、送信を非同期にするために ツール を開発しました。
これがお役に立てば幸いです。