ルール

例として、ファイルシステムの監視におけるWARN およびCRIT の閾値の設定を見てみましょう。 データベース指向の設定では、ファイルシステムごとに 1 行ずつテーブルに入力します。

これは比較的簡単ですが、この例では表が短いからです。 実際には、ファイルシステムは数百、数千にも及ぶことがよくあります。 コピー＆ペーストやバルクアクションなどのツールを使用すると作業を簡略化できますが、基本的な問題、つまり標準的なポリシーをどのように決定し、実装するかという課題は残ります。 一般的なルールは何でしょうか？ 将来のホストの閾値はどのようにあらかじめ設定すべきでしょうか？

しかし、ルールベースの構成はポリシーで構成されています。 上記の表のロジックを 4 つのルールに置き換えます。myserver001 がテストシステムであり 、いずれの場合も最初の関連ルールがすべてのファイルシステムに適用されると仮定すると 、結果は上記の表と同じ閾値になります。

確かに、2 台のホストだけではあまり効果はありませんが 、ホストがさらに数台増えるだけで、すぐに大きな違いが生まれます。 ルールベースの構成の利点は明らかです。

つまり、作業量が減り、品質が向上します。 そのため、Checkmk には、閾値、監視設定、責任、通知、エージェント設定など、ホストやサービスをカスタマイズするための豊富なルールが用意されています。

セットアップ内で、Checkmk はルールをルールセットに整理します。 各ルールセットは、ホストまたはサービスに関する特定のパラメータを定義する役割があります。 Checkmk には 700 以上のルールセットが含まれています。 以下に、その例をいくつか挙げます。

各ルールセットは、ホストまたはサービスのいずれかを担当し、両方を担当することはありません。 ホストとサービスの両方にパラメータを定義できる場合、適用可能なルールが 2 つあります。たとえば、Normal check interval for host checks とNormal check interval for services checks です。

厳密に言えば、いくつかのルールセットは実際にはパラメータを定義するのではなく、サービスを作成します。 その例としては、Setup > Services > HTTP, TCP, Email, …​ にありますアクティブチェックのルールがあります。 これを使用すると、たとえば、特定のホストに対して HTTP チェックを設定することができます。 これらのルールは、ホストにそのようなチェックが存在する場合、そのホストのプロパティとみなされるため、ホストルールに分類されます。

さらに、サービスディスカバリーを制御するルールセットもあります。 これらを使用すると、たとえば、Windows service discovery で、システム上で検出された Windows サービスについて、自動チェックを作成すべきかどうかを定義することができます。 これらはホストルールでもあります。 これらのルールセットの大部分は、特定のチェックプラグインのパラメータを決定します。

ルールセットの大部分は、特定のチェックプラグインのパラメータを決定します。 その例として、Network interfaces and switch ports があります。 これらのルールの設定は、対応するプラグインに非常に具体的に合わせています。 このようなルールセットは、基本的に、このプラグインに基づくサービスでのみ使用されます。 どのルールセットがどのサービスに対応しているかわからない場合は 、サービスから直接、関連するルールに移動して確認することをお勧めします。 その方法については、後で説明します。

これまで触れていなかった点があります。 上記の例には、すべてのテストシステムに対するルールがあります。 ホストがテストシステムであることを実際に定義しているのはどこでしょうか？

Checkmk では、テストシステムのようなものは ホストタグとして知られています。 使用可能なタグは、Setup > Hosts > Tags で確認できます。 一部のタグは、Criticality グループで定義されているTest system など、あらかじめ定義されています。

ホストにタグを適用するには、ホストのプロパティで明示的に設定するか、フォルダ階層で継承します。 その方法については、ホストに関する記事で説明しています。 独自のタグを作成する方法、および定義済みのタグについては、ホストタグに関する記事で説明しています。

1 つ以上のホストのパラメータを定義する新しいルールを作成する場合は、 いくつかの方法があります。 直接的な方法は、[setup ] メニューの対応するグループ、 この場合は [Setup > Hosts > Host monitoring rules] を使用することです。

次のビューには、ホストの監視に関連するすべてのルールセットが表示されます。 これらのルールセットの名前の後に表示されている数字は、すでに定義されているルールの数を示しています。

ただし、検索フィールドを使用すると、より早く目的の結果に到達できます。 もちろん、そのためには、ルールセットの名称を大まかに把握している必要があります。 ここでは、host checks を検索した結果を例として示します。

別の方法としては、セットアップの既存のホストのプロパティにある「Hosts > Effective parameters 」メニュー項目 またはフォルダのホストリストにあるアイコンを使用します。

ここでは、そのホストに影響するすべてのルールセットだけでなく そのホストに対して現在有効なパラメータも確認できます。Host check command の例では、表示されているホストにはルールが適用されていません。 そのため、商業版のデフォルト値であるSmart PING (only with Checkmk Micro Core) に設定されています。 Checkmk Raw では、デフォルト値はPING (active check with ICMP echo request) です。

Host check command をクリックすると、ルールセット全体が表示されます。

ルールがすでに存在する場合、Default value の代わりに、このパラメータを定義するルールの番号が表示されます。

これをクリックすると、そのルールに直接移動します。

サービス用のルールセットへのパスも同様です。 一般的なアクセス方法は、Setup メニューから この場合はSetup > Services > Service monitoring rulesまたは、より適切な検索フィールドから行います。

ルールセットの名前についてまだあまり経験がない場合は、サービス経由のパスの方が簡単です。 ホストと同様に、サービスのすべてのパラメータが表示されるページもあり 、該当するルールセットに直接アクセスすることができます。 このパラメータページには、セットアップのホストのサービスリストにある アイコンからアクセスできます。 アイコンをクリックすると、このサービスのチェックプラグインのパラメータを定義するルールセットに直接移動します。

ちなみに、パラメータページのアイコンは、各サービスのアクションメニューの監視にもあります。

Setup メニューには、Enforced Services という項目もあります。 その名前が示すとおり、このルールセットを使用すると、ホストにサービスを強制的に作成することができます。 詳細については、サービスに関する記事をご覧ください。Simple checks for BIOS/Hardware errorsなど、ごく一部のルールセットは、強制サービスにのみ表示されます。 これらは、サービスディスカバリーによって検出されたサービスではなく、手動で作成されたサービスです。

前述のルールセットのリスト（Host monitoring rules またはService monitoring rules）では、メニューバーのRelated > Used rulesets を使用して、少なくとも 1 つのルールを定義したルールセットのみを表示することができます。 これは、既存のルールを調整する場合に、作業を開始するのに便利な方法です。 ちなみに、一部のルールは、Checkmk サイトを作成する際にデフォルトで生成され、サンプル設定の一部となっています。 これらのルールもここに表示されます。

監視は複雑な作業です。 ルールが 1 つのホストまたはサービスにも一致しない場合があります。これは、ミスによるもの、または一致するホストおよびサービスが消滅したためです。 このような無効なルールは、メニューバーの「Related > Ineffective rulesets 」から前述のルールセットのリストで確認できます。

Checkmk は常に開発が進められています。 時折、標準化が行われ、一部のルールセットが他のルールセットに置き換えられる場合があります。 そのようなルールセットを使用している場合は、ルール検索を行うのが最も簡単な方法です。Setup > General > Rule search からルール検索を開きます。 次に、メニューバーの「Rules > Refine search 」をクリックし 、「Deprecated」のオプションとして「Search for deprecated rulesets 」を選択し 、「Used 」のオプションとして「Search for rule sets that have rules configured 」を選択します。 さらに「Search 」をクリックすると、目的の概要が表示されます。

Setup でホストまたはサービスのルールセットにアクセスすると、Checkmk はこのルールセットを分析モードで表示します。 このモードに移動するには、ホストまたはサービスリストのSetup にある アクションメニューの アイコンをクリックします。 次のEffective parameters of ページには、ホスト/サービスに適用されるルールのリストが表示されます。 分析モードに移動するには、少なくとも 1 つのルールが存在するルールセット、つまりDefault value に設定されていないセットの名前をクリックします。

このモードには 2 つの機能があります。 まず、ルールを設定するための 2 つ目のボタン — 「Add rule for current host 」または「 」 — が表示されます。Add rule for current host and service.

これにより、現在のホストまたはサービスがすでに選択されている新しいルールを作成することができます。 この方法では、例外ルールを非常に簡単かつ直接作成することができます。 次に、各行に「信号機」アイコンが表示され、その色によって このルールが現在のホスト、またはサービスに影響を与えるかどうか、あるいはその影響の程度が示されます。 以下の条件があります。

最後の条件（ルールが部分一致）は、ルールセット で、個々のチェックボックスを選択して 1 つのルールで複数のパラメータを定義できる場合にのみ発生します。 理論的には、別のルールのすべてのパラメータもここで個別に設定できます。 これについては後で詳しく説明します。

最初のブロック「Rule Properties 」の内容はすべてオプションであり、主にドキュメント用です：

2 番目のセクションはルールごとに異なりますが、常に実行すべき内容を指定します。 次の図は、よく使用されるタイプのルール (DB2 Tablespaces) を示しています。 チェックボックスを使用して、ルールで定義する個々のパラメータを指定できます。 前述のように、Checkmk は、個々のパラメータを定義するルールを個別に決定します。 したがって、この図のルールは 1 つの値のみを定義し、その他の設定は変更しません。

このルールおよび他のルールの値は、時間/カレンダーベースで制御することもできます。 たとえば、営業時間と週末でテーブルスペースの使用状況の閾値を設定することができます。

まず、[Enable timespecific parameters ] ボタンをクリックし、次に [Add new element] をクリックすると、時間依存のオプションが表示されます。

次に、[Match only during time period ] リストで期間を選択し、この期間を適用するパラメータを選択します。

一部のルールセットでは、パラメータを設定せず、対象となるホストと対象とならないホストを決定するだけです。 その例として、ルールセット「Hosts to be monitored 」があります。このパラメータの範囲は、次のとおりです。

2 つの利用可能な値のいずれかを選択して、影響を受けるホストの処理方法を決定します。Positive match (Add matching hosts to the set) を選択すると、影響を受けるホストが監視対象のホストのセットに追加されます。Negative match (Exclude matching hosts from the set) を選択すると、影響を受けるホストが監視対象から削除されます。Positive match またはNegative match は、現在のルールの内容を指します。 これは、ホストを選択するための追加のフィルタ条件ではありません。 影響を受けるホストのセットは、以下のConditions を使用してのみフィルタリングします。

前のセクションでは、ルールが影響するすべてのホストまたはサービスをどのように処理するかを定義しました。 3 番目のセクション「Conditions 」では、ルールによって処理されるホストまたはサービス、つまりルールの効果を定義します。 ルールが有効になるには、さまざまな種類の条件がすべて満たされている必要があります。 したがって、条件は論理的に AND で連結されています。

ルールの概念の紹介で、最初に適用されるルールが常に最終的な結果を決定することを説明しました。 しかし、これは完全な真実ではありません。 評価には、合計 3 種類のタイプがあります。

ルールの評価方法に関する情報は、メニューバーの直下にある各ルールセットに表示されます。

では、複数のホストに適用する複数のルールを作成した場合、具体的にどのように評価されるのでしょうか？ これを説明するために、簡単な例を見てみましょう。

3 つのホストがあり、それぞれ（および将来追加されるすべてのホスト）に対して、Periodic notifications during host problems ルールを使用して、周期的に繰り返される異なる通知を設定したいとします。

この設定を有効にすると、Checkmk はルールチェーンを上から下へ順番に実行します。 その結果、次のように評価されます。

ここで注意してください。 このルールセットには「最初に一致したルールがパラメータを定義する」が適用されるため、ルールチェーンの処理は、最初の一致後に常に終了します。 したがって、結果にはルールの順序が重要です。 これは、ルールの順序を変更してルール B と C を入れ替えた場合に明らかになります。

ここで、個々のホストについてルールチェーンを最初から最後まで再度実行すると、結果も変わります。 ルール C は、ホスト 3 だけでなくホスト 2 にも適用されるため、両方のホストに対して 30 分ごとに通知が行われます。 これで、両方のホストの処理が完了します。 ルール B はホスト 2 に関連し、このホストのために記述されていましたが、評価および適用はされなくなりました。 分析モードでは、このプロセスは次のようになります。

この記事で説明したさまざまな設定を、正しい処理順序に注意しながら組み合わせることで、ホスト複合体全体に対する複雑なルールチェーンを構築することができます。