ラベル

ラベルは、さまざまな方法でホストに割り当てることができます。

最初の方法は簡単です。 セットアップで ホストを作成または編集するときに表示されるホストのプロパティページで ホストに任意のラベルをいくつでも付けることができます。

Labels をチェックボックスで有効にして、Add some label フィールドをクリックし、key:value の形式に従ってラベルの定義を入力し、Enter キーで終了します。

既存のラベルは、そのテキストをクリックして編集したり、小さな「x」で削除したりすることができます。

もちろん、ラベルはフォルダから継承することもできます。 他の属性と同様に、ラベルはサブフォルダまたはホストに設定でき、必要に応じて個別に上書きすることができます。 たとえば、フォルダに「location:munich 」というラベルが設定されている場合、このフォルダ内の「location 」というラベルがまだ定義されていないすべてのホストに、このラベルが継承されます。 ホストに他のラベルが設定されている場合は、そのラベルは影響を受けません。

ホストまたはフォルダに明示的に定義されたラベルは、ホストのリストで紫色で表示されます。

Checkmk では通常どおり、ルールによってホストおよびサービスに属性を割り当てることもできます。 これにより、フォルダ構造に依存しなくなるほか、ラベルにも適用されます。 この機能には、Host labels ルールセットが用意されており、セットアップメニューで検索してすばやく見つけることができます。

次のルールは、Bavaria フォルダ内の、ホストタグが「Real Hardware 」のすべてのホストに「hw:real 」ラベルを追加します。

このルールの条件ではラベルを使用できないことに気付いたかもしれません。 これは間違いではなく、再帰的な依存関係やその他の異常を回避するための意図的なものです。

ルールによって追加されたラベルは、表示されているホストには赤色で表示されますが、セットアップのホストリストには表示されません。 代わりに、ホストのステータスビューにのみ表示されます。

ラベルを作成する 3 つめの方法は、完全に自動です。 クラウドおよびコンテナシステムを監視するための特別なエージェントなど、さまざまなデータソースが自動的にラベルを生成します。 ここでは、特に AWS、Azure、および Kubernetes 用の特別なエージェントについてご説明します。 これらは、それぞれのプラットフォームではタグと呼ばれることもあり、Checkmk ではホストラベルまたはサービスラベルとして作成されます。 それぞれのルールセットには、この点に関する十分な情報が記載されています。

この方法の良い点は、何も設定する必要がないことです。 これらのデータソースがアクティブになると、対応するラベルが自動的に生成されます。

自動的に生成されるホストラベルセクションには、Checkmk が自動的に生成するラベルの概要が表示されます。

ラベルを直接操作する簡単な方法は、エージェントプラグインを追加することです。これにより、ローカルチェックと同様に、 labels というセクションが作成されます。 この方法では、HW/SW インベントリだけを評価する場合よりも、より詳細にラベルを割り当てることができます。たとえば、インストールされているハードウェアの微妙な違い（CPU 機能など）や、実際に実行されているプロセス（単にインストールされているソフトウェアではなく）に関連してラベルを割り当てることができます。

ラベルの出力は、次の例のように Python 辞書としてフォーマットする必要があります。

評価の順序は保証されないため、Checkmk 自体や他のプラグインによって自動的に割り当てられるラベルとの衝突は避けてください。

ディスカバリーチェックを有効にしている場合（新規インストールではデフォルト設定です）、セットアップのホストプロパティにまだ追加されていない新しいホストラベルが見つかった場合に警告が表示されます。 たとえば、次のような警告が表示されます。

この警告には 2 つの対応方法があります。 1 つ目は、セットアップでホストのサービス設定を呼び出し、[Hosts > Update host labels ] メニュー項目でラベルの設定を更新して、新しいラベルを追加する方法です。 この場合、変更をアクティブにしなくても、次回ディスカバリーチェックが実行されると（最大 2 時間遅れて）、ディスカバリーチェックは再び「OK 」になります。 それほど長く待ちたくない場合は、サービスのアクションメニューで [Reschedule check ] を選択して、サービスをすぐに手動で更新することもできます。

この変更が一度に多くのホストに影響する場合、各ホストのサービス設定を個別に確認するのは大変です。 この場合は、Run bulk service discovery のバルクアクションを実行し、モードとしてOnly discover new host labels を選択します。新しいサービスも追加したい場合は、Add unmonitored services and new host labels を選択してください。

ディスカバリーチェックを緑色にする 2 つめの方法は、新しいラベルについて警告が表示されないように再設定することです。 これを行うには、Periodic service discovery ルールセットに移動し、既存のルールを編集します。そこで、Severity of new host labels オプションが見つかります。

これは、デフォルトでは「Warning 」に設定されています。 「OK - do not alert, just display 」を選択すると、チェックは表示されなくなります。

ディスカバリーチェックによって検出されたラベルは、黄土色で表示されます。

理論的には、同じラベルが複数のソースで同時に異なる値で定義される場合があります。 そのため、以下の優先順位が設定されています。

この優先順位ルールにより、ラベルを完全に制御することができます。

ラベルの重要な機能は、ホスト機能と同じです。 つまり、ルール内の条件として使用することです。 これは、AWS、Azure、Kubernetes などの情報に基づいて監視を完全に自動化できるため、自動生成されたラベルに特に役立ちます。

ホストまたはサービスラベルに条件を追加するには、Add to condition （条件を追加）をクリックします。 次に、is （条件が真の場合）またはnot （条件が偽の場合）を選択して、肯定または否定の条件を設定し、通常のフォームkey:value （ラベル）にラベルを入力します。 大文字小文字を含むスペルに注意してください。 ラベルは指定なしで定義できるため、Checkmk はタイプミスを認識できません。 ただし、ラベルを入力すると、Checkmk は、入力内容と一致する既存のラベルを候補として表示します。 提案では、ホストラベルとサービスラベルは区別されません。一致するすべてのラベルが提案されます。 スペルミス、大文字小文字の誤りなど、正しいスペルに注意してください。

ただし、条件の定義はさらに一歩進んでいます。 条件をさらに絞り込むために、ブール演算子Not 、And 、Or も使用できます。 ここで、Not は、And Not の略語です。

たとえば、ラベルcmk/site:today があり、ラベルcmk/piggyback_source_today:yes がないホストを検索するには、条件は次のようになります。

この条件は、is またはnot とその他の仕様でさらに絞り込むことができます。 または、Add to condition を使用して新しい条件のグループを追加することができます。これにより、より複雑になった条件が読みやすくなりますが、ブール代数の評価は変わりません。

ルールでは、ラベルとホストタグの両方を使用できます。 これらは自動的に AND リンクされます。 したがって、ルールは、両方の条件が同時に満たされた場合にのみ適用されます。

ラベルは、通知ルールの条件としても使用できます。 使用方法は他の条件と同じであるため、使用方法を新たに習得する必要はありません。Match host labels （条件）を選択し、ホストまたはサービスが持つべきラベルを入力するだけで、このルールによって通知がトリガーされます。 ここでも、複数のラベルは AND 演算で連結されます。