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 には、標準で多数のチェックプラグインが用意されているため、すでに多くの関連データを監視することができます。 しかし、IT 環境はそれぞれ独特であるため、非常に個別の要件が生じる場合が多くあります。 ローカルチェックを使用すると、ターゲットホスト上のエージェントに小さな拡張を行うだけで、独自のサービスを迅速かつ簡単に作成することができます。
これらのローカルプラグインは、他のチェックとは 1 つの重要な点で異なります。 その状態は、データが取得されるホスト上で直接決定されます。
これにより、Python を使用してチェックを作成する必要がなくなり、スクリプト言語を自由に選択することができます。 ローカルチェックは、サーバー管理者にも大きな自由度をもたらします。 監視管理者は、新しいローカルチェックをサービスとして含めるかどうかを決定するだけで済みます。
ローカルチェックが提供するメカニズムは、エージェントデータの転送のために Checkmk がサポートするすべての方法と組み合わせることができます。 データソースプログラム、スペシャルエージェント、 ピギーバックデータ、スプールファイルなどです。 すべてのソースからのデータはマージされますが、サービス名が(誤って)2 回割り当てられていると、競合が発生します。そのため、各サービス名は一意であることを確認してください。 |
2. 簡単なローカルチェックの記述
2.1. スクリプトの作成
ローカルチェックは、ターゲットホストがサポートする任意のプログラミング言語で記述できます。 スクリプトは、各チェックが 4 つの部分で構成される状態行を生成するように作成する必要があります。 以下に例を示します。
0 "My service" myvalue=73 My output text which may contain spaces4つの部分は空白で区切られ、以下の意味を持ちます:
| 例値 | 意味 | 説明 |
|---|---|---|
|
状態 |
サービスの状態は、数字で指定されます。OK は「 |
|
サービス名 |
Checkmk に表示されるサービス名、チェックの出力で二重引用符で囲んだもの。 |
|
値およびメトリック |
データのメトリック値。 構成の詳細については、メトリックの章をご覧ください。 チェックでメトリックが生成されない場合は、マイナス記号をコード化することもできます。 |
|
状態の詳細 |
Checkmk の「Summary 」フィールドに表示される、状態の詳細です。 この部分には空白を含めることもできます。 |
この出力の 4 つの部分の間には、必ず正確に 1 つのスペース(ASCII0x20 )を挿入する必要があります。
状態の詳細内では、スペースを任意の順序で使用できます。
上記の仕様からの逸脱は機能する場合もありますが、必ずしも機能するとは限りません。 Checkmk の将来のバージョンでは、この出力形式が強制され、逸脱したローカルチェックが無視される可能性があります。 |
出力の結果が不明な場合は、echo コマンドを使用して小さなスクリプトを作成して、簡単にテストすることができます。
テストしたい出力をecho コマンドに挿入します。
この例では、外部には二重引用符を使用しています。これは、内部変数 (環境変数およびスクリプトで設定された変数) が評価されるためです。
その結果、サービス名の引用符は、シェルによって文字列の終わりと始まりとして解釈されて(したがって出力から削除されて)しまわないように、\ で囲む必要があります。
#!/bin/bash
echo "0 \"My 1st service\" - This static service is always OK"Windows ホストの場合、このようなスクリプトは次のように表示されます。
@echo off
echo 0 "My 1st service" - This static service is always OKどちらのスクリプトも、出力結果は同じになります。
0 "My 1st service" - This static service is always OKCheckmk では、この出力のみ関連があり、この出力をどのように作成したかは関係ありません。
ちなみに、スクリプトには任意の数の出力を記述することができます。 各出力行には、Checkmk で独自のサービスが作成されます。 そのため、Checkmkで複数行の出力を行う場合など、マスクされていない限り、出力に改行文字は使用できません。
ローカルスクリプトがエージェントによって正しく呼び出されているかどうかを、エラー分析で確認できます。
Nagios コアを使用する場合(常に Checkmk Raw で使用)、サービス名には以下の特殊文字は使用できません。 |
2.2. スクリプトの配布
スクリプトが作成されたら、それを適切なホストに配布することができます。 使用するパスは、オペレーティングシステムによって異なります。 パス名のリストは、以下の「ファイルおよびディレクトリ」に記載されています。
Unix 系システムでは、スクリプトを実行可能にすることを忘れないでください。 この例で示しているパスは、Linux (デフォルト設定のエージェントパッケージ) 用のものです。
root@linux# chmod +x /usr/lib/check_mk_agent/local/mylocalcheckエージェントベーカリーを使用する場合、スクリプトはルールベースの手順で配布できます。 ルールの作成の詳細については、「エージェントベーカリーによる配布」の章をご覧ください。
2.3. サービスを監視に追加する
Checkmk エージェントが起動されるたびに、スクリプトに含まれるローカルチェックも実行され、エージェントの出力に追加されます。 サービスディスカバリーも、他のサービスと同様に自動的に機能します。

サービスが監視に追加され、変更がアクティブになると、ローカルチェックによる自己作成サービスの実装は完了です。 サービスディスカバリー中に問題が発生した場合は、エラー分析が役立ちます。
3. メトリック
3.1. メトリックの定義
ローカルチェックでメトリックを定義することもできます。 メトリックデータの最短の構文は次のとおりです。
metricname=valueここで、value は現在の値です。
メトリックデータの完全な構文は次のとおりです。
metricname=value;warn;crit;min;maxここで、warn およびcrit は(上限)閾値です。
これらの閾値をグラフに表示するには、動的計算を有効にする必要があります(状態P )。
その後、Checkmk を使用して状態が計算されます。min およびmax で最後に指定したパラメータによって、値の範囲が固定されます。
完全な例は以下のようになります:
count=73;80;90;0;100値はセミコロンで区切られます。
値が不要な場合は、フィールドを空のままにしたり、末尾で省略したりします。例えば、warn 、crit 、max の場合:
count=42;;;0商業版では |
3.2. メトリックで使用される名前と単位
ローカルチェックのメトリック定義は、他のタイプのチェックのメトリック定義と変わりません。 最終的には、メトリックに単位とわかりやすい名前を割り当てるには、 3 つの選択肢があります。
必要な目的に「適合する」既存のメトリック定義にアクセスします。
独自のメトリックをその場に応じて一意に作成します。これは、純粋なカウンターには多くの場合で十分です。
独自のメトリックを作成し、メトリック定義を保存します。これにより、最大の柔軟性が得られます。
既存のメトリック定義を使用する
適切な単位、自動的に調整される凡例、そして多くの場合パーフオメーターを取得する最も簡単な方法は、既存のメトリック定義を使用することです。
この記事では、いくつかの例で識別子humidity またはtemperature を使用しています。
両方に(湿度と温度)定義済みメトリック定義が存在し、メトリックに正しい単位を提供します。
どちらの場合も、メトリック定義はパーフオメーターを提供し、グラフの凡例には摂氏と 相対湿度がパーセントで表示されます。
メトリックのアドホックな定義
この記事で最初に示したメトリックの例では、myvalue 、count 、metricname などの名前を使用しました。
適切なメトリック定義がない場合、グラフの凡例ではこれらの名前の先頭文字が大文字になり、アンダースコアはスペースに置き換えられます。
したがって、outgoing_queue_size は、読みやすいOutgoing queue size になります。
純粋なカウンターには単位は必要ないため、適切に選択された識別子だけで、追加のメトリック定義を必要とせずにその目的を果たすことができます。
単位が実際に必要な場合は、名前の中に含める必要があります。
メトリックをその場その場で定義しようと試みた結果、前のセクションで説明したような影響が生じ、既存のメトリック定義が割り当てられてしまう場合、問題になります。
特に、単位が一致しない場合、最大の混乱が生じる可能性があります。たとえば、指定されたメトリックが 0 から 100 % の浮動小数点数のパーセンテージスケールを使用しているのに、ローカルチェックの値の範囲が固定小数点数の無限大の数値である場合です。
あるいは、現在のリクエストのキュー (Current requests queue) があり、それを単にcurrent と命名したい場合、その結果、電流のメトリック定義が割り当てられてしまいます。
したがって、current_requests_queue がここでの適切な選択です。
追加のプレフィックスを付けることで完全に安全です。例えば:mycompany_current_requests_queue 。
独自のメトリック定義の記述
特別な要件がある場合、たとえば、凡例とパーフオメーター付きのグラフが必要な場合などは、独自のメトリック定義が必要になります。 エージェントベースのチェックプラグインのプログラミングに関する記事のメトリックに関する章をお読みください。
3.3. 複数のメトリック
複数のメトリックを出力することもできます。
定義では、これらは「パイプ」文字 (|) で区切られます。例えば、次のように記述します。
count1=42|count2=23Windows ホストでは、これらのパイプが出力にも表示されるように、スクリプトでこれらのパイプの前にサーキュムフレックス (^) を付ける必要があります。
@echo off
echo 0 "My 2nd service" count1=42^|count2=23 A service with 2 graphs2 つのメトリックを含む完全な出力は、次のように表示されます。
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
0 "My 2nd service" count1=42|count2=23 A service with 2 graphs新しいサービスを監視に追加すると、サービスリストの「Summary 」フィールドに、状態の詳細に関するテキストが表示されます。 サービスをクリックすると、そのサービスの詳細ページが表示されます。 メトリックは「Details 」フィールドに表示され、その下には Checkmk によって自動的に生成されたサービスのグラフが表示されます。

この例では、動的計算( |
3.4. 状態の動的計算
前のセクションでは、メトリックの値を提供し、それを使用してグラフを生成する方法を学びました。 次のステップは、追加で渡された閾値を使用して、サービスの状態を動的に計算することです。 これはまさに、プラグインによって生成される多くの状態と、受信したデータの準備を一致させるために Checkmk が実現している機能です。
状態を決定する出力の最初のフィールドに、数値ではなく文字「P 」を渡すと、渡された閾値に基づいてサービス状態が計算されます。
実際の値に加えて、転送された閾値もグラフに黄色と赤色の線で表示されます。
この動的な計算は、Checkmk で定義された監視ルールによって閾値を変更できることを意味するものではありません。 実際の計算には、ローカルチェックで指定された閾値が常に使用されます。 |
出力は次のように表示されます:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My 1st dynamic service" count=40;30;50 Result is computed from two threshold values
P "My 2nd dynamic service" - Result is computed with no values… サービスビューでの表示は次のようになります。

この表示は、以前の表示と2点異なります:
WARN またはCRIT 状態のサービスの場合、サービスの [Summary ] には、メトリックの重要な情報 (名前、値、閾値) がすべて表示されます。 これにより、この状態が値からどのように計算されたかを常に確認できます。 その他の状態の場合、メトリック情報は [Details ] フィールドにのみ表示されます。
メトリックが転送されない場合、サービス状態は常に「OK 」になります。
動的状態評価と静的状態評価の切り替え
ローカルチェックを行うスクリプトでは、動的状態評価と静的状態評価を切り替えることが有用な場合があります。
例として、ローカルチェックの形式でスプールファイルを作成するバックアップスクリプトを考えてみましょう。
バックアップの継続時間による状態評価は動的である必要があるため、スクリプトは「P 」と書き込む必要があります。
P "Backup stuff" duration=2342;1800;3600 Successfully created the backup. Good luck restoring.ただし、バックアップが短時間で失敗した場合、状態は閾値ではなくバックアップスクリプトの戻り値によって決定されます。 この場合、スクリプトは数値を使用して状態を静的に設定する必要があります。
2 "Backup stuff" duration=123;1800;3600 Backup failed. Nuff said.この場合、グラフに閾値が表示されないのは当然です。 なぜなら、問題となっているのは(失敗した)バックアップまでの所要時間ではなく、バックアップが成功しなかったという事実だからです。
3.5. 上限および下限の閾値
一部のパラメータには、上限閾値だけでなく下限閾値も設定されています。 その一例が、湿度記録です。 このような場合、ローカルチェックでは、WARN およびCRIT 状態それぞれについて 2 つの閾値を渡すオプションが用意されています。 これらはコロンで区切られ、それぞれ下限閾値と上限閾値を表します。
一般的な構文では、次のように表示されます。
metricname=value;warn_lower:warn_upper;crit_lower:crit_upper… 例では次のように表示されます:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My 3rd service" humidity=37;40:60;30:70 A service with lower and upper thresholds… サービスビューの表示では、次のように表示されます。

下限の閾値のみに関心がある場合は、上限の閾値のフィールドを省略してください。
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My 4th dynamic service" count_lower=37;40:;30: A service with lower thresholds onlyこの出力では、値が 40 未満の場合はWARN 、30 未満の場合はCRIT になるようサービスを指定しています。 したがって、指定した値が 37 の場合、サービスはWARN 状態になります。
Checkmk のメトリックおよびグラフ表示システムは、簡潔さを優先するため、上限閾値のみに対応しています。 つまり、サービスの状態の判定は期待どおりに機能しますが、メトリックおよびグラフ表示コンポーネントに表示される情報では、下限閾値は無視されます。 このため、下限閾値のみを使用している場合、グラフの黄色や赤の線、パーフオメーター、Service performance data などのエレメントは、Checkmk GUI にまったく表示されません。 |
3.6. 複数行出力
出力を複数行に分割するオプションも利用できます。
Checkmk は Linux で動作するため、エスケープシーケンス'\n' を使用して、改行を強制することができます。
スクリプト言語の都合でバックスラッシュ自体をエスケープする必要がある場合でも、Checkmk はそれを正しく解釈します。
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My service" humidity=37;40:60;30:70 My service output\nA line with details\nAnother line with detailsサービスの詳細では、これらの追加行は「Summary 」の下に表示されます。

4. 非同期実行
エージェントプラグインと同様に、ローカルチェックの出力もキャッシュすることができます。 これは、スクリプトの処理時間が長い場合に必要になることがあります。 このようなスクリプトは、非同期で、定義された時間間隔でのみ実行され、最後の出力がキャッシュされます。 時間切れになる前にエージェントが再度クエリされると、エージェントはローカルチェックにこのキャッシュを使用し、エージェント出力に返します。
キャッシュは、AIX、FreeBSD、Linux、OpenWrt、および Windows でのみ使用できます。 その他のプラットフォームでは、スプールディレクトリと組み合わせてクーロンジョブを使用してください。 |
4.1. Linux の設定
Linux またはその他の Unix 系オペレーティングシステムでは、あらゆるプラグインを非同期で実行できます。 ローカルチェックの場合、必要な設定はプラグインの場合とよく似ています。 これを行うには、出力をキャッシュする秒数と同じ名前のサブディレクトリを作成し、そのサブディレクトリにスクリプトを配置します。
次の例では、ローカルチェックは 10 分(600 秒)ごとにのみ実行されます。
root@linux# /usr/lib/check_mk_agent/local/600/mylocalcheck
2 "My cached service" count=4 Some output of a long running scriptキャッシュされたデータは、キャッシュディレクトリに書き込まれます。
キャッシュされたデータを提供するサービスの場合、キャッシュ固有の情報がサービスビューに追加されます。

4.2. Windows の設定
Windows でも、設定はエージェントプラグインの場合と同様です。 Linux などでは特別なサブディレクトリを使用しますが、Windows では、設定ファイルでオプションを設定します。
local:
enabled: yes
execution:
- pattern : $CUSTOM_LOCAL_PATH$\mylocalcheck.bat
async : yes
run : yes
cache_age : 600上記のように、Windows では、非同期実行 (async) と時間間隔 (cache_age) を個別に設定できます。
あるいは、Windows では、エージェントベーカリーで設定を行うこともできます。
5. エージェントベーカリーによる配布
商業版でエージェントベーカリーをすでに使用している場合は、この方法でローカルチェック付きのスクリプトを複数のホストに配布することもできます。
これを行うには、まず、Checkmk サーバーの~/local/share/check_mk/agents/ の下に、サイトユーザーとしてcustom ディレクトリを作成し、その中にローカルチェックの各パッケージ用のサブディレクトリツリーを作成します。
OMD[mysite]:~$ cd ~/local/share/check_mk/agents
OMD[mysite]:~$ ~/local/share/check_mk/agents$ mkdir -p custom/mycustompackage/lib/local/上記の例の場合、パッケージディレクトリはmycustompackage です。
その下に、lib ディレクトリが、スクリプトをプラグインまたはローカルチェックとしてフラグ付けします。
次のlocal ディレクトリは、ファイルを明示的に割り当てます。
ローカルチェック付きのスクリプトをこのディレクトリに配置してください。
Linux では、前の章で説明したのと同様に、 |
Checkmk の設定環境では、パッケージディレクトリmycustompackage が新しいオプションとして表示されます。Setup > Agents > Windows, Linux, Solaris, AIX を開き、Agents > Agent rules > Generic agent options > Deploy custom files with agent で新しいルールを作成し、新しく作成したパッケージを選択します。

Checkmk は、ローカルチェックを適切なオペレーティングシステムの インストールパッケージに自動的に正しく統合します。 変更をアクティブにしてエージェントをベイクすると、設定は完了です。 あとは、エージェントを配布するだけです。
6. エラー分析
6.1. スクリプトのテスト
自作のスクリプトで問題が発生した場合は、以下の潜在的なエラーの原因をチェックしてください。
スクリプトは正しいディレクトリにありますか?
スクリプトは実行可能であり、アクセス許可は正しいですか? これは、エージェントまたはスクリプトを root または LocalSystem アカウントで実行していない場合に特に重要です。
-
出力は指定された構文に準拠していますか? ローカルチェックの出力は、「スクリプトの作成」および「メトリック」の章で説明されている構文に準拠している必要があります。 そうしないと、エラーのない実行は保証されません。
ローカルチェックで、本格的なチェックプラグインを必要とするタスクを実行する場合、たとえば、ローカルチェック自体の出力にセクションヘッダーや、ピギーバックデータの転送に使用されるホスト名の定義が含まれている場合、問題やエラーが発生する可能性があります。
Linux では、エージェントスクリプトまたはプラグインがシェルで直接呼び出された場合、Checkmk エージェントのエージェントコントローラーによって呼び出された場合とは異なる環境変数が使用される場合があります。 Windows では、エージェントコントローラーも LocalSystem アカウントで実行されますが、ターミナルでの呼び出しは通常のユーザーまたは管理者で行われます。 環境の違いに加え、これにより許可が失われる場合があります。 Checkmk エージェントが呼び出された条件とできるだけ近い状態でエージェントスクリプトの出力を分析するには、可能であればエージェントコントローラーをダンプモードで使用してください。 |
6.2. ターゲットホストでのエージェント出力のテスト
スクリプト自体に問題がない場合は、エージェントをホストで実行できます。
Linux、BSD などの Unix 系オペレーティングシステムでは、以下のコマンドを使用できます。-A オプションを使用すると、ヒット後に表示する追加行数を指定できます。
この数は、予想される出力行数に合わせてカスタマイズできます。
root@linux# cmk-agent-ctl dump | grep -v grep | grep -A2 "<<<local"
<<<local:sep(0)>>>
P "My service" humidity=37;40:60;30:70 My service output\nA line with details\nAnother line with details
cached(1618580356,600) 2 "My cached service" count=4 Some output of a long running script最後の行では、現在の Unix 時間と実行間隔(秒単位)が記載された「cached 」という情報によって、キャッシュされたサービスを認識できます。
Windows では、Linux のgrep コマンドとよく似た結果を、パワーシェルとSelect-String コマンドレットを使用して実現できます。次のコマンドでは、Context パラメータの後の2桁の数字で、ヒットの前後に出力する行数を指定します。
PS C:\Program Files (x86)\checkmk\service> ./cmk-agent-ctl.exe dump | Select-String -Pattern "<<<local" -Context 0,3
> <<<local:sep(0)>>>
0 "My 1st service" - This static service is always OK
cached(1618580520,600) 1 "My cached service on Windows" count=4 Some output of a long running script環境、使用するプログラミング言語、Windows のバージョン、その他の条件によっては、Windows でUTF-16文字セットに直面することがよくあります。 さらに、行の改行にはキャリッジリターンと ラインフィードの組み合わせがよく使用されます。 しかし、Linux アプリケーションである Checkmk は、UTF-8および単純なラインフィードを無条件に期待します。 スプールディレクトリに関する記事には、文字セット関連の問題のトラブルシューティングを説明する章があります。 |
6.3. Checkmk サーバーでのエージェント出力のテスト
最後のステップとして、cmk コマンドを使用して、Checkmk サーバーでスクリプト出力の処理をテストすることもできます。サービスディスカバリーでは 1 回、
OMD[mysite]:~$ cmk -IIv --detect-plugins=local mycmkserver
Discovering services and host labels on: mycmkserver
mycmkserver:
...
+ EXECUTING DISCOVERY PLUGINS (1)
2 local
SUCCESS - Found 2 services, no host labels... また、同様のコマンドを使用して、サービス出力の処理もテストできます。
OMD[mysite]:~$ cmk -nv --detect-plugins=local mycmkserver
+ FETCHING DATA
Get piggybacked data
My cached service Some output of a long running script(!!), Cache generated 6 minutes 30 seconds ago, cache interval: 10 minutes 0 seconds, elapsed cache lifespan: 68.71%
My service My service output, Humidity: 37.00 (warn/crit below 40.00/30.00)(!)
[agent] Success, [piggyback] Success (but no data found for this host), execution time 3.3 sec ...両方のコマンドでは、このトピックに関係のない行を省略して出力を短縮しています。
あるいは 、監視でホストのサービスリストを開き、サービスCheck_MK とその列Icons に移動します。 そこで、メニューエントリDownload agent output を選択して、エージェントの出力全体を含むテキストファイルを取得することができます。
ローカルチェックでエラーが発生した場合、Checkmk はサービス出力でそれらを識別します。 これは、誤ったメトリック、スクリプト出力の誤った情報または不完全な情報、および無効な状態にも適用されます。 これらのエラーメッセージは、スクリプトのエラーを迅速に特定するのに役立ちます。
7. ファイルおよびディレクトリ
指定したパスはすべて、標準構成でパッケージ化されたインストールパッケージを指します。 パッケージ化されていないエージェントスクリプトをインストールした場合、またはベーカリールールを使用してインストールディレクトリを適応させた場合は、スクリプト自体でパスを確認するか、パスを自分の構成に合わせて適応させてください。
7.1. ターゲットホストのスクリプトディレクトリ
ローカルチェックは、これらのディレクトリに保存します。 ローカルチェックは、任意の実行可能ファイルにすることができます。
| パス | オペレーティングシステム |
|---|---|
|
AIX、Linux、および Solaris |
|
Windows |
7.2. ターゲットホストのキャッシュディレクトリ
local セクションを含む個々のセクションのキャッシュデータはここに保存され、データが有効である限り、実行ごとにエージェントに再アタッチされます。
| パス | オペレーティングシステム |
|---|---|
|
AIX、Linux、および Solaris |
