Checkmk
to checkmk.com
Important

This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved.

1. 概要

Checkmk では、さまざまな方法でインフラストラクチャを監視することができます。 エージェントや SNMPによる監視は、その方法の一部にすぎません。 エージェントによる監視は、その方法の一部にすぎません。 すべてのエージェントベースの方法に共通しているのは、ホストが内部から認識した状態のみをレポートする点です。 しかし、外部からのみ効果的に監視できるサービスもいくつかあることはご存じでしょう。 web サーバーが機能しているかどうかは、内部から確認することはできますが、 実際のユーザーのアクセス可能性や応答時間は、この方法では判断できません。

Checkmk は、このような状況に対応するためにアクティブチェックを提供しています。 このチェックを使用すると、ネットワークサービスを外部から直接、かつ便利に監視し、その情報を監視に表示することができます。 アクティブチェックは、ネットワークまたはインターネット上のサービスに接続し、ユーザーに監視データを提供する小さなプログラムまたはスクリプトです。 Checkmk に含まれるスクリプトやプログラムの多くは、monitoring-plugins.org が開発したものです。 Checkmk は一般的に Nagios と互換性があるため、Nagios で動作するすべてのプラグインも使用できます。

このようなプラグインを統合する場合は、アクティブチェックの主な目的、つまりエンドツーエンド監視の観点から、監視対象のホスト上のネットワークアクセス可能なサービスのアクセス可能性、応答時間、または応答ステータスをチェックすることであることを念頭に置いてください。 Checkmk は、他の多くの監視タスクのための効率的なチェックを幅広く提供しています。 概要については、「Checkmk の拡張機能の開発」の記事をご覧ください。

これらのプログラムおよびスクリプトのうち、最も重要なものは、Checkmk の web インターフェイスから直接利用できます。 その一部を以下に示します。

2. アクティブチェックの設定

2.1. 定期的なアクティブチェックの設定

Setup では、前述のように、最も重要で頻繁に使用するチェックを web インターフェイスで直接設定することができます。 これを行うには、Setup > Services > HTTP, TCP, Email を開きます。 ここでは、これらのチェックを設定するためのルールセットを見つけることができます。

List of rulesets for active checks.

ルールセットのほとんどのオプションは、その名前で意味がわかります。 ただし、不明な点がある場合は、インラインヘルプで多くのオプションの説明を確認することもできます。

2.2. アクティブチェックをホストに割り当てる

一部のルールでは、オプションで IP アドレスまたはホスト名を指定する必要があります。 多くの場合、このオプションは空白のままにしておくと、ホスト名またはその IP が使用されます。 これにより、1 つのルールだけで、ホストのグループ全体にアクティブチェックを簡単に実行することができます。 そのため、前述のインラインヘルプも参照しながら、このオプションが特定のルールセットで使用可能かどうかを必ず確認してください。 これにより、設定作業を大幅に削減できます。

Check HTTP web service は、証明書の有効性、応答時間、応答コード、配信された Web ページ内の文字列の検索など、Web サーバーの多くのパラメータを監視するためによく使用されるチェックです。 このチェックは、 にあります。 インフラストラクチャ内のすべての Web サーバーの証明書の有効性を監視し、応答時間を 1 秒未満、ステータスコードを 200 に保つことを確保したいが、そのために数十、あるいは数百ものルールを作成したくない場合を考えてみましょう。Networking > Check HTTP web service

Example of a configuration of the 'Check HTTP web service' rule.
Tip

Check certificates には、証明書に関する別のアクティブチェックがあるのはなぜですか?

前述のCheck HTTP web service チェックは、常に1 つの完全なHTTP リクエストを実行するため、その使用は web サーバーに限定されます。 一方、その実行は非常に効率的で、1 つの HTTP リクエストで一連のチェックを実行できます。

一方、Check certificates は、TLS 接続のセットアップと証明書のみをチェックします。 したがって、このチェックは、IMAP/S など、TLS でセキュリティ保護されている他のサービスにも適用できます。 また、サーバー名表示 (SNI) によって保存されている特定のホスト名など、証明書をより詳細に検査することもできます。

設定したチェックを 1 つのルールですべての適切なホストに適用するには、まず、Conditions をどのように入力するのが最適かを考えてください。 次の例では、ラベル機能を使用して、すべての web サーバーに「webprotocol:https 」ラベルを追加しています。 このラベルを使用すると、ルールを作成し、Conditions をこのラベルに設定することができます。

Restriction of the rule via a host label on the web server.

作成したルールを有効にした後、[Monitor] メニューで、先ほど定義したBasic webserver health のサービス名を検索します。 次の例では、ラベルが適切に適用されたホストを確認できます。

The services generated by the rule in the monitoring.

重要: アクティブチェックでは、条件に適用される最初のルールだけでなく、ホストの条件に適用されるすべてのルールが評価されます。 これは、ホストに複数のアクティブサービスを作成するための唯一の方法です。

2.3. 他の Nagios 互換プラグインの統合

もちろん、web インターフェイスでルールセットとして表示されるアクティブチェックだけが Checkmk で利用できるわけではありません。 これらのチェックプラグインに加えて、サイトにはさらに多くのプラグインがあります。 ここで示す概要の例を簡略化するため、以下のサンプル出力では、選択した行のみを表示しています。

OMD[mysite]:~$ ll ~/lib/nagios/plugins/
total 2466
-rwxr-xr-x 1 root root   56856 Feb  3 00:45 check_dig
-rwxr-xr-x 1 root root    6396 Feb  3 00:45 check_flexlm
-rwxr-xr-x 1 root root    6922 Feb  3 00:45 check_ircd
-rwxr-xr-x 1 root root   60984 Feb  3 00:45 check_ntp_peer
-rwxr-xr-x 1 root root   78136 Feb  3 00:45 check_snmp

これらのチェックプラグインにはそれぞれ、ヘルプオプション (-h) が用意されており、monitoring-plugins.org の web サイトにアクセスすることなく、それぞれのプラグインの使用方法について詳しく知ることができます。

Setup > Services > Other services では、これらのプラグインを便利に使用するための特別なルールセットIntegrate Nagios plugins が用意されています。 ここで最も重要な 2 つのオプションは、サービス内容の指定とコマンドラインの指定です。 後者は、すでに正しいディレクトリにいるかのように記述することができます。

Rule for the integration of Nagios plug-ins.

$HOSTNAME$$HOSTADDRESS$ などの上記のマクロもここで使用できることにご注意ください。 使用可能なマクロのリストは、いつものようにインラインヘルプで確認できます。 変更をアクティブにすると、割り当てられたホストに新しいサービスが表示されます。

The service generated by the rule in the monitoring.

独自のプラグインの使用

場合によっては、独自のプラグインをすでに作成しており、それを Checkmk で使用したいこともあるでしょう。 その場合の操作は、ほとんど同じです。 唯一の要件は、プラグインが Nagios と互換性があることです。 これには、ステータスの詳細を含む 1 行の出力と、ステータスを表す終了コードが含まれます。 これは、OK では0WARN では1CRIT では2UNKNOWN では3 である必要があります。

非常にシンプルな構文を説明する簡単な例として、サイトディレクトリの~/tmp サブディレクトリなどに作成できる以下のスクリプトがあります。

~/tmp/myscript.sh
#!/bin/bash
echo "I am a self written check and I feel well."
exit 0

1 つの操作で、プラグインをサイトのローカルファイルパスに配置し、実行可能にしてください。

OMD[mysite]:~$ install -m755 ~/tmp/myscript.sh ~/local/lib/nagios/plugins/

残りの手順は、Integrate Nagios plugins ルールセットを使用して作成される他のプラグインと同じであるため、最後に新しいサービスが表示されます。

The service generated by the custom plug-in in monitoring.

3. アクティブチェックの特別な機能

アクティブチェックによって作成されたサービスは、他のサービスとはいくつかの点で動作が異なります。 したがって、アクティブチェックのサービスは…​

  • …​ ホストがDOWN の場合でもチェックは継続されます。

  • …​ 他の(パッシブ)サービスとは独立して実行されます。 これにより、独自のインターバルを設定することもできます。

  • …​ 常に Checkmk サーバーによって実行されます。 例外はMRPE で、これはホスト上で直接実行されます。

  • …​サービスディスカバリーによって組み込まれるのではなく、自動的に生成されます。

4. ホストでのアクティブチェックの実行 (MRPE)

Checkmk サイトからホスト A(web サーバーなど)を監視しており、そのホスト A がホスト B(データベースなど)のサービスにアクセスしているとします。 Checkmk サイトからホスト B のサービスを直接監視すると、他のパケットの実行時間などの影響を受けて監視結果が乱れる可能性が高く、ホスト A からのアクセスが実際にどのように動作しているかを正確に把握することができません。 このような場合、監視対象のホスト(ここでは A)のエージェントから Nagios プラグインを実行し、ホスト B のサービスを直接チェックすると便利です。

監視対象のホストで従来の Nagios プラグインを実行するには、MK のリモートプラグインエクゼキュータ(略称: MRPE) を使用します。 このようなプラグインを Unix 系システムで実行するか、Windows システムで実行するかによって、それぞれのエージェントのインストールディレクトリ内の適切な場所にプラグインを配置してください。 さらに、プラグインの実行方法、および呼び出し用の具体的なコマンドラインを決定する設定ファイルも必要です。

詳細な手順については、LinuxおよびWindows に関する各記事をご覧ください。

5. ファイルとディレクトリ

ファイルパス 説明

~/lib/nagios/plugins/

ここでは、Checkmk に付属のすべてのプラグインを確認できます。 monitoring-plugins.orgによって作成されたプラグインと、Checkmk 用に特別に作成されたプラグインは区別されません。

~/local/lib/nagios/plugins/

ここに独自のプラグインを保存することができます。 これらのプラグインは動的に読み込まれ、Checkmk サイトの更新後も引き続き使用することができます。

このページでは