Checkmk による監視の基本原則

Checkmk のすべては、ホストと サービスを中心に展開しています。 ホストには、次のようなさまざまなものがあります。

監視では、ホストは常に次のいずれかの状態になります。

状態に加えて、ホストには、ユーザーが設定できるその他の属性がいくつかあります。

監視がUNREACH の状態を判断するには、各ホストに連絡するために使用するパスを知っている必要があります。 この目的のために、各ホストに対して 1 つ以上のいわゆる親ホストを指定することができます。 たとえば、監視から見たサーバーAがルーター B 経由でしか到達できない場合、B は A の親ホストとなります。 Checkmk では、直接の親 のみ設定されます。 これにより、Checkmk サイトが中央にあるツリー状の構造になります (ここでは として表示されています)。

上記のネットワークトポロジの例で、ホストmyhostおよびmyhost4にアクセスできなくなったと仮定します。 myhost4の障害は、myhost が故障していることで説明できます。 したがって、myhost4は監視で「UNREACH 」と分類されます。 Checkmk がmyhost4 に到達できなくなった理由を明確に判断することは不可能であるため、DOWN 状態は状況によっては誤解を招くおそれがあります。 その代わりに、UNREACH はデフォルトで通知を抑制する効果があります。 これは、親概念の最も重要な役割、つまり、単一のポイントで中断が発生して依存するネットワークセグメント全体が監視に到達できなくなった場合に、大量の通知が発生することを回避する役割です。

偽アラームの防止には、商業版で使用されている Checkmk マイクロコア (CMC)の機能も役立ちます。 この機能では、障害が発生したホストの状態変化はしばらく保留され、親に確実に到達できることが確認された場合にのみ進行します。 一方、親が確実に「DOWN 」の場合、ホストは「UNREACH」に切り替わります。この場合、通知は発生しません。

ルーターがクラスタで高可用性を実現している場合など、ホストに複数の親が存在する場合があります。 Checkmk では、これらの親のうち 1 つに到達できる場合、ホストの状態を明確に判断できれば十分です。 したがって、ホストに複数の親が存在し、そのうちの少なくとも 1 つがUP の場合、そのホストは監視上、到達可能とみなされます。 つまり、このような状況では、ホストは自動的にUNREACH 状態には切り替わりません。

ホストには複数のサービスがあります。 サービスは、Windows のサービスと混同しないでください。 サービスは、OK または OK 以外の状態になる、ホストのあらゆる部分または側面です。 当然、状態は、ホストがUP 状態の場合にのみ決定できます。

監視対象のサービスは、次の状態になります。

どの条件が「悪い」かを判断する場合、Checkmk は以下の順序で利用率を決定します。

OK WARN →UNKNOWN→CRIT

チェックは、ホストまたはサービスに状態を割り当てることができることを確認します。 これらの状態については、前のセクションで説明しています。 サービスとチェックは密接に関連しています。 そのため、実際には異なるものですが、このユーザーガイドでも、これらの用語が同じ意味で使用される場合があります。

セットアップでは、各サービスを担当するチェックプラグインを表示することができます。Setup > Hosts でホストのプロパティを開き、Host > Run service discovery メニューでこのホストのサービスのリストを表示します。 次に、Display > Show plugin names を使用して、各サービスを担当するチェックプラグインを表示する新しい列を表示します。

df チェックプラグインの例からわかるように、1 つのチェックプラグインは複数のサービスに対応することができます。 ちなみに、列にリストされているチェックプラグインの名前は、チェックプラグインの説明を表示するリンクでもあります。

サービスとチェックの接続および依存関係は、監視でも確認できます。 監視中のホストのサービスリストでは、Reschedule エントリのアクションメニューに、一部のサービスには黄色の矢印 ()、その他のほとんどのサービスには灰色の矢印 () が表示されています。 黄色の矢印が付いているサービスは、アクティブチェックに基づいています。

このようなアクティブチェックは、Checkmk によって直接実行されます。 灰色の矢印が付いているサービスは、別のサービスであるCheck_MK サービスからデータを取得するパッシブチェックに基づいています。 これはパフォーマンス上の理由によるもので、Checkmk の特別な機能です。

Checkmk は、UP でないすべてのホスト、およびOK でないすべてのサービスを問題として識別します。 問題には、未処理と 処理済みの 2 つの状態があります。 手順としては、新しい問題はまず未処理として扱われます。 誰かが問題を確認すると、その問題は処理済みとしてフラグが付けられます。当然のことながら、未処理の問題は、まだ対処されていない問題です。 そのため、サイドバーの「概要」では、この 2 種類の問題が区別されています。

ちなみに、現在UP ではないホストからのサービス問題は、問題として認識されません。

承認の詳細については、別の記事をご覧ください。

ホストの状態が変化した場合 (OK からCRIT へ変化した場合など)、Checkmk は監視イベントを登録します。 これらのイベントは、通知を生成する場合と生成しない場合があります。 Checkmk は、ホストまたはサービスに問題が発生すると、そのオブジェクトの連絡先に電子メールが送信されるように設計されています (デフォルトでは、新しく作成されたユーザーはどのオブジェクトの連絡先にも登録されていません)。 ただし、これらは非常に柔軟にカスタマイズすることができます。 通知は、いくつかのパラメータにも依存します。 通知が送信されない場合を見てみると、最もわかりやすいでしょう。 通知は、以下の場合に抑制されます。

通知を抑制するためのこれらの前提条件のいずれも満たされない場合、監視コアは通知を作成し 、次のステップで一連のルールを通過します。 これらのルールでは、さらに除外基準を定義し、通知の対象者と通知のフォーム（電子メール、SMS など）を決定することができます。

通知に関する詳細は、通知の記事をご覧ください。

サービスが継続的に、かつ迅速に条件を変更する場合があります。 継続的な通知を回避するため、Checkmk はそのようなサービスをフラッピング状態に切り替えます。 これは、アイコンで表示されます。

サービスがフラッピング状態になると、ユーザーに状況を知らせる通知が生成され、それ以降の通知は停止されます。 適切な時間が経過しても、それ以上の急激な変化がなく、最終的な（良好または不良）状態が明らかになった場合、フラッピング状態は解除され、通常の通知が再開されます。

サーバー、デバイス、またはソフトウェアのメンテナンス作業を行う場合、通常はその間、問題通知は避けたいでしょう。 さらに、その間に監視で問題が発生しても、一時的に無視してよいことを同僚に知らせておきたいでしょう。

この目的のために、ホストまたはサービスにスケジュールダウンタイムの条件を入力することができます。 これは、作業を開始する前に直接、または事前に実行することができます。 スケジュールダウンタイムは、次のアイコンで表示されます。

ホストまたはサービスがスケジュールダウンタイム中である間：

さらに、後でホストおよびサービスの可用性に関する統計情報を文書化したい場合 スケジュールダウンタイムを含めることをお勧めします。 これらは、後の可用性評価に考慮することができます。

Checkmk をしばらく使用していると、ホストおよびサービスのビューに蜘蛛の巣が表示される場合があります。 たとえば、サービスの場合、次のように表示されます。

これらの蜘蛛の巣は、面白くない状態を表しています。 面白くないホストまたはサービスがある場合、これは Overviewスナップインにも表示され、列Stale

しかし、この「古い」状態とは一体どういう意味なのでしょうか？ 一般的に、ホストまたはサービスは、Checkmk がその状態に関する最新情報を長期間受信しなくなった場合に「古い」とマークされます。

ホストおよびサービスが古いとみなされるまでの時間制限は、チェック間隔のセクションで調整できます。

チェックを実行する期間を制限することができます。 この目的には、ルールセット「Check period for hosts 」、「Check period for active services 」、「Check period for passive Checkmk services 」を使用します。 これらのルールを使用して、利用可能な期間の中からチェック期間として 1 つを選択してください。

チェックは、状態ベースの監視において、固定の間隔で実行されます。 Checkmk は、サービスチェックには 1 分、Smart Ping によるホストチェックには 6 秒をデフォルトとして使用します。

これらのデフォルトは、Normal check interval for service checks およびNormal check interval for host checks ルールセットを使用して上書きできます。

チェック期間とチェック間隔を組み合わせると、1 日に 1 回、特定の時間にアクティブチェックが確実に実行されます。 たとえば、チェック間隔を 24 時間に、チェック期間を毎日 2:00 から 2:01（つまり 1 日 1 分）に設定した場合、Checkmk はチェックが実際にこの短い時間枠に移動されるようにします。

この定義されたチェック期間外では、サービスの状態は更新されなくなり、サービスは アイコンで「面白くない」とマークされます。 グローバル設定の「Staleness value to mark hosts / services stale 」では、ホスト/サービスが「面白くない」とマークされるまでの時間を定義できます。 この設定は、Setup > General > Global settings > User interface:

この係数は、チェック間隔のn 倍を表します。 したがって、チェック間隔が 1 分（60 秒）に設定されている場合、新しいチェック結果がないサービスは、その 1.5 倍の時間、つまり 90 秒後に「面白くない」状態になります。

チェックの試行回数オプションを使用すると、散発的なエラーが発生した場合に通知を回避することができます。 これにより、チェックの感度が低下します。 この目的には、Maximum number of check attempts for host およびMaximum number of check attempts for service というルールセットを使用できます。

たとえば、チェックの試行回数が 3 に設定されており、対応するサービスがCRIT になった場合、最初は通知はトリガーされません。 次の 2 回のチェックでもOK 以外の結果になった場合にのみ、現在の試行回数が 3 に増え、通知が送信されます。

この中間状態、つまりOK ではないものの、チェックの試行回数が最大回数に達していないサービスは、ソフトステートになります。 ハードステートになった場合にのみ、通知が実際にトリガーされます。