分散監視

ライブステータスは、監視コアに統合されたインターフェイスで 他の外部プログラムがステータスデータを照会したり コマンドを実行したりすることができます。ライブステータスはネットワーク経由で利用可能にする ことができるため、リモートの Checkmk サイトからもアクセスできます。 Checkmkのユーザーインターフェースは、ライブステータスを使用して すべてのテザーサイトを一つの概要にまとめます。これにより、まるで 「大規模な」監視システムのような感覚を得ることができます。

次の図は、3 つの場所に分散した ライブステータスによる監視の構造を模式的に示したものです。 Checkmkセントラルサイトは、中央処理サイトにあります。 ここから、中央システムが直接制御されます。さらに、 リモートサイト 1およびリモートサイト 2が 他のネットワークにあり、それぞれのローカルシステムによって制御されています。

この方法の特徴は、リモートサイトの監視ステータスが セントラルサイトに継続的に送信されないことです。GUI は、 コントロールセンターのユーザーが要求した場合にのみ、リモートサイトから ライブデータを取得します。 データは、その後、一元化されたビューにまとめられます。 したがって、中央でデータを保持する必要がないため、 スケーリングアップに大きなメリットがあります。

この方法の利点の一部を以下に示します。

上記のようにライブステータスを使用して分散されたシステムでは、個々のサイトは異なるチームによって独立して保守され、 セントラルサイトは集中管理されたダッシュボードを提供する役割のみを担うことが十分に可能です。

複数のサイト、またはすべてのサイトを同じチームで管理する必要がある場合、中央で設定を行う方がはるかにハンドルしやすくなります。 Checkmk はこれをサポートしており、このような設定を「セントラルセットアップ」と呼んでいます。 これにより、すべてのホストとサービス、ユーザーと許可、期間、通知などがセントラルサイトのSetup で管理され、指定に従ってリモートサイトに自動的に配布されます。

このようなシステムでは、共通のステータス概要だけでなく、共通の設定も使用できるため、事実上「大規模なシステムのような感覚」で使用できます。

このようなシステムは、サブエリアや特定のユーザーグループ専用のステータスインターフェイスとして機能する閲覧専用サイトなどを追加して拡張することもできます。

セントラルサイトには特別な要件はありません。 つまり、ピギーバックデータを正しくハンドルするために必要な 1 つの変更だけで、既存のサイトを分散監視に拡張することができます。 セットアップページSetup > General > Global settings のセクションSite management で、ピギーバックハブを有効にするだけです。

omd create で、リモートサイトは通常の方法で新しいサイトとして生成されます。 これは、当然のことながら、それぞれのリモートサイトに対応する (リモート) サーバーで行われます。

特別な注意事項：

ここでは、myremote1 という名前のリモートサイトを作成する例を示します。

ここで最も重要なステップは、ネットワークの TCP 経由でライブステータスを有効にし、ここでもピギーバックハブを有効にすることです。 ライブステータスはそれ自体は安全なプロトコルではないため、 安全なネットワーク（セキュリティ保護された LAN、VPN など）内でのみ使用してください。 有効化は、サイトが停止している状態で、サイトユーザーとしてomd config を使用して行います。

次に、Distributed Monitoring を選択してください：

LIVESTATUS_TCP をon に設定し、このサーバーで明示的に指定されているLIVESTATUS_TCP_PORT の使用可能なポート番号を入力してください。デフォルトは 6557 です。

保存後、omd start で通常どおりサイトを開始してください。

cmkadmin のパスワードを覚えておいてください。 このパスワードは 2 回だけ必要になります。1 回目はピギーバックハブを有効にするため、2 回目はリモートサイトをセントラルサイトに接続するためです。 リモートサイトがセントラルサイトに従属すると、 すべてのユーザーはセントラルサイトのユーザーに置き換えられます。

これでサイトの準備は完了です。netstat で確認してください。 ポート 6557 が開いていることが表示されます。このポートへの接続は、サイト インターネットスーパーサーバーxinetd によって行われます。このサーバーは、サイト内で直接実行されています。

次に、ユーザーcmkadmin としてリモートインスタンスに一度ログインし、セクションSite management の設定Setup > General > Global を使用してピギーバックハブを有効にします。

分散監視の設定は、セントラルサイトのメニューSetup > General > Distributed monitoring でのみ行います。これは、個々のサイトへの接続を管理するためのものです。 この機能では、セントラルサイト自体がサイトとしてカウントされ、リストにすでに存在しています。

Add connection を使用して、最初のリモートサイトへの接続を定義します。

Basic settings では、omd createで定義したリモートサイトの正確な名前をSite ID として使用することが重要です。 エイリアスは、いつものように任意で定義でき、後で変更することもできます。

Status connection の設定によって、セントラルサイトがライブステータスを介してリモートサイトのステータスを照会する方法が決まります。 スクリーンショットの例は、Connect via TCP(IPv4) 方法による接続を示しています。 これは、レイテンシーが短く（LAN など）、安定した接続に最適です。 WAN 接続に最適な設定については、後で説明します。

ここに、リモート web インターフェイスの HTTP-URL を入力します（check_mk/ の部分のみ）。 基本的に HTTPS 経由で Checkmk にアクセスする場合は、ここでhttp をhttps に置き換えてください。 詳細については、オンラインヘルプまたはHTTPS による web インターフェイスのセキュリティ保護に関する記事をご覧ください。

設定を複製してセントラルセットアップを使用することは、冒頭で説明したようにオプションです。 セントラルサイトからリモートを設定する場合は、Push configuration to this site を選択して複製を有効にしてください。 その場合は、上の画像とまったく同じ設定を選択してください。

指定する必要があるMessage broker port を必ずチェックしてください。 これを確認するには、それぞれのリモートサイトにログインし、コマンドラインからomd config を実行します。Basic セクションに移動します。 ここで、変数RABBITMQ_PORT が関連しています。

URL of remote site の正しい設定は非常に重要です。 URL は必ず/check_mk/ で終わらなければなりません。リモートサイトの Apache が HTTPS をサポートしている場合は、HTTPS による接続をお勧めします。 これは、Linux レベルでリモートに手動でインストールする必要があります。 Checkmk アプライアンスの場合、HTTPS は web ベースのコンフィギュレーションインターフェイスを使用して設定できます。 自己署名証明書を利用する場合は、Ignore SSL certificate errors チェックボックスをオンにする必要があります。

マスクを保存すると、概要に 2 つ目のサイトが表示されます。

（これまでのところ）空のリモートサイトの監視ステータスが正しく統合されました。 セントラルセットアップを使用するには、リモート Checkmk サイト用のlogin がまだ必要です。 この目的のために、セントラルサイトは、ランダムに生成されたログインシークレットをリモートサイトと交換し、それ以降、すべての通信はそれを通じて行われます。 その後、リモートサイトへのcmkadmin アクセスは使用されなくなります。

ログインするには、アクセスデータcmkadmin およびリモートサイトの対応するパスワードを使用してください。Login ボタンをクリックする前に、ボックスConfirm overwrite をオンにしてください。

ログインが成功すると、次のように承認されます。

ログインでエラーが発生した場合は、いくつかの原因が考えられます。 例えば、

最初の 2 つのリストエントリは、ブラウザでリモートの URL を手動で呼び出すことで簡単にテストできます。

すべて正常に完了したら、Activate Changes を実行してください。 これにより、通常どおり、まだアクティブになっていない変更の概要が表示されます。 同時に、概要には、ライブステータス接続の状態、およびセントラルセットアップの個々のサイトの同期状態も表示されます。

Version 列には、各サイトのライブステータスバージョンが表示されます。 CMC をCheckmk のコア（商業版）として使用している場合、コアのバージョン番号 （‘Core’ 列に表示）は、ライブステータスのバージョン番号と同じになります。 Nagios をコア（Checkmk Raw）として使用している場合、Nagios のバージョン番号がここに表示されます。

以下の記号は、設定環境の複製ステータスを示しています。

Status 列には、各サイトのライブステータス接続の状態が表示されます。 これは、設定はライブステータスではなくHTTP経由で送信されるため、 情報としてのみ表示されます。 以下の値が表示されます。

Activate on selected sites ボタンをクリックすると、すべてのサイトが同期され、変更がアクティブになります。 これは並行して実行されるため、全体の時間は最も遅いサイトに必要な時間と同じになります。 この時間には、各サイトの構成スナップショットの作成、HTTP による送信、リモートサイトでのスナップショットの解凍、および変更のアクティブ化が含まれます。

重要：すべてのサイトで同期が完了する前にページを離れないでください 。ページを離れると、同期が中断されます。

分散環境がインストールされたら、その使用を開始できます。 実際には、各ホストに、どのサイトによって監視されるかを指定するだけで済みます。 セントラルサイトはデフォルトで指定されています。

このために必要な属性は、‘Monitored on site’ です。 これは、ホストごとに個別に設定できます。 もちろん、これはフォルダレベルでも実行できます。

ホストの追加は通常どおり行います。ただし、監視 およびサービスディスカバリーは、それぞれのリモート サイトから実行されることを除けば、特別な考慮事項はありません。

ホストをあるサイトから別のサイトに移行する場合、注意すべき点がいくつかあります。 ホストの現在のステータスデータも履歴データも引き継がれません。 設定環境には、ホストの設定のみが残ります。 事実上、ホストは 1 つのサイトから削除され、別のサイトに新しくインストールされたことになります。

ヒストリーの継続性が重要な場合は、監視の実装時に どのホストをどこから監視するかを慎重にプランしてください。

暗号化を実現するために、Checkmk はstunnel プログラムと 独自の証明書および独自の認証機関(CA) を使用して 証明書に署名します。これらは、新しいサイトごとに個別に自動的に生成されるため 、あらかじめ定義された静的な CA または証明書ではありません。これは、偽の 証明書が攻撃者に使用されるのを防ぐための非常に重要な安全対策です。偽の証明書を使用すると、攻撃者は 公開されている CA にアクセスできるからです。

生成された証明書には、以下の特性もあります。

標準の証明書は有効期間が非常に長いため、分類できない接続の問題が発生することを非常に効果的に 防止できます。 同時に、証明書が一度侵害されると、それに応じて長期間、不正使用される可能性があることはもちろん可能です。 したがって、攻撃者が CA またはそれを使用して署名されたサイト証明書にアクセスするおそれがある場合は、 必ず両方の証明書 (CA およびサイト) を交換してください。 古いバージョンからの移行

Checkmk のアップデート中、LIVESTATUS_TCP およびLIVESTATUS_TCP_TLS の 2 つのオプションは自動的に変更されることはありません。 TLS を自動的にアクティブにすると、最終的にはリモートサイトにクエリを送信できなくなる可能性があります。

これまで暗号化されていないライブステータスを使用しており、暗号化を使用することに決めた場合は、手動で暗号化を有効にする必要があります。 これを行うには、まず影響を受けるサイトを停止し、次のコマンドで TLS を有効にしてください。

証明書はアップデート中に自動的に生成されるため、サイトはすぐに新しい暗号化機能を使用します。 セントラルサイトからサイトに引き続きアクセスできるように、[Setup > General > Distributed Monitoring] のメニューで、[Encryption ] オプションがEncrypt data using TLS に設定されていることを確認してください。

最後の手順は上記と同じです。ここでも、まずリモートサイトの CA を信頼済みとしてマークする必要があります。

監視対象ホストへのアクセスはすべて、そのホストが割り当てられている サイトから一貫して実行されます。 これは、実際の監視だけでなく、サービスディスカバリー、診断ページ、通知、アラートハンドラー、その他すべてにも適用されます。 この点は、セントラルサイトが 実際にこのホストにアクセスできるとは想定されていないため、非常に重要です。

標準ビューの一部は、ホストを監視するサイトに応じてグループ化されています 。これは、たとえばAll hosts

サイトは、ホストまたはサービスの詳細にも同様に表示されます。

この情報は、通常、独自のビューを作成する際に 列で使用できます。また、特定のサイトのホストのビューをフィルタリングする フィルタもあります。

サイドバーには、Site status スナップインがあり、を使用して追加できます。 これにより、個々のサイトのステータスが表示されます。 また、ステータスをクリックして、1 つのサイトだけ、または [Disable all ] または [Enable all] をクリックしてすべてのサイトを一時的に使用不能にしたり、再び使用可能にしたりするオプションもあります。

使用不能になったサイトは、ステータスで表示されます。 これにより、タイムアウトを発生させているサイトを無効にして、不要なタイムアウトを回避することもできます。 この無効化は、Setup の接続設定を使用してライブステータスの接続を無効にするものとは異なります。 この「無効化」は、現在ログインしているユーザーにのみ影響し、純粋に視覚的な機能です。 サイトの名前をクリックすると、そのサイトのすべてのホストのビューが表示されます。

分散監視では、Master control スナップインの外観が異なります。 各サイトには、独自のグローバルスイッチがあります。

CheckmkHAクラスタで監視する場合、クラスタの個々のノードは クラスタ自体と同じサイトに割り当てる必要があります。 これは、クラスタ化されたサービスの状態を判断するために、ノードの監視によって生成されたキャッシュ ファイルにアクセスするためです。 このデータは、それぞれのサイトにローカルに保存されています。

一部のチェックプラグインは、ピギーバックデータを使用します。 たとえば、ホストから「ピギーバック」された監視データを個々の仮想マシンに割り当てる場合などです。 分散監視では、ピギーバックホスト（ピギーバックデータを受信するホスト）と、そのピギーバックデータに依存するホスト（ピギーバックデータの実際の消費者）は、必ずしも同じサイトから監視されるとは限りません。 このような場合、ピギーバックデータのサイト間ホスト割り当てを有効にすることができます。

このような通信を有効にするには、参加しているすべてのインスタンスでメッセージブローカーポートが正しく設定されており、ピギーバックハブが有効になっていることを確認するだけです。

これは、少なくとも、ここに「Disabled 」と表示された時点でチェックしてください。

データトラフィックは、通信のボトルネックになることがよくあります。 すべてのポイント間でデータがやり取りされると、すぐに膨大なデータ流量が発生し、通信ネットワークが過負荷になる可能性があります。 そのため、通信チャンネルの数を減らし、データ交換は主にローカルネットワーク内に留めることをお勧めします。 セントラルサイトの負荷を軽減したり、ネットワークトラフィックを最適化したりするために、リモートサイト間で直接通信を行う（ピアツーピア接続）こともできます。 このためには、両方のリモートサイトがセントラルサイトによって設定されている必要があります。つまり、「リモートサイトをセントラルサイトに割り当てる」セクションの説明に従って、Push configuration to this site が両方で有効になっている必要があります。

Setup > General > Distributed monitoring で、メニュー項目Connections > Add peer-to-peer message broker connection を選択します。 ここで一意の ID を割り当て、直接接続する 2 つのサイトを選択します。 インラインヘルプの指示に従ってください。

Checkmk のHW/SW インベントリは、分散環境でも機能します。 その場合、var/check_mk/inventory ディレクトリにあるインベントリデータは リモートからセントラルサイトに定期的に送信する必要があります。 パフォーマンス上の理由から、ユーザーインターフェースは常にこのディレクトリにローカルでアクセスします。 商用版では、Livestatus プロキシを使用して接続されているすべてのサイトで同期が自動的に実行されます。

商業版では、ライブステータスプロキシを使用して接続されているすべてのサイトで同期が自動的に実行されます。 分散システムで CheckmkRaw を使用してインベントリを実行する場合、ディレクトリは

分散システムで Checkmk Raw を使用してインベントリを実行する場合は、ディレクトリを 独自のツール（rsync など）を使用して、セントラルサイトに定期的にミラーリングする必要があります。

すべてのサイトが集中的に監視されている場合でも、個々の サイトのインターフェースにログインすることは可能であり、多くの場合、それが適切です。 このため、Checkmk では、ユーザーのパスワードはすべてのサイトで常に同じになるようになっています。

管理者がパスワードを変更すると、その変更はActivate Changes を使用してすべてのサイトに共有されるとすぐに有効になります。

ユーザーが自分の個人設定のサイドバーを使用してパスワードを変更した場合 は、少し動作が異なります。 ユーザーには当然この機能に対する一般的な権限がないため、Activate changes を実行することはできません。 このような場合、Checkmk は、変更されたパスワードを すべてのサイトに自動的に共有します。 実際には、保存された直後に共有されます。

ご存じのとおり、ネットワークは 100% 可用であるとは限りません。 パスワードの変更時にサイトにアクセスできない場合 そのサイトには新しいパスワードは送信されません。 管理者がActivate changes を正常に実行するか または、次のパスワード変更が正常に実行されるまで、そのサイトでは ユーザーの古いパスワードが保持されます。 ステータス記号により、個々のサイトへのパスワード 共有のステータスがユーザーに通知されます。

リモートで使用されているホストタグは、引き継ぐためにセントラルサイトでも認識されている必要があります。 移行前にこれらをチェックし、不足しているタグはセントラルサイトに手動で追加してください。 ここでは、タグ ID が一致していることが重要です。タグのタイトルは関係ありません。

次に、ホストとルールをセントラルサイトの設定環境に移動します。 これは、サブフォルダ（Main フォルダ以外）にあるホストとルールにのみ機能します。 メインフォルダにあるホストは、まずSetup > Hosts > Hosts を使用して、リモートサイトのサブフォルダに移動してください。

実際の移行は、該当するディレクトリをコピーするだけで簡単に実行できます。 設定環境のフォルダは、~/etc/check_mk/conf.d/wato/ 内のディレクトリに対応しています。 これらのフォルダは、お好みのツール（scp など）を使用して、テザリングサイトからセントラルサイトの同じ場所にコピーできます。 同じ名前のディレクトリがすでに存在する場合、その名前を変更してください。 Linux ユーザーおよびグループは、セントラルサイトでも使用されます。

コピーすると、ホストがセントラルサイトのSetupに表示されます。また、これらのフォルダに作成したルールも表示されます。 フォルダのプロパティもコピーされます。 これらは、隠しファイル.wato 内のディレクトリにあります。

セントラルサイトの親フォルダの機能の属性が正しく継承されるように、移行の最後のステップとして、親フォルダの特性を一度開いて保存する必要があります。これにより、ホストの属性が新たに定義されます。

ライブステータスプロキシのインストールは非常に簡単です。 商業版ではデフォルトで有効になっています。

リモートサイトへの接続設定で、「TCP 経由で接続」ではなく「Use Livestatus Proxy-Daemon」を選択してください。 ホストとポートの詳細は、通常どおりです。

ホストおよびポートの詳細は、これまでと同じです。リモートサイトでは、変更を行う必要はありません。Number of channels to keep open で、プロキシがターゲットサイトに対して確立および維持する TCP 接続の並列接続数を入力します。

TCP 接続プールは、すべての GUI 問い合わせで共有されます。接続数 は、同時に処理できるクエリの最大数を制限します。 これにより、間接的にユーザー数が制限されます。すべてのチャンネルが 予約されている状況では、これはすぐにはエラーにはなりません。GUI は、指定した時間、 空きチャンネルを待ちます。ほとんどのクエリは、実際には数ミリ秒しかかかりません。

GUI がTimeout waiting for a free channel よりも長くチャンネルを待機しなければならない場合 エラーで中断され、ユーザーにエラーメッセージが表示されます。 このような場合は、接続数を増やす必要があります。ただし リモートサイトでは、十分な並列着信接続が許可されている必要があります。これはデフォルトで 20 に設定されています。この設定は、グローバルオプションのMonitoring core > Maximum concurrent Livestatus connections

Regular heartbeat は、プロトコルレベルで接続を常にアクティブに監視します 。このプロセスでは、プロキシは定期的に単純な ライブステータスクエリを送信し、リモートサイトは、あらかじめ決められた時間内 （デフォルト：2 秒）にそれに応答する必要があります。この方法では、ターゲットサーバーと TCP ポートは実際に到達可能ですが、監視コアが応答しなくなった 状況も検出されます。

応答がない場合、すべての接続は「切断」とみなされ 、一定時間（デフォルト：4 秒）の「クールダウン」期間を経て、新たに確立されます。 これらはすべて、ユーザーが GUI ウィンドウを開く必要なく、 プロアクティブに実行されます。 これにより、障害を迅速に検出し、リカバリによって接続を 即座に再確立することができ、最良の場合、 ユーザーが障害に気付く前に接続を復旧することができます。

Caching は、静的クエリはリモートサイトによって 1 回だけ応答すればよく、 その時点からは遅延なく、直接ローカルで応答できることを保証します。 この例としては、Quicksearch で必要な、監視対象のホストのリストがあります。

ライブステータスプロキシには独自のログファイルがあり 、~/var/log/liveproxyd.log にあります。 5 つのチャンネル（標準）を持つ正しく設定されたリモートサイトでは 、次のような内容になります。

ライブステータスプロキシは、その状態を~/var/log/liveproxyd.state ファイルに定期的に記録します。

サイトが現在停止している場合、状態は次のようになります。

ここでは、状態は「starting」です。 したがって、プロキシは接続の確立を試みています。 まだチャンネルはありません。 この状態では、サイトへのクエリはエラーで応答されます。

まず、リモートサイトで、そのホストおよびサービスの設定のコピーを Nagios 設定形式で作成します。また、livedump -TC からの出力をファイルにリダイレクトします。

ファイルの先頭は次のような形式になります:

このファイルをセントラルサイトに送信し (scp など)、~/etc/nagios/conf.d/ ディレクトリに保存します。このディレクトリには、ホストおよびサービスの設定データが保存されます。ファイル名は、.cfg で終わるものを選択してください。たとえば、~/etc/nagios/conf.d/config-myremote1.cfg などです。 リモートサイトからセントラルサイトへの SSH アクセスが可能な場合は、次のように実行できます。

次に、セントラルサイトにログインし、変更をアクティブにします。

これで、リモートサイトのすべてのホストおよびサービスがセントラルサイトに表示されます。 最初はPEND状態になりますが、これは当面は変更されません。

注:

ホストがセントラルサイトに表示されたら、リモートサイトの監視ステータスの（定期的な）送信を設定する必要があります。 再び、livedump でファイルを作成しますが、今回は二次オプションは指定しないでください。 このファイルには、Nagios がチェック結果から直接読み込める形式で、すべてのホストおよびサービスのステータスが含まれます。

このファイルには、Nagios がチェック結果から直接読み込める形式で、すべてのホストおよびサービスの状態が 記録されます。このファイルの先頭は、次のような形式になっています。

このファイルをセントラルサイトの~/tmp/nagios/checkresults ディレクトリにコピーします。 重要：このファイルの名前は、c で始まり、7 文字でなければなりません。scp の場合、次のようなファイルになります。

最後に、セントラルサイトに同じ名前で、拡張子を.ok にした空のファイルを作成します。 これにより、Nagios はステータスファイルが完全に転送されたことを認識し、 読み込むことができるようになります。

リモートホスト/サービスのステータスが、セントラルサイトで即座に更新されます。

ステータスの送信は、これからは定期的に行う必要があります。 スクリプトを使用すると、上記のステップを任意の間隔で繰り返し実行することができます。scp 経由でデータをコピーする代わりに、スクリプトをセントラルサイトから直接実行して、ssh 経由でステータスや設定データを受信することができます。

これらのアクションを実行するためのスクリプトは、GitHubのtreasures ディレクトリで入手できます。

ライブステータスフィルタを使用すると、設定およびステータスのダンプを制限することもできます。 たとえば、ホストをmygroup ホストグループのメンバーに制限することができます。

商業版には、各リモートサイトで個別に有効化できる、集中通知用のビルトインメカニズムが用意されています。 このようなリモートは、すべての通知をセントラルサイトにルーティングして、さらに処理します。 したがって、集中通知は、分散監視が標準的な方法で設定されているか、CMCDump を使用して設定されているか、あるいはこれらの手順を組み合わせて設定されているかに関係なく、機能します。 技術的には、中央通知サーバーは「中央」である必要はありません。このタスクは、任意の Checkmk サイトで行うことができます。

リモートサイトが「転送」に設定されている場合、すべての通知は コアから送信されるのと同じように、セントラルサイトに直接転送されます。 セントラルサイトでは、通知ルールが評価され、実際に 誰にどのように通知するかが決定されます。 必要な通知スクリプトがセントラルサイトで呼び出されます。

リモートサイトとセントラル（通知）サイトの通知スプーラは、TCP 経由で相互に通信します。 通知は、リモートサイトからセントラルサイトに送信されます。セントラルサイトは 、通知が受信されたことをリモートサイトに承認します。これにより 、TCP 接続が切断されても通知が失われることはありません。

TCP接続の構築には2 つの方法があります。

したがって、ネットワーク上の理由により、特定の方向での接続しか確立できない場合でも、通知の転送に支障はありません。 TCP 接続は、ハートビート信号によってスプーラによって監視され、 必要に応じて、通知イベントが発生した場合だけでなく、直ちに再確立されます。 リモートサイトと中央サイトでは異なるグローバル設定が必要であるため、

リモートサイトとセントラルサイトでは異なるグローバル設定が必要であるため、 すべてのリモートサイトに対してサイト固有の設定を行う必要があります。 セントラルサイトの設定は、通常のグローバル設定を使用して行います。 注：この設定は、特定の設定が定義されていないすべてのリモートサイトに自動的に継承されます。

まず、セントラルサイトがリモートサイトへの TCP 接続を確立する例を見てみましょう。

ステップ 1:リモートサイトで、サイト固有のグローバル設定Notifications > Notification Spooler Configuration を編集し、Accept incoming TCP connections を有効にします。 着信接続には、TCP ポート 6555 を推奨します。 問題がなければ、この設定を採用してください。

ステップ 2: 次に、同様に、Notification Spooling サブメニュー （リモートサイトのみ）で、オプションForward to remote site by notification spooler を選択します。

ステップ 3: 次に、セントラルサイト（つまり、通常のグローバル設定）で リモートサイトへの接続を設定します（必要に応じて、追加のリモートサイトにも接続を設定します）。

ステップ 4：グローバル設定の「Notification Spooling 」を 「Asynchronous local delivery by notification spooler 」に設定して、セントラルサイトの 通信も、同じセントラルスプーラーで処理されるようにします。

ステップ 5：変更をアクティブにします。

TCP 接続をリモートから確立する場合は、 手順はまったく同じですが、上記の説明と セントラルサイトとリモートサイトの役割が逆になるだけです。

2 つの手順を組み合わせることもできます。その場合は、セントラルサイトは 着信接続をリッスンし、リモートサイトに接続するように インストールする必要があります。ただし、すべてのセントラル/リモート関係において ペアのうち 1 つだけが接続を確立することができます。

通知スプーラは、~/var/log/mknotifyd.log ファイルにログを記録します。 スプーラの設定で、ログのレベルを上げると、より多くのメッセージを受信することができます。 標準のログレベルでは、セントラルサイトには次のようなメッセージが表示されます。

~/var/log/mknotifyd.state ファイルには、スプーラーとそのすべての接続の現在のステータスが常に記録されます。 中央: ~/var/mknotifyd.state (抜粋)

同じファイルのバージョンは、リモートサイトにも存在します。 そこでは、接続は次のようなものになります。

テストするには、監視対象のリモートサービスを選択し、Fake check results コマンドを使用して、手動でCRIT に設定します。

これで、セントラルサイトの通知ログファイル (notify.log) に、着信通知が表示されます。

同じイベントは、リモートサイトでは次のように表示されます。

グローバル設定では、通知の通常のログファイル (notify.log) と通知スプーラのログファイルの両方を、より高いログレベルに変更することができます。

上記の手順で設定が完了すると、セントラルサイトには 、リモートサイトには、それぞれ新しいサービスが検出されます。このサービスは、必ず 監視対象に追加する必要があります。このサービスは、通知スプーラとその TCP 接続を監視します。 これにより、すべての接続は 2 回、セントラルサイトとリモートサイトそれぞれで監視されます。