サービスの理解と設定

セットアップに新しいホストを追加したら、次のステップはサービスのリストを呼び出すことです。 この操作により、このホストに対して初めて自動サービスディスカバリーが行われ、データソースのアクセス可能性が同時にチェックされます。 このリストは、ディスカバリーを再開したり、設定を変更したりするために、後でいつでも呼び出すことができます。 サービスリストを開くには、さまざまな方法があります。

ホストが新しく組み込まれた場合、そのサービスはまだ設定されていないため、検出されたすべてのサービスが「Undecided services - currently not monitored 」カテゴリに表示されます。

新しく発見されたサービスを追加する通常の方法は、単に「Accept all 」ボタンをクリックすることです。 そうすることで、すべてのホストラベルも一度に追加されます。 その後、すぐに「Activate changes」をクリックすると、そのホストが監視対象になります。

すでに監視されているホストの場合、このリストは異なります。Undecided services - currently not monitored の代わりに、Monitored services が表示されます。 Checkmk が、監視されていないが監視すべきホストで何かを検出した場合、リストは次のようになります。

Monitor undecided services またはAccept all をクリックすると、不足しているサービスがすべて追加され、監視が再び完全になります。 不足しているサービスの一部のみを追加したい場合は、代わりに ボタンをクリックして、Move to monitored services を選択してください。

データセンターでは、新しいものが追加されるだけでなく、消えることもあります。 データベースインスタンスが廃止されたり、LUN がアンマウントされたり、ファイルシステムが削除されたりする場合があります。 Checkmk は、このようなサービスを自動的に消失したサービスとして認識します。サービスリストでは、次のように表示されます。

これらのサービスを削除する最も簡単な方法は、再び「Accept all 」をクリックするか、各行の「Remove vanished services 」ボタンをクリックすることです。 注意：サービスが消えた理由は、もちろん問題によるものかもしれません。 ファイルシステムが消えた場合は、エラーのためにマウントできなかった可能性もあります。 監視は、このような場合に備えてあるのです。 そのサービスがもはや監視する必要がないことが確実になった場合にのみ、そのサービスを削除してください。 2.4. 不要なサービスの削除

Checkmk が検出したすべてを監視したいとは限りません。 ディスカバリーは、もちろんターゲット指向で機能し、 事前に多くの不要なデータを除外することができます。しかし、たとえば、特定のデータベースインスタンスが「試しに」設定されたもので、 本番環境では使用されていないことを Checkmk はどのようにして知ることができるのでしょうか？ このようなサービスを排除するには、2 つの方法があります。

ディスカバリー中にさまざまなことを通知するプラグインがいくつかあります。 たとえば、ネットワークインターフェイス用のプラグインは、ディスカバリー中にインターフェイスに設定されている速度をチェックします。 なぜでしょうか？変更があった場合に警告を表示するためです。 インターフェイスが 10 Mbit/s に設定されていることもあれば 1 Gbit/s に設定されていることもある場合、これは良い兆候とは言い難いでしょう。 これは、オートネゴシエーションに問題があることを示している可能性があります。 この変更が望ましく、今後 OK として受け入れる場合はどうすればよいでしょうか？

この変更が望ましく、今後 OK として受け入れる場合はどうすればよいでしょうか？ アイコン（Move to undecided services ）でサービスを削除し、 その後すぐに再追加してください。 または、メニューバーのActions > Remove all and find new をクリックして、ホストのすべてのサービスを更新してください。 これは当然、はるかに簡単な方法ですが、個々のサービスをエラー状態にしておきたくない場合に限ります。

ラベルのみを更新するには、メニューバーの [Actions > Host labels > Update host labels ] および [Actions > Services > Update service labels ] をそれぞれ選択します。 個々の (新しい) サービスラベルを追加または更新する必要がある場合は、[Changed services ] ボックスのそれぞれのサービスの行で をクリックして実行できます。

SNMP によって監視されるデバイスには、いくつかの特別な機能があります。 これらの機能については、SNMP に関する記事をご覧ください。

Checkmk が、ホスト上で見つかったすべてのプロセスを監視するサービスを単に定義してもあまり意味がありません。 ほとんどのプロセスは、関心のないものか、一時的にしか存在しないものです。 少なくとも、一般的な Linux サーバーでは、何百ものプロセスが実行されています。 そのため、サービス監視には、実行中のプロセスをフィルタリングするルールが必要です。

したがって、サービスを監視するには、強制サービスを使用するか、 より洗練された方法として、ルールセット「Process discovery 」を使用して サービスディスカバリーに監視すべきプロセスを指示する必要があります。 この方法では、ホスト上で確実に興味深いプロセスが見つかった場合に、 常に自動的に監視を開始することができます。 次の図は、 ルールセットにあるルールを示しています。

次の図は、Process discovery ルールセットのルールで、 プログラム/usr/sbin/apache2 を実行するプロセスを検索するものです。 この例では、そのようなプロセスが見つかったすべてのオペレーティングシステムユーザーに対して、 サービス (Grab user from found processes) が作成されます。 このサービスの名前はApache %u となり、%uはユーザー名に置き換えられます。閾値については、プロセスの インスタンス数をそれぞれ 1/1 (最小) および 30/60 (最大) に設定します。

事前定義された閾値はDefault parameters for detected services として参照されます。これらは、 他のすべてのサービスと同様に、ルールを使用して割り当てることができます。念のため、上記のルールは サービスディスカバリー（ 何 ）を設定するものです。サービスが 初めて存在する場合、ルールチェーンState and count of processes が 閾値を担当します。

ディスカバリー中に閾値を設定できることは、利便性を高める機能です。 ただし、ディスカバリールールを変更した場合、その変更は 次回のディスカバリーまで有効になりません。閾値を変更した場合は 、新しいディスカバリーを実行する必要があります。ただし、ルールを サービスのディスカバリー（何）にのみ使用し、ルールセットState and count of processes をどのように使用するか（方法）に指定している場合は、この問題はありません。

Windows ホスト上の特定または単一のプロセスを監視するには、フィールドExecutable に、パスを指定せずにファイル名 (拡張子を含む) を指定するだけです。 これらの名前は、たとえば Windows の [タスク マネージャー] の [詳細] タブで確認できます。 ルールProcess discovery では、プロセスsvchost の場合、次のように指定します。

プロセスディスカバリーに関する詳細情報は、このルールセットのインラインヘルプでご覧いただけます。このヘルプは、メニューバーの「Help > Show inline help 」からいつでも表示できます。

Windows サービスのディスカバリーと監視のパラメータ設定は プロセスと同様で、ルールセットWindows service discovery (何) およびWindows services (どのように) によって制御されます。ここでは、2 つのサービスを監視するルールの例を示します。

プロセスとまったく同じように、ここでもサービスディスカバリーは 1 つのオプションにすぎません。ホストの特性とフォルダに基づいて 特定のサービスが予想されるホストについて正確なルールを策定できる 場合は、強制サービスも使用できます。 これは、実際に発見された状況とは無関係ですが、 この状況では、どのホストでどのサービスが実行されるかを正確に記述するために 多くのルールが必要になるため、 かなり手間がかかる場合があります。

Checkmk は、サーバーのネットワークインターフェイスとイーサネットスイッチのポートの監視に同じロジックを使用します。 スイッチポートでは、サービスディスカバリーを制御するための既存のオプションが 特に興味深いですが、 （プロセスや Windows サービスとは対照的に）ディスカバリーは、最初は ルールなしで機能します。つまり、デフォルトでは、Checkmk は 現在 UP 状態のすべての物理ポートを自動的に監視します。適用される ルールセットはNetwork interface and switch port discovery と呼ばれ、 ここでは簡単に説明する、数多くの設定オプションを提供しています。

以下のオプションが最も重要です：

しかし、このためには、新しいサイトで自動的に設定される定期的なディスカバリーチェックの方がはるかに優れています。 このサービスCheck_MK Discovery はすべてのホストに存在し、監視されていない項目を見つけると警告をログに記録します。

監視対象外のサービスまたは消滅したサービスの詳細は、[Details ] フィールドの [Check_MK Discovery ] サービス詳細ページで確認できます。

セットアップのホストのサービスリストには、Check_MK Discovery サービスのアクションメニュー およびRun service discovery エントリから簡単にアクセスできます。

ディスカバリーチェックのパラメータ設定は、Periodic service discovery ルールセットを使用して非常に簡単に行えます。 すぐに使えるサイトには、すべてのホストに適用されるように定義済みのルールが 1 つあります。

チェックを実行する間隔とともに、監視されていないサービス、消滅したサービス、変更されたサービスラベル、および新しいホストラベルの場合の監視状態を設定できます。 7.2. サービスの自動追加

ディスカバリーチェックで、不足しているサービスを自動的に追加することができます。 このためには、Automatically update service configuration オプションを有効にしてください。これにより、さらにオプションが利用可能になります。

追加に加えて、[Parameters ] では、消滅したサービスを削除したり、既存のサービスをすべて削除して完全に新しいディスカバリーを実行したりすることもできます。 後者のオプションは、[Refresh all services and host labels (tabula rasa)] という名前でドロップダウンメニューにあります。 これらのオプションは慎重に使用してください。 消滅したサービスは、問題の存在を示している可能性があります。 ディスカバリーチェックでは、そのようなサービスは単に削除され、すべてが正常であるとの誤った認識に陥ります。 更新は特に危険です。 たとえば、スイッチポートのチェックではUP のポートのみが監視対象となります。DOWN のステータスのポートは、ディスカバリーチェックでは消失したと認識され、すぐに削除されます。

さらに、別の問題も考慮する必要があります。サービスを追加したり、 自動Activate Changes を実行したりすると、設定作業中の管理者（あなた）の注意がそらされてしまいます。 理論的には、ルールや設定の作業中に、その瞬間にディスカバリーチェックが実行され、 変更がアクティブになる可能性があります。 Checkmk では、すべての変更を一度にアクティブにすることができます。Checkmk では、すべての変更は一度にのみアクティブにすることができます。このような 状況を回避するために、この機能の時間を、たとえば夜間に再スケジュールすることができます。 上の画像は、その例を示しています。xml-ph-0000@deepl.internal では、クラスタ化されたサービスを個別に処理することができます。

Vanished clustered services （サービスチェックのスケジュール）では、クラスタ化されたサービスを個別にハンドルすることができます。 この機能の特別な点：クラスタ化されたサービスが 1 つのノードから別のノードに移動した場合、そのサービスは一時的に消失したとみなされ、意図せずに削除される可能性があります。 このオプションを無効にすると、実際に消失したサービスは削除されなくなります。

Group discovery and activation for up to （ディスカバリーチェックの待機時間）の設定により、 新しく発見されたすべてのサービスがすぐにActivate Changes（ディスカバリーチェック）をトリガーするのではなく、指定した待機時間があり、 複数の変更を 1 つのアクションでアクティブにすることができます。ディスカバリー チェックが 2 時間以上の間隔に設定されている場合でも、これは各ホストに個別に適用されます。 チェックは、すべてのホストで同時に実行されるわけではありません。 これは、ディスカバリーチェックは通常のチェックよりもはるかに多くのリソースを必要とするため 、望ましいことです。

要約 – すべてのオプションを一目で確認:

サービスディスカバリーの結果、つまり前述のように、ホスト名、チェックプラグイン、項目、および識別されたパラメータのテーブルは、var/check_mk/autochecks フォルダに保存されます。 ここでは、各ホストごとに、自動的にディスカバリーされたサービスを保存するデータセットがあります。 このデータセットの Python ファイルは、ホスト名と同じ名前です。 このデータセットの Python 構文を損なわない限り、 個々の行を手動で変更または削除することができます。データセットを削除すると、すべてのサービスが削除され 、再び「監視対象外」としてフラグが付けられます。

これまで、サービスを監視に含める方法を学びました。 しかし、何千ものサービスのリストを見たり、常に ホストビューを調べたりしなければならないのはあまり意味がありません。たとえば、すべてのファイルシステムまたは 更新サービスをまとめて表示したい場合は、ホストグループと同じような方法でグループを簡単に作成することができます。

サービスグループを使用すると、ビューやNagVis マップを使用して監視をより整理し、 ターゲットを絞った通知や アラートハンドラーを簡単に切り替えることができます。

ちなみに、ビューフィルターだけを使用して、ほぼすべての対応するビューを構築することができますが 、サービスグループの方がより明確に整理されており 、操作も簡単です。

サービスグループは、Setup > Services > Service groups から確認できます。

サービスグループの作成は簡単です。Add group でグループを作成し、後で変更できない名前と、意味のあるエイリアスを割り当てます。

サービスグループにサービスを割り当てるには、ルールセット Assignment of services to service groups が必要です。 そこへ最も早く移動するには、サービスグループの概要 (Setup > Services > Service Groups) を使用します。 ここでは、メニューバーのService Groups > Assign to group > Rules をクリックするだけです。 もちろん、[Setup ] メニューのルール検索からルールを見つけることも、Setup > Services > Service monitoring rules > Various > Assignment of services to service groups を詳しく調べることもできます。 次に、[Create rule in folder ] を使用して、その作業を行います。まず、サービスを割り当てるサービスグループを指定します。たとえば、myservicegroupまたはそのエイリアスMy service group 1 などです。

Conditions セクションで、いよいよエキサイティングな部分が始まります。 まず、フォルダ、ホストタグ、および明示的なホスト名を使用して、サービス以外の制限を設定できます。 次に、グループ化したいサービスに名前を付けます。たとえば、Filesystem およびmyservice と指定して、ファイルシステムのセットを作成します。 サービスの指定は、正規表現のフォームで行います。これにより、グループを正確に定義できます。

特定のサービスの詳細ページで、サービスの割り当てを確認できます。 以下は、デフォルトの「Service groups the service is member of 」行です。

前述のように、サービスグループは、ビュー、NagVis マップ、通知、アラートハンドラーなど、いくつかの場所で使用されます。 詳細ページでは、デフォルトで「Service groups 」��が表示されます。10.5. サービスグループの使用 新しいビューでは、データソースとして「 」を使用することが重要です。 もちろん、Views ウィジェットには、サービスグループ用の定義済みビューも含まれています。 たとえば、わかりやすい要約があります。 サービスグループ名をクリックすると、そのグループに属するすべてのサービスの完全なビューが表示されます。

サービスグループ名をクリックすると、そのグループに属するすべての サービスの完全なビューが表示されます。

NagVis マップでサービスグループを使用すると、単一のアイコンにカーソルを置くと、 メニューに開いているサービスグループの概要が表示されます。

サービスグループを 通知および アラートハンドラー 通知 で使用すると、条件/フィルタとして使用でき、その中から 1 つ以上を選択して使用することができます。

Checkmk でサービスを生成するには、チェックプラグインが必要です。 各サービスは、チェックプラグインを使用して、そのステータスを判断したり、メトリックを作成/維持したりします。 その際、プラグインはホストごとに 1 つ以上のサービスを作成することができます。 同じプラグインの複数のサービスを区別するために、項目が必要です。 たとえば、サービス「Filesystem /var 」の場合、項目は「/var 」というテキストになります。 ホストごとに 1 つのサービスしか生成できないプラグイン（CPU utilization ）など）の場合、項目は空で表示されません。

使用可能なすべてのチェックプラグインのリストは、Setup > Services > Catalog of check plugins にあります。ここでは、個々のプラグインを 検索し、さまざまなカテゴリでフィルタリングすることができます。

各プラグインには、3 つの情報列が表示されます。 サービスの説明 (チェックの種類)、チェックプラグインの名前 (プラグイン名)、および 互換性のあるデータソース (エージェント) です。