icinga2を使用したDebian5、6、7ホストの監視
Debian 8にicinga2とicinga2-webを正常にインストールしました。問題は、Debian 5、6、7がインストールされているサーバーを監視する必要があることです。それも可能ですか？
正しく理解している場合（監視したいホストにicinga2クライアントをインストールする必要があり、icinga2に特定のクライアントのようなものはありません）、icinga2パッケージ全体をインストールする必要があります。
このパッケージをバックポートからスクイーズにインストールしようとしましたが（手順はここにあります： http://debmon.org/instructions ）、成功しませんでした。
監視から冒険を始めるとき、私はあらゆる助けをいただければ幸いです。前もって感謝します。
「クライアント」と呼んでいるノードにicinga2バイナリパッケージをインストールするだけでは混乱するかもしれませんが、そうすることは合理的です。
そうすれば、次のメリットが得られます。
- マスター、サテライト、クライアント、エージェント、またはそれらに割り当てるその他の役割など、（クラスター）分散セットアップ内のすべてのノードに対して同じセットアップ。
- 関係するすべてのノードに同じ構成DSL
- クライアントは、クラスターノードと同じ利点を使用します。SSLx509、IPv4およびIPv6のサポート、接続損失時のログの再生などです。
クライアントのセットアップは、CLIウィザードとCSR自動署名メカニズムで支援されます。 Icinga 2のゾーンとエンドポイントの概念に既に精通している場合は、独自のツールを使用してクライアントを構成したり、SSL証明書を展開したりすることもできます（Puppet CAを再利用するなど）。
時間が経つにつれて、コミュニティで使用される3つの異なる方法がありましたが、現在では人気があり、ドキュメントで詳細に説明する必要があります（これは、読むのが混乱し、まだToDoリストにあります）。
1）ローカル構成のクライアント。 Icinga 2には、ローカルノードを監視するいくつかの基本的なチェック例が付属しています。新しいチェックをローカルに追加してIcinga2を再起動すると、クライアントのコアがチェックの実行を開始し、それらをコネクタマスターノードに報告します。マスターでは、収集されたリポジトリからノードを一覧表示し、それらをブラック/ホワイトリストに登録してから、「nodeupdate-config」を使用して構成を生成できます。
各クライアントの構成を自分で管理するのが面倒だと感じた場合、それは事実ですが、自動化とローカル構成の観点からは、それでも有効なポイントです。
2）（衛星および）クライアントを備えた中央構成マスター。この方法では、Icinga 2クラスターのゾーンとエンドポイントのメカニズムを再利用し、マスターからクライアントに構成を分散させることができます。そうすれば、マスター上のホスト/サービスオブジェクトを管理し、残りをIcinga2に処理させることができます。テンプレート、チェックコマンドなどを含むグローバルゾーン用のスペースもあります。
そのシナリオでは、クライアントを1回セットアップし、残りはマスターに処理させます。また、クライアントのローカルスケジューラの利点も得られます。このスケジューラは、接続の再確立時にチェック履歴をチェックして再生し続けます（これは、SLAレポート）に確かに役立ちます）。
3）ローカルスケジューラなしでチェック実行のようなNRPEを探しているが、クイックコマンドプラグインエグゼキュータを探している場合は、クライアントを「コマンド実行ブリッジ」として使用できます。そのシナリオでは、最初にクライアントを1回セットアップし、そのエンドポイント/ゾーン構成をマスターに追加します。チェック可能なホスト/サービスオブジェクトもマスターで構成されますが、いわゆる「command_endpoint」を参照します。これにより、Icinga2はチェックの実行をIcinga2クライアントに送信します。このクライアントは、チェックを非同期に実行し、結果をマスターに送り返します。
クライアントには引き続きローカルのCheckCommand定義が必要です。 Icingaテンプレートライブラリ（ITL）はすでにそれらをたくさん提供していますが、独自のものを追加することを検討している場合は、コマンド構成を同期するグローバルゾーンのみを使用して2）を取ることを検討する必要があります。
このようにして、マスターに渡された特定のコマンドパラメーターを特定のクライアントで無効にできるようにすることもできます（nrpeの悪名高い「-a」パラメーターですが、より制御された方法で）。
詳細については、ドキュメントをご覧ください： http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/icinga2-client#icinga2-client-scenarios
Debian 5 Lennyに関しては、これはサポート終了であるため、Icinga2ではサポートされていません。次にcheck_by_sshに移動します。 http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check-command-by-ssh
Icingaはnagiosのフォークであり、監視に同じプラグイン/クライアントを使用します。必要なのはnrpeデーモンとnagios-pluginsです。
Nrpeデーモンは、監視するサーバーで実行されており、リモートのnagios/icingaからのリクエストをリッスンしています。このようなリクエストが来ると、特定のプラグインを実行して、結果をicingaサーバーに返すことができます。
Nagiosプラグインは、特定のサービス/リソースのステータスをチェックし、条件に応じてOK、WARNING、CRITICALで報告する小さなプログラムのコレクションです。
必要なパッケージは次のとおりです。
- nagios-プラグイン
- nagios-nrpe-server
監視する各サーバーにインストールする必要があります。
外部で利用可能なサービス（HTTPなど）の可用性を確認するだけでよい場合は、クライアントにソフトウェアをインストールする必要はありません。