Nagios にスケジューリングとチェックを処理させるかどうかについては、Nagios のバージョン (新しいバージョンではこれらのチェックを同時に実行できます) と、別のデーモンが必要な理由によって異なるため、お任せします。Nagios のバージョニングに関しては、バージョン 3 IIRC は同時チェックを使用するため、レポートよりも多くのノード数にスケーリングされます。
ただし、Web サイトの Postfix キュー統計と TTFB 追跡で行ったように、Redis ルートの概念に答えることができます。
curl および multiprocessing モジュールを使用して Python を使用してチェックを設定するのは、Redis にダンプするのと同様に非常に簡単です。の有効期限は、DB が成長しないようにするための堅実なアイデアであると言えます。古いチェック結果を取得しないように、この値をチェック間隔より大きくしない (または小さくする) ことをお勧めします。現在実行中のチェックが完了しておらず、Redis-to-Nagios チェックが実行され、前のチェックがプルされた場合、失敗したチェックを見逃す可能性があります。
Redis-To-Nagios チェックの場合、簡単な redis-cli+bash スクリプトまたは Python チェックを使用して、特定のホストのデータをプルします。データに応じて OK を返すか、そうでない場合はかなり簡単で、十分に速く実行されます。
Nagios チェック サーバーで Redis インスタンスを実行して、レイテンシを最小限に抑え、チェックで誤ったアラートを引き起こすネットワークの問題を回避することをお勧めします。また、Redis インスタンスとチェック デーモンで Nagios チェックを行うことをお勧めします。実行中の Redis および http_check デーモンに依存する check_http 置換チェックを作成します。したがって、次のような依存関係チェーンがあります。
Redis -> http_checkd -> http_check_replacement
これにより、問題が特定され、http_check_replacement での誤ったアラートが防止されます。たとえば、redis_checkd が停止した場合、200 以上の「http_check_replacement の失敗」ではなく、その警告が表示されます。
また、Redis のデータは定義上一時的なものであるため、ディスクの永続性を無効にします。データが常に回転している場合、ディスクに書き込む必要はありません。
余談ですが、libcurl を使用している場合は、接続を開くのにかかる時間とサーバーが応答するまでの時間 (最初のバイトまでの時間 - TTFB) に関する統計を libcurl から取得し、Nagios の機能を利用することをお勧めします。チェック統計を保存します。そのデータがあれば、トラブルシューティングやパフォーマンス分析に非常に役立つ時代が来るかもしれません。
これを実行してローカルの Redis インスタンスにアップロードする C で記述した CLI ツールがあります。高速です。URL を取得する時間よりもわずかに長くなります。Nagios スタイルの出力をかなり簡単に追加できます。実際、来週か 2 週間以内にそれを行うと思います。