Nagios / Icingaチェックの遅延
サーバーの正常性を監視する場合、一部の障害または警告はすぐに緊急になりますが、他の障害または警告は、それらが持続する場合にのみ問題になります。私は次のようなことを考えています：
- 一部のソフトウェアを更新する必要があります
- 時間オフセットはNTPとは異なります
対処されていない場合、これらは実際の問題になる可能性がありますが、それらを処理するためのバックグラウンドサービスがすでに用意されています-無人アップグレード、NTPクライアントサービスなど。問題が発生してからの間に常に短い遅延がありますこれらのバックグラウンドプロセスはそれらに対処するために開始され、モニターはそのギャップで一連の電子メールを送信します-その後、問題が修正された1分後に再び送信します。私は通常、「問題」の電子メールの山に目覚めます。対応する「RESOLUTION」メールが1分後に送信されます。危険なのは、100の無関係な警告を却下する際に、実際の警告を見逃す可能性があることです。
それで、問題が特定の時間、たとえば5分以上継続した場合にのみ、問題を報告するようにIcingaまたはNagiosに指示する方法はありますか？
SvWは、彼が書いた内容に誤りはありませんが、変数max_check_attemptsも調査する必要があります。これは、HARDエラーが発生して通知する前にサービスが失敗する必要があるチェックの数を定義します。
私のヘアトリガーサービスのいくつかについては、
max_check_attempts 2
check_interval 2
retry_interval 1
つまり、NAGIOSは通常よりも頻繁にチェックし、何かがダウンしていることに気づいたら、1分待ってからもう一度チェックしてから、通知します。しばらくダウンするまで気にしない他のサービスについては、
max_check_attempts 12
check_interval 5
retry_interval 5
つまり、NAGIOSは何かがダウンしていることに気付くと、通常どおり5分ごとにチェックを続け、1時間ダウンするまで教えてくれません。
それは間違いなくあなたが気にかけていることについて、あなたが気にかけているときに、そして他に何も教えてくれるまで、NAGIOSを調整する価値があります。誤検知の雲を発する（つまり、本当に気にしない通知を大量に送信する）監視システムは、誤検知がある（つまり、実際の問題に気付かない）ものとほぼ同じくらい役に立たない。
詳細な構成を定義して、サービスのチェックに関するすべての詳細をNagiosに伝えることができます。
check_intervalおよびretry_interval構成オプションを調べて、そこにいる間に、一般的な期間について学習します。