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 は通常、TCP 接続を介してポート 6556 にプルモードで監視対象のホストにアクセスします。2.1.0 以降、ほとんどの場合、エージェントコントローラーはこのポートをリッスンし、TLS 暗号化接続を介してエージェントの出力を転送します。 Checkmk2.2.0 では、プッシュモードという送信方向を選択する代替オプションが導入されました。
ただし、エージェントコントローラーを使用できない環境(例えば、ストリップダウンされたコンテナ、レガシーシステム、組み込みシステムなど)もあります。
このような場合、レガシーモードが適用され、(x)inetd は接続を確立した後、エージェントスクリプトを実行し、エージェントの出力はプレーンテキストとして転送され、接続はすぐに閉じられます。
多くの場合、セキュリティポリシーにより、プレーンテキストでのデータ送信などの操作は回避する必要があります。 たとえば、ファイルシステムのフィルレベルは攻撃者にとってほとんど意味がありませんが、プロセステーブルや欠落しているアップデートのリストは、攻撃の標的を絞る上で役立ちます。 さらに、既存の通信チャンネルを使用することで、追加のポートを開くことを避けるべきです。
このような転送手順を Checkmk に接続するための汎用的な方法は、データソースプログラムです。 その考え方は非常に単純です。 コマンドをテキストとして Checkmk に渡します。 Checkmk は、ポート 6556 に接続する代わりに、このコマンドを実行します。 これにより、エージェントデータが標準出力に生成され、Checkmk は「通常の」エージェントから送信されたデータとまったく同じようにこのデータを処理します。 データソースの変更は通常、転送にのみ影響するため、セットアップ GUI でホストを「API integrations if configured, else Checkmk agent 」のままにしておくことが重要です。
Checkmk のモジュール性により、プレーンテキストのエージェント出力を任意のトランスポート手段で送信することで、これらの要件を満たすことができます。 最終的には、エージェントスクリプトのプレーンテキスト出力は、直接または間接、プルまたはプッシュなど、あらゆる手段で転送することができます。 エージェントデータを Checkmk サーバーに取得する方法の例をいくつかご紹介します。
電子メール経由
サーバーからの HTTP アクセス経由
ホストからの HTTP アップロード経由
rsyncを使用してサーバーにコピーされたファイルへのアクセスによる方法scpHTTP を使用して web サービスからデータを取得するスクリプト経由
データソースプログラムのもう 1 つの用途は、エージェントのインストールは許可していないが、REST API または Telnet インターフェイスを介してステータスデータを発行するシステムです。 このような場合、既存のインターフェイスを照会し、取得したデータからエージェント出力を生成するデータソースプログラムを作成することができます。
2. データソースプログラムの記述
2.1. 最もシンプルなプログラム
データソースプログラムの作成とインストールは難しくありません。
Linux でサポートされているスクリプトおよびプログラム言語ならどれでも使用できます。
プログラムは、データパスを指定しなくても常に自動的に見つかる、~/local/bin/ ディレクトリに保存することをお勧めします。
以下の最初の非常に基本的な例はmyds と呼ばれ、単純な架空の監視データを生成します。
新しい転送パスを統合する代わりに、監視データ自体を生成します。
これらは、1 つのセクション<<<df>>> で構成され、1 つのファイルシステムに関する情報が含まれています。
このセクションのサイズは 100 kB で、名前はMy_Disk です。
これは、3 行のシェルスクリプトとして記述されています。
#!/bin/sh
echo '<<<df>>>'
echo 'My_Disk foobar 100 70 30 70% /my_disk'プログラムを実行可能にすることを忘れないでください:
OMD[mysite]:~$ chmod +x local/bin/myds次に、セットアップでテストホストを作成します。たとえば、myserver125 と入力します。
IP アドレスは不要です。
Checkmk がmyserver125 を DNS 経由で解決しようとしないように、この名前を明示的な「IP アドレス」として入力してください。
次に、このホストに適用されるルールをSetup > Agents > Other integrations > Individual program call instead of agent access ルールセットに追加し、実行可能プログラムとしてmyds を入力します。

セットアップ GUI でホストのサービス設定に移動すると、監視を開始できるサービスが 1 つだけリストされているはずです。

このサービスを監視に追加し、変更をアクティブにすると、最初のデータソースプログラムが実行されます。
テストとして、プログラムによって生成されるデータを変更すると、My_Disk ファイルシステムの次のチェックでそれがすぐに表示されます。
2.2. エラー診断
何かが正しく機能していない場合は、コマンドラインに「cmk -D 」と入力して、ホストの構成をチェックし、ルールが有効になっているかどうかを確認できます。
OMD[mysite]:~$ cmk -D myserver125
myserver125
Addresses: myserver125
Tags: [address_family:ip-v4-only], [agent:cmk-agent], [criticality:prod], [ip-v4:ip-v4], [networking:lan], [piggyback:auto-piggyback], [site:mysite], [snmp_ds:no-snmp], [tcp:tcp]
Host groups: check_mk
Agent mode: Normal Checkmk agent, or special agent if configured
Type of agent:
Program: mydscmk -d を使用すると、エージェントデータの取得とプログラムの実行をトリガーすることができます。
OMD[mysite]:~$ cmk -d myserver125
<<<df>>>
My_Disk foobar 100 70 30 70% /my_disk-v を 2 回実行すると、プログラムが呼び出されるというメッセージが表示されます。
OMD[mysite]:~$ cmk -vvd myserver125
Calling: myds
<<<df>>>
My_Disk foobar 100 70 30 70% /my_disk2.3. ホスト名の転送
この例のプログラムは実際に動作しますが、呼び出されたホストに関係なく常に同じデータを生成するため、あまり有用ではありません。
たとえば、HTTP 経由でどこからかデータを取得するような実際のプログラムでは、少なくともデータを取得するホストの名前が必要です。$HOSTNAME$ をコマンドラインにプレースホルダーとしてコーディングすることで、これを転送することができます。

この例では、プログラムmyds は、最初の引数としてホスト名を受け取ります。
次のプログラム例は、ローカルチェックのフォームでこれをテストするために作成されています。$1 により、最初の引数が取得され、概要として$HOST_NAME 変数に保存されます。
これは、ローカルチェックのプラグイン出力に挿入されます。
#!/bin/sh
HOST_NAME="$1"
echo '<<<local>>>'
echo "0 Hostname - My name is ${HOST_NAME}"サービスディスカバリーは、local タイプの新しいサービスを見つけ、その出力からホスト名を見つけます。

ここから、curl コマンドを使用して HTTP 経由でデータを取得するような、実際のデータソースプログラムへの移行は、あと少しです。
データソースプログラムのコマンドラインでは、以下のプレースホルダーを使用できます。
|
セットアップで設定されたホスト名。 |
|
監視するホストの IP アドレス。 |
|
空白文字で区切られたすべてのホストタグのリスト – シェルによって分割されないように、この引数は引用符で囲んでください。 |
IPv4 と IPv6 を使用してデュアル監視を行っている場合、次のマクロが役立つかもしれません。
|
ホストの IPv4 アドレス |
|
ホストの IPv6 アドレス |
|
IPv4 アドレスが監視に使用されている場合は数字の「 |
2.4. エラーのハンドル
IT 分野での実際の職務に関係なく、エラーや問題への対応に多くの時間を費やすことになるでしょう。 データソースプログラムも例外ではありません。 特に、ネットワークを介してデータを提供するプログラムの場合、エラーがまったく発生しないことを期待することは現実的ではありません。
Checkmk がエラーをプログラムに整然と伝達するために、以下の事項が適用されます。
0以外の終了コードはエラーとして扱われます。エラーメッセージは、標準エラーチャンネル (
stderr) で受け取ります。
データソースプログラムが失敗した場合、
Checkmk は出力のユーザーデータをすべて破棄し、
Check_MK サービスをCRIT に設定し、
stderrからのデータをエラーとして識別します。実際のサービスは以前の状態のまま残ります (時間の経過とともに面白くなくなります)。
上記の例を、エラーをシミュレートするように変更することができます。
リダイレクト>&2 により、テキストはstderr に転送され、exit 1 はプログラムの終了コードを1 に設定します。
#!/bin/sh
HOST_NAME=$1
echo "<<<local>>>"
echo "0 Hostname - My name is $HOST_NAME"
echo "This didn't work out" >&2
exit 1Check_MK サービスとしては、次のように表示されます。

シェルスクリプトとしてプログラムを書く場合は、最初にset -e オプションを記述します。
#!/bin/sh
set -e命令がエラー(つまり、終了コードが0 以外)を生成すると、シェルは直ちに停止し、終了コード1 を発行します。
これにより、汎用的なエラー処理が可能になり、すべての命令の成功を個別にチェックする必要がなくなります。
3. スペシャルエージェント
Checkmk には、よく必要となるデータソースプログラムが数多く付属しています。 これらのスペシャルエージェントについては、別の記事で説明します。
4. ファイルとディレクトリ
| パス | 機能 |
|---|---|
|
検索パスにあるべき、パスを指定せずに直接実行できる、独自のプログラムおよびスクリプトの保存場所。プログラムが |
