CMC の特別な特徴

ホストチェックは、ホストが完全に故障した場合に通知をトリガーするだけでなく、ホストの計画的なダウンタイム中にサービスの問題に関する通知を抑制する役割も果たします。 サービスの問題は、サービス自体の問題ではなく、ホストの故障条件によって発生する場合があります。 Checkmk での最後のホストチェックの結果が「UP 」であっても、実際にはホストが「DOWN 」である場合があります。 このような条件では、複数のサービスチェックがホストの「DOWN 」の状態に依存する問題を報告し、誤ってサービス通知が送信される可能性があります。 したがって、サービス問題が発生した場合は、まずサービスのホストの状態を確認することが重要です。

CMC はこの問題を非常に簡単に解決します。 サービス問題が発生し、ホストが「UP 」状態の場合、CMC は次のホストチェックを待ちます。 間隔は（デフォルトで）6 秒と非常に短いため、ホストが「UP 」のままで、サービスに関する通知を送信する必要がある場合でも、通知の遅延はごくわずかです。

例として、クエリした web サーバーが利用できないために、check_http プラグインがCRIT 状態を通知する場合を考えてみましょう。 この状況では、サービスチェックの開始後に、 icmpreceiver コンポーネントがこのサーバーから TCP RST パケット（接続拒否）を受信します。 したがって、CMC はホスト自体がUP であることを確実に認識し、通知を遅滞なく送信することができます。

親ホストが定義されている場合、ネットワークの停止を計算する際にも同じ原則が利用されます。 ここでも、確認された状態を待つために、通知が一時的に遅延する場合があります。

この手順には以下の利点があります：

ただし、1 つの欠点があります。 Smart Ping ホストチェックでは、パフォーマンスデータ (パケットのランタイム) は生成されません。

これが必要なホストでは、Check hosts with PING (ICMP Echo Request) ルールセットを使用して、pingによるアクティブチェックを設定するだけで対応できます。

実際には、すべてのホストが ping によってチェックできるわけではありません。 このような場合、CMC の他の方法、たとえば TCP 接続などをホストチェックに使用することもできます。 これらは一般的に例外であるため、全体的なパフォーマンスに悪影響はありません。 ここで設定するルールセットは、Host check command です。

アクセスできないホストへの TCP 接続パケットに対して、TCP RST パケットで応答するファイアウォールがあります。 このファイアウォールは、このパケットの送信者として自身を登録することは許可されておらず、ターゲットホストの IP アドレスを指定する必要があります。 Smart Ping は、このパケットを「応答あり」と認識し、ターゲットホストがアクセス可能であると誤って判断します。

このような (まれな) 状況では、Global settings > Monitoring core > Tuning of Smart PING で、Ignore TCP RST packets when determining host state オプションを有効にすることができます。 または、check_icmp で、影響を受けるホストのホストチェックとして従来の ping を選択することができます。

コアのフォークを回避するため、プログラムの起動時に CMC は、アクティブチェックプラグインを起動するタスクを持つ、非常に軽量な補助プロセスを一定数作成します。 これらのプロセスは、フォークの速度がはるかに速いだけでなく、コア自体がブロックされなくなるため、利用可能なすべてのコアにスケールアップしてフォークを行うことができます。 これにより、実際にはランタイムが非常に短いアクティブチェック（check_http など）の実行が大幅に高速化されます。

しかし、CMC はさらに一歩進んでいます。Checkmk 環境では、アクティブチェックはむしろ例外的なものだからです。 ここでは、ホストおよび間隔ごとに 1 回のフォークのみを必要とする Checkmk ベースのチェックが主に使用されています。

これらのチェックの実行を最適化するために、CMC は 2 種類の補助プロセス、Checkmk フェッチャーと Checkmk チェッカーを維持しています。

デフォルトで起動されるチェックヘルパー（アクティブチェック）、Checkmkフェッチャー、およびCheckmkチェッカーの数は、Global settings > Monitoring core で定義されており、ユーザーでカスタマイズすることができます。

デフォルト値を変更する必要があるかどうか、および変更する方法を確認するには、いくつかの方法があります。

サイドバーの「Core statistics 」スナップインには、過去 10～20 秒間の平均利用率がパーセンテージで表示されます。

すべての補助プロセスタイプについて、設定されたチェックを実行するのに十分なプロセスが常に存在する必要があります。 プールが 100% 利用されている場合、チェックは時間通りに実行されず、レイテンシーが拡大し、サービスの状態が最新情報から遅れてしまいます。

サイトの起動後数分で、使用状況が80% を超えてはいけません。 それ以上の割合の場合は、プロセスの数を増やす必要があります。 必要な Checkmk フェッチャーの数は、監視対象のホストおよびサービスの数に応じて増加するため、ここでは修正が必要になる可能性が高いです。 ただし、各プロセスはリソースを消費するため、実際に必要な数の補助プロセスだけを作成するように注意してください。 さらに、CMC の起動時にすべての補助プロセスが並行して初期化されるため、負荷のピークが発生する可能性があります。

Core statistics スナップインには、使用状況だけでなく、レイテンシーも表示されます。 これらの値については、単純なルールが適用されます。つまり、低いほど良い、つまり 0 秒が最適です。

Core statistics スナップインの代わりに、Setup > Maintenance > Analyze configuration を使用して、Checkmk で構成を分析することもできます。 この方法の利点は、Checkmk から補助プロセスの状態を即座に評価できることです。 補助プロセスのいずれかがOK でない場合、ヘルプテキストから対応するGlobal settings オプションを開いて、プロセスの値を変更できるのが非常に便利です。