1. 概要
アプリケーションプログラミングインタフェースとしての Checkmk REST API を使用すると、HTTP リクエストによるコマンドまたはスクリプトでタスクを Checkmk サーバーに送信し、実行させることができます。このタスクは、通常、Checkmk の GUI を使用して実行します。
REST API の「REST」はREpresentational State Transfer(表現状態転送)の略で、分散システム、特に web サービスにおけるデータ交換のアーキテクチャを表しています。 REST アーキテクチャに従って実装された API は、クライアント・サーバーモデル、ステートレス通信、統一インターフェースなどの特定の原則に従います。 実際には、実装は HTTP プロトコルを介して行うことが望ましいです。このプロトコルでは、リソースは Uniform Resource Identifier (URI) によってアドレス指定され、HTTP メソッド (GET、POST、PUT、DELETE) を使用してアクセスされます。
以上が REST の原則です。 これらの原則の利点は、Checkmk REST API が提供する具体的な機能によって実証できます。
プロトコル |
通信のトランスポートシステムとして、ハイパーテキスト転送プロトコル(HTTP/1.1)が使用されます。 |
コーディング |
データ形式としてJavaScript Object Notation(JSON)が使用されます。 応答のペイロードはJSONでシリアライズされ、UTF-8でエンコードされます。 日付と時刻情報は、有効なタイムゾーン情報と共にISO-8601形式でエンコードされます。 |
言語 |
ラベル、識別子、および API ドキュメントの言語は英語です。 |
認証 |
API へのアクセスは、HTTP 認証(例えば「Bearer」)によって認可されたクライアントにのみ許可されます。 |
バージョン |
API にはバージョンがあり、Semantic Versioning 2.x標準に準拠した番号付け方式が使用されています。 詳細については、以下の「バージョン管理」セクションをご覧ください。 |
ドキュメント |
API は、機械が読み取り可能な構造と、人間が読み取り可能な英語形式で文書化されており、すべてのリソース、その入力および出力パラメータ、および関連する値の範囲が含まれています。 API は、REST API 専用の API 記述フォーマットであるOpenAPI Specification (OAS) 3.x を使用して作成されています。 この仕様を使用して作成された API ドキュメントは、OpenAPI ドキュメント用のレスポンシブ Web デザインである ReDoc を使用してユーザーに表示されます。 |
コード例 |
その使用方法を示すために、各リクエストについて、さまざまなアプリケーション用のサンプルコード(curl や httpie など)が用意されています。 |
エラー表示 |
エラーが発生した場合、API は、問題に関する数値のHTTP ステータスコードと診断メッセージを送信します。これにより、不正なリクエストの考えられる原因を特定することができます。 |
REST API の分類 |
この API は、API の REST 度を評価するために使用できるリチャードソン成熟度モデル (RMM) の 4 つのレベル (0 から 3) をすべて満たしています。 レベル 1 では、グローバルなエンドポイントではなく、個々のエンドポイントとの通信を可能にするリソースの導入が必要です。 レベル 2 は、リクエストに HTTP メソッドが使用されている場合に満たされます。 最高レベルであるレベル 3 では、API は事実上自己文書化されています。つまり、サーバーはリクエストに応答する際に、実行可能な次のアクションと対処すべきリソースをすべて伝達するため、クライアントは利用可能な機能を自ら発見することができます。 この追加情報の提供は、「アプリケーションの状態のエンジンとしてのハイパーメディア (HATEOAS)」とも呼ばれています。 |
これらの一般的な快適機能に加え、REST API は、Checkmk の以前のリリースでは GUI およびコマンドインターフェースを介して提供されていた機能をすべて網羅することを目的としています。
サービス品質保証 (SLA) やエージェントベーカリーなど、商業版にのみ存在する機能については、関連する REST API の方法もこれらのエディションでのみ提供されます。
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. |
2. API ドキュメント
2.1. バージョン管理
REST API の利点の 1 つは、ソフトウェアとそのドキュメントが、同じソース(OpenAPI ドキュメント)から提供されていることです。 したがって、API ドキュメントは常にソフトウェアと一致し、API の機能を正確に説明しています。 そのため、Checkmk ユーザーガイドで、利用可能なリソース、方法、パラメータなどの参照部分を説明する必要はありません。代わりに、このマニュアルとは別に、Checkmk サイトから API ドキュメントを直接ご覧いただけます。
API およびそのドキュメントにはバージョンが付けられており、X.Y 形式の 2 レベルの番号体系が使用されています。ここで、X はメジャーバージョン、Y はマイナーバージョンを表します。
新しいマイナーバージョンには、既存の機能に影響を与えない、下位互換性のある変更のみが含まれます。
一方、新しいメジャーバージョンには、API を以前のメジャーバージョンと互換性がないようにする変更(いわゆる破壊的な変更)が含まれます。
メジャーバージョンおよびマイナーバージョンのバージョン番号は、サーバーにリクエストを送信する URL の一部です。
Checkmk REST API は現在、パッチバージョンにセマンティックバージョニング標準の 3 番目のレベル(.Z )を使用していません。
REST API は、Checkmk ソフトウェアとは異なるバージョン管理方式を採用しています。 API に互換性のない変更があった場合は、API の新しいメジャーバージョンが必要になるため、通常、Checkmk ソフトウェアのリリースサイクルとは一致しません。
ただし、API ドキュメントと Checkmk ソフトウェアのバージョンの相関関係は、次の章で説明するように非常に単純です。
2.2. アクセス
REST API ドキュメントは、web ブラウザで表示できる HTML 形式で提供されています。
Checkmk GUI で、ナビゲーションバーからHelp > Developer resources > REST API documentation を選択して API ドキュメントを開きます。 API ドキュメントは、新しいブラウザウィンドウ(またはブラウザのタブ)に表示されます。 これについては、次の章で詳しく説明します。

Help メニューには、REST API に関するエントリがさらに多くあることにお気づきでしょう。REST API introduction で、この記事を開くことができます。 REST API interactive GUI で、REST API の別のビューを開くことができます。 このエントリは、REST API 機能が表示されるだけでなく、ブラウザから直接 API と対話できる(たとえば、サーバーにリクエストを送信できる)ため、GUI という名前になっています。 スクリプトによる実行の代替手段として、REST API GUI を、REST API GUI に関する章で後で紹介します。 |
2.3. 構造と内容
API ドキュメントは、3 つのセクションで構成されるレスポンシブ Web デザインを採用しています。

左側のセクション「ナビゲーション」は、オリエンテーション、検索、および中央のセクションのエントリの正確な説明へのクイックジャンプに使用されます。 目次には、API エンドポイントごとに 1 つのエントリが含まれています。 エンドポイントは、API が提供するリソース (ホストなど) を参照するために URL を使用し、リソースへのアクセスに使用する方法 (ホストを表示するには GET など) も指定します。 エンドポイントは、いくつかのフォルダに整理されています。
中央のセクション「Content」には、ドキュメントの重要な事実が記載されています。 リクエストを定義するためのすべての情報(パラメータ、値の範囲、デフォルト値、説明)および対応する回答(詳細もすべて記載)が含まれます。 返されるHTTP ステータスコードが成功またはエラーのいずれであるかに応じて、可能な回答がさまざまな色で表示されます。
右側のセクション「Request samples 」には、コンテンツセクションで選択したエンドポイントの方法と URL が表示され、その後にいくつかのリクエストの例が示されます。 JSON 形式のペイロード(エンドポイントに関連する場合)と、curl、httpie、Python Requests、Python Urllib などのコード例です。 その後、HTTP ステータスに応じた応答が続きます。 すべてのコード例は、「Copy 」ボタンでクリップボードにコピーできます。
ナビゲーションセクションは、他の 2 つのセクションとスクロール同期されています。つまり、コンテンツセクションを上下にスクロールすると、ナビゲーションセクションも目次内の適切な項目に自動的にスクロールします。
レスポンシブ web デザインにより、ブラウザウィンドウが非常に狭い場合でも、例セクションが表示されないようになっています(その場合は、例は対応する方法の下に表示されます)。また、ナビゲーションセクションはメニューに変換されます。
すべてのセクションには、表示/非表示を切り替えられるコンテンツがあります。たとえば、ナビゲーションセクションのエンドポイントのエントリ、コンテンツセクションのネストされたパラメータなどです。> またはExpand all をクリックすると、非表示のコンテンツを表示でき、∨ またはCollapse all をクリックすると、再び非表示にできます。
次の章では、API ドキュメントを使用して、情報から具体的なリクエストを作成し、そのリクエストを Checkmk サーバーに送信し、実行して、その実行と結果を監視する方法について説明します。
3. API の使用
3.1. 認証
クライアントから Checkmk サーバーの REST API を使用するには、クライアントは自分の身元を証明する必要があります。 REST API は、認証にBearer、Web サーバー、Cookie の順で優先順位の高い方法を使用します。 つまり、たとえば Bearer による認証が成功した場合、他の方法はチェックされません。
Bearer またはヘッダー認証
「Bearer」とは、ID の所有者を意味します。 クライアントは、Checkmk サーバーに設定されたユーザーの認証情報を使用して、自身を認証します。 理想的には、これは API 経由でアクションを実行するために Checkmk で提供される、いわゆるオートメーションユーザーです。 Bearer 認証は、スクリプトでの使用をお勧めします。
認証には、ユーザー名と、マシンアカウント用のいわゆるオートメーションの秘密、つまりオートメーションユーザーのパスワードが必要です。 この 2 つの情報は、各リクエストのヘッダーで Checkmk サーバーに送信する必要があります。
オートメーションユーザーは、他のユーザーと同様に、Setup > Users > Users で確認できます。 オートメーションユーザーの役割と関連する許可が、リクエストの実行を許可するように設定されていることを確認してください。
この記事で紹介するスクリプトでは、automation というオートメーションユーザーが常に例として使用されています。
web サーバーの認証
web サーバーの認証には、REST API は web サーバーに設定されている HTTP 認証(「基本」または「ダイジェスト」)を使用します。
この認証方法は、Apache web サーバーの認証用にソフトウェアモジュールを使用して設定する、特別な要件のある大規模な Checkmk インストール用です。 web サーバー認証を使用する場合は、Checkmk サイト自体の Apache web サーバーを再設定する必要があります。
Cookie 認証
Cookie 認証は、API キーによる認証の特殊なケースです。Checkmk にログインし、HTTP Cookie が割り当てられているすべての Checkmk ユーザーは、REST API を使用できます。Cookie 認証は、REST API GUI の試用およびテストに使用されます。リクエストを実行できるかどうかは、Checkmk ユーザーアカウントに適切な許可が与えられているかどうかによって決まります。
3.2. HTTP ステータスコード
REST API は、各リクエストに対してHTTP ステータスコードを返します。このステータスコードを使用して、リクエストが成功したかどうかを チェックできます。 リクエストで可能なすべての HTTP ステータスコードは、API ドキュメントにリストされています。
HTTP ステータスコードは、リクエストの送信が成功したかどうかについての情報のみを提供し、実行が成功したかどうかについての情報は提供しませんのでご注意ください。 コマンドは、ライブステータスで Checkmk サーバー上で実行されます。 REST API によるリクエストが意図したとおりに実行されたことを確認するには、ご自身で成功を確認する必要があります。Help > Developer resources > REST API interactive GUI で開くことができる API ドキュメントの「REST API によるクエリ」セクションには、このタスクのサンプルスクリプトが掲載されています。
3.3. API のローカルテスト
REST API をテストするには、Checkmk サーバーから直接リクエストを行うことをお勧めします。この例では、リクエストを送信するクライアントとリクエストを受信するサーバーは、同じコンピュータ上にあります。
サイトユーザーとして作業している場合は、サイト名を指す$OMD_SITE などのローカル変数も使用できます。
以下の簡単な例では、API ドキュメントに含まれる、コマンドラインプログラム curl のサンプルコードを使用しています。このプログラムを使用すると、HTTP などを介して、ユーザーの操作なしでサーバーとの間でデータを転送することができます。
特に複雑なリクエストの場合、curl の例には矛盾が含まれている場合があり、必ずしも信頼できるとは限りません。 httpieを使用すると、一貫性があり、理解しやすく、スクリプトでの使用に最適な代替手段を利用できます。 |
curl コマンドは、bashスクリプト内で実行されます。
準備として、次のセクションで実行するリクエストごとにスクリプトファイルを作成し、後でサンプルコードをコピーします。
OMD[mysite]:~$ touch create_host.sh service_discovery.sh show_pending_changes.sh activate_changes.sh
OMD[mysite]:~$ chmod +x create_host.sh service_discovery.sh show_pending_changes.sh activate_changes.shREST API は、すべての応答を 1 行の JSON 形式で出力します。
フォーマットされた出力の方が読みやすいため、以下の例では 1 行の出力を複数行にフォーマットして表示しています。
JSON 形式を処理するための web サイトやツールは、コマンドライン JSON プロセッサjq など、さまざまなものがあります。
開始する前に、Checkmk 構成に固有の基本情報を収集してください。
| 変数 | 例 | 意味 |
|---|---|---|
|
|
Checkmk サーバーのホスト名 |
|
|
Checkmk サイト名 |
|
|
オートメーションユーザーの名前 |
|
|
オートメーションユーザーのパスワード |
これらの変数はサンプルコードで使用されます。リクエストを送信する前に、ご自身で編集してください。 上記の表には、以下で使用されるサンプル値も記載されています。
3.4. スクリプトを使用したリクエストの作成
簡単な例で、REST API の使用方法を説明します。 合計 4 つのリクエストを使用して、サービスを含むホストを作成します。 原則として、Checkmk GUI と同じ手順で操作します。
ホストの作成
ホストのサービスディスカバリーを実行します。
保留中の変更を表示します
変更をアクティブにする
ホストの作成
API ドキュメントを開き、左側のナビゲーション領域でホストを作成するためのエントリ (Create a host) を選択します。

パネルの中央には、選択したリクエストの詳細、必要な HTTP 認証 (REST API 経由のすべてのリクエストで同じです)、および必須およびオプションのパラメータが表示されます。 ホストの名前と、ホストを作成するフォルダを指定する必要があります。 デフォルトでは、ホストはMain フォルダに作成されます。 別のフォルダにホストを作成する場合は、まず別の API リクエスト (Show all folders) を実行して、既存のフォルダを表示し、使用するフォルダの ID を確認する必要があります。
この例では、ホストmyhost123 を、IP アドレス192.168.0.42 で、Main フォルダに作成します。
API ドキュメントで、右側の例で「curl 」ボタンをクリックし、「Copy 」をクリックして、curl のサンプルコードをクリップボードにコピーします。
準備したスクリプト「create_host.sh 」を開き、クリップボードの内容を貼り付けます。
#!/bin/bash
# NOTE: We recommend all shell users to use the "httpie" examples instead.
# `curl` should not be used for writing large scripts.
# This code is provided for debugging purposes only.
HOST_NAME="localhost"
SITE_NAME="mysite"
PROTO="http" #[http|https]
API_URL="$PROTO://$HOST_NAME/$SITE_NAME/check_mk/api/1.0"
USERNAME="automation"
PASSWORD="test123"
curl \
--request POST \
--write-out "\nxxx-status_code=%{http_code}\n" \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '{
"attributes": {
"ipaddress": "192.168.0.123"
},
"folder": "/",
"host_name": "example.com"
}' \
"$API_URL/domain-types/host_config/collections/all"サンプルコードの最初の部分には環境変数があり、その後に、最後の行にある URL のリソースに対して POST 方法でcurl コマンドが続きます。
最後に、-write-out オプションによって、HTTP ステータスコードを含む行が出力されます。
ヘッダー行(そのうちの 1 つは HTTP 認証を定義しています)の後に、新しいホストのパラメータが定義されているデータセクションが続きます。
curl のサンプルコードには、特定の状況では必要のないパラメータが含まれている場合がありますのでご注意ください。
この例では、その必要はありません。既存の 2 つのパラメータ、host_name およびipaddress を変更するだけで済みます。
サンプルコードを編集して、結果が次のように表示されるようにします。
#!/bin/bash
# NOTE: We recommend all shell users to use the "httpie" examples instead.
# `curl` should not be used for writing large scripts.
# This code is provided for debugging purposes only.
HOST_NAME="myserver"
SITE_NAME="mysite"
PROTO="http" #[http|https]
API_URL="$PROTO://$HOST_NAME/$SITE_NAME/check_mk/api/1.0"
USERNAME="automation"
PASSWORD="theautomationsecret"
curl \
--request POST \
--write-out "\nxxx-status_code=%{http_code}\n" \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '{
"attributes": {
"ipaddress": "192.168.0.42"
},
"folder": "/",
"host_name": "myhost123"
}' \
"$API_URL/domain-types/host_config/collections/all"スクリプトを実行します。
OMD[mysite]:~$ ./create_host.sh
{
"links":[
{
"domainType":"link",
"rel":"self",
"href":"http://myserver/mysite/check_mk/api/1.0/objects/host_config/myhost123",
"method":"GET",
"type":"application/json"
},
...
{
"domainType":"link",
"rel":"urn:com.checkmk:rels/folder_config",
"href":"http://myserver/mysite/check_mk/api/1.0/objects/folder_config/~",
"method":"GET",
"type":"application/json",
"title":"The folder config of the host."
}
],
"domainType":"host_config",
"id":"myhost123",
"title":"myhost123",
"members":{
},
"extensions":{
"folder":"/",
"attributes":{
"ipaddress":"192.168.0.42",
"meta_data":{
"created_at":"2024-07-03T12:55:29.165920+00:00",
"updated_at":"2024-07-03T12:55:29.174520+00:00",
"created_by":"automation"
}
},
"effective_attributes":null,
"is_cluster":false,
"is_offline":false,
"cluster_nodes":null
}
}
xxx-status_code=200
注意: 波括弧で囲まれた JSON 形式の単一行は、ここでは複数行に分割して表示されています。
API は、links に、REST API にふさわしい、作成したホストに適用できるリクエストの選択(上記の例では省略)を返します。
最後に、API は、作成したホストの ID と名前(title )、folder 名(メインフォルダの場合は/ )、およびホストに割り当てられたattributes (IPアドレスを含む)を返します。
最後に、HTTP ステータスコードを含む行が出力されます。200 はOK を表し、アクションが正常に実行されたことを意味します。
ホストでサービスディスカバリーを実行します。
ホストmyhost123 が作成されたら、そのサービスをディスカバリーできます。
サービスディスカバリーが実際に期待されるサービスを提供するようにするには、Linux および Windows ホストで、それぞれのエージェントをインストールして登録する必要があります。
REST API 経由でサービスディスカバリーを実行するには、API ドキュメント (Execute a service discovery on a host) で適切なエントリを選択し、サンプルコードをこの目的のために作成したスクリプトファイルにコピーして、適宜変更します。
最初の部分は、前の例の環境変数をそのままコピーできます。curl コマンドで、ホストの名前をmyhost123 に変更し、必要に応じて、mode パラメータを使用してサービスディスカバリーのタイプを変更します。
#!/bin/bash
# NOTE: We recommend all shell users to use the "httpie" examples instead.
# `curl` should not be used for writing large scripts.
# This code is provided for debugging purposes only.
HOST_NAME="myserver"
SITE_NAME="mysite"
PROTO="http" #[http|https]
API_URL="$PROTO://$HOST_NAME/$SITE_NAME/check_mk/api/1.0"
USERNAME="automation"
PASSWORD="theautomationsecret"
curl \
--request POST \
--write-out "\nxxx-status_code=%{http_code}\n" \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '{
"host_name": "myhost123",
"mode": "refresh"
}' \
"$API_URL/domain-types/service_discovery_run/actions/start/invoke"このスクリプトも実行してください。
OMD[mysite]:~$ ./service_discovery.sh
xxx-status_code=302HTTP ステータスコード302 は、サービスディスカバリーのバックグラウンドジョブが初期化されたことを意味します。
保留中の変更を表示する
変更をアクティブにする前に、中間ステップとして、Show all pending changes リクエストで保留中の変更を表示する必要があります。 REST API では、蓄積された変更に加えて、これらの変更をアクティブにするために必要な HTTP ETag (エンティティタグ) も提供されます。 REST API では、オブジェクトの ID またはタイトルを使用してオブジェクトを変更することはありません。 代わりに、生成された ETag を使用して、複数の競合するリクエストによって同じオブジェクトの値が上書きされるのを防ぎます。
ETag は、応答ヘッダーで返されます。
このヘッダーを表示するには、このリクエストのサンプルコードを拡張し、-i オプション (応答ヘッダーを含める) を指定してcurl を呼び出します。
次の例でも、変更された行が再びマークされています。
#!/bin/bash
# NOTE: We recommend all shell users to use the "httpie" examples instead.
# `curl` should not be used for writing large scripts.
# This code is provided for debugging purposes only.
HOST_NAME="myserver"
SITE_NAME="mysite"
PROTO="http" #[http|https]
API_URL="$PROTO://$HOST_NAME/$SITE_NAME/check_mk/api/1.0"
USERNAME="automation"
PASSWORD="theautomationsecret"
curl \
-i \
--request GET \
--write-out "\nxxx-status_code=%{http_code}\n" \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
"$API_URL/domain-types/activation_run/collections/pending_changes"スクリプトの実行後、出力にはまずヘッダー行が表示されます。
OMD[mysite]:~$ ./show_pending_changes.sh
HTTP/1.1 200 OK
Date: Wed, 03 Jul 2024 13:23:26 GMT
...
ETag: "2156db7032754ec778c75123ec12cdd897592b0a574760fa0963a1782c22472c"
...
Content-Type: application/json
{
...
"domainType":"activation_run",
"value":[
{
"id":"8cb85882-cdae-4d43-b5af-362b4c1cb717",
"user_id":"automation",
"action_name":"create-host",
"text":"Created new host myhost123.",
"time":"2024-07-03T13:05:07.466406+00:00"
}
]
}
xxx-status_code=200
わかりやすくするために、ここでは出力を短縮し、重要な行のみを示しています。ETag を含むヘッダー行、ホストを作成するための 1 件の保留中の変更の属性、およびOK の HTTP ステータスコードです。
次の最後のステップで ETag が必要になります。
変更をアクティブにする
最後に、変更をアクティブにする必要があります。 適切なリクエストはActivate pending changes です。
curl コマンドで、ヘッダー行If-Match を変更し、前のセクションで読み込んだ ETag を挿入します。
データセクションで、パラメータsites を変更し、変更をアクティブにするサイトの名前を設定します。
#!/bin/bash
# NOTE: We recommend all shell users to use the "httpie" examples instead.
# `curl` should not be used for writing large scripts.
# This code is provided for debugging purposes only.
HOST_NAME="myserver"
SITE_NAME="mysite"
PROTO="http" #[http|https]
API_URL="$PROTO://$HOST_NAME/$SITE_NAME/check_mk/api/1.0"
USERNAME="automation"
PASSWORD="1234567890"
curl -L \
--write-out "\nxxx-status_code=%{http_code}\n" \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "If-Match: "2156db7032754ec778c75123ec12cdd897592b0a574760fa0963a1782c22472c"" \
--header "Content-Type: application/json" \
--data '{
"force_foreign_changes": false,
"redirect": false,
"sites": [
"mysite"
]
}' \
"$API_URL/domain-types/activation_run/actions/activate-changes/invoke"このスクリプトを実行します。
OMD[mysite]:~$ ./activate_changes.sh
{
"links":[
{
"domainType":"link",
"rel":"self",
"href":"http://myserver/mysite/check_mk/api/1.0/objects/activation_run/eddbef05-438b-4108-9a02-0d010da2b290",
"method":"GET",
"type":"application/json"
},
{
"domainType":"link",
"rel":"urn:com.checkmk:rels/wait-for-completion",
"href":"http://myserver/mysite/check_mk/api/1.0/objects/activation_run/eddbef05-438b-4108-9a02-0d010da2b290/actions/wait-for-completion/invoke",
"method":"GET",
"type":"application/json"
}
],
"domainType":"activation_run",
"id":"eddbef05-438b-4108-9a02-0d010da2b290",
"title":"Activation status: In progress.",
"members":{
},
"extensions":{
"sites":[
"mysite"
],
"is_running":true,
"force_foreign_changes":false,
"time_started":"2024-07-03T13:45:07.031741+00:00",
"changes":[
{
"id":"8cb85882-cdae-4d43-b5af-362b4c1cb717",
"user_id":"automation",
"action_name":"create-host",
"text":"Created new host myhost123.",
"time":"2024-07-03T13:05:07.466406+00:00"
}
]
}
}
xxx-status_code=200
title というテキストが表示されたら、有効化が開始されました。
ここでも、REST API は、links の下に 2 つの有用なフォローアップリクエストを提案します。
この有効化のステータスを照会し、完了を待つためのリクエストです。
3.5. REST API GUI によるリクエストの実行
REST APIGUIを使用すると、API を新しい視点で見ることができます。 この GUI を使用すると、curl コマンドを使用してサーバーにリクエストを送信し、応答を即座に確認することで、ブラウザから API と直接対話することができます。 これを行うには、API GUI の REST API ドキュメントのコード例を使用しないでください。両方のビューは、それぞれの機能に最適化されています。
REST API GUI は、REST API ドキュメントと同じソース(OpenAPI ドキュメント)から生成されているため、API と一致する機能を常に提供します。
API GUI は、Checkmk GUI のナビゲーションバー、メニュー「Help > Developer resources > REST API interactive GUI 」から開きます。 API GUI は、新しいブラウザウィンドウ(またはブラウザのタブ)に表示されます。

以下では、スクリプトを使用せずに、REST API GUI を使用して上記の例(ホストの作成)の最初のリクエストを実行する方法の概要を説明します。
認証: REST API GUI では、[Authorize ] ボタン(最初のエンドポイントフォルダの入力欄の上部右側)をクリックすると、認証情報を入力するためのダイアログボックスが表示されます。 ただし、サイトユーザーとしてログインしている場合は、Cookie 認証により Checkmk ユーザーとして REST API を使用することが認可されているため、このボックスに何も入力する必要はありません。
エンドポイントの選択:Hosts フォルダで、エンドポイントCreate a host を選択し、[Try it out] をクリックします。
パラメーター値を入力してください: Request body で、
host_nameとipaddressの例値を上書きしてください。リクエストを送信します: Execute をクリックします。
応答をチェックします。Responses に、送信された curl コマンドとエンドポイントの URL が最初に表示されます。 次に、Server response に HTTP ステータスコード付きの応答が表示され、Responses に(複数行形式の)REST API 応答が表示されます。
したがって、REST API GUI を使用すると、API の機能をすばやく簡単に試して、入力値の機能や具体的な応答について理解を深めることができます。
3.6. エラー修正
これまでに示したスクリプトによるコマンドの正常な出力とは対照的に、REST API ではエラーは次のように表示されます。
{
"title": "The operation has failed.",
"status": 401,
"detail": "There are changes from other users and foreign changes are not allowed in this API call."
}
xxx-status_code=401エラーに応じて、出力に表示されるパラメータは異なります。
ただし、status にはHTTP ステータスコードが、title にはエラーの原因に関する簡単な説明が常に表示されます。
ほとんどの場合、detail には、その名前が示すとおり、詳細情報が表示されます。
上記の例では、Checkmk に保留中の変更があることがわかりますが、これらは別のユーザーによって開始されたものです。
デフォルトでは、API 経由で変更された変更のみ、API 経由でアクティブ化することができます。
次の例でも、詳細情報には役立つメッセージが表示されています。
{
"title":"Bad Request",
"status":400,
"detail":"These fields have problems: host_name",
"fields":{
"host_name":[
"'my/host123' does not match pattern '^[-0-9a-zA-Z_.]+\\\\Z'."
]
}
}
xxx-status_code=400上記の例の問題は、ホスト名にスラッシュが含まれているため、パラメータ値が有効な値の範囲に準拠していないことです。
もちろん、発生するエラーの数は、ここでご紹介した 2 つよりもはるかに多くなります。 しかし、上記の例から、REST API は通常、出力に原因に関する十分な情報を提供し、分析やトラブルシューティングを開始するための手がかりとなる情報を提供していることがわかります。
4. API のセキュリティ確保
REST API によるアクセス時には、機密データが転送される可能性があり、オートメーションユーザーの認可によっては、Checkmk に大幅な変更が加えられる可能性があるため、このようなアクセスは適切にセキュリティで保護する必要があります。 利用可能なオプションの一部を以下に示します。
HTTPS 経由の Checkmk: API は、Hypertext Transfer Protocol Secure (HTTPS) 経由でのみ使用してください。そうしないと、ユーザー名、パスワード、および設定データがネットワーク上で平文で送信されます。
オートメーションユーザーには、十分な長さのパスワードを割り当ててください。 パスワードは通常、スクリプトにのみ保存されるため、非常に長いパスワードを簡単に割り当てることができます。
API へのリクエストに使用するスクリプトの認可の概念には、特に注意してください。 スクリプトには、設定データ、パスワードなどの機密データが含まれている場合があります。 そのため、認可されたユーザーおよびグループのみがこのスクリプトを読み込めるようにしてください。
5. REST API リクエストの例
この章では、REST API を使用して、よく必要な操作を実行する方法を示す例を紹介します。
この例も、curlコマンドラインプログラムのサンプルコードに基づいています。
ただし、「API の使用」の章の手順とは異なり、ここでは、スクリプトではなく、コマンドラインでcurl コマンドとしてリクエストを実行します。
これにより、ご自身の環境に合わせてカスタマイズした後、すぐに例を試すことができます。
ここでは、コマンドをわかりやすく説明するために、コマンドの実行に絶対に必要なサンプルコードの行のみを表示しています。
API ドキュメントのサンプルコードと同様、この章の例には、Checkmk サーバー上の REST API のベース URL を組み立て、使用するBearer 認証の オートメーションユーザーの認証情報を設定するための変数が含まれています。
| 変数 | 例示値 | 説明 |
|---|---|---|
|
|
Checkmk サーバーの名前 |
|
|
Checkmk サイトの名前 |
|
|
REST API のベース URL |
|
|
オートメーションユーザーの名前 |
|
|
オートメーションユーザーのパスワード |
curl コマンドを発行する前に、次のシェルコマンドを使用して、環境に合わせて変数をカスタマイズすることができます。
user@host:~$ HOST_NAME="myserver"; SITE_NAME="mysite"; API_URL="http://$HOST_NAME/$SITE_NAME/check_mk/api/1.0"; \
USERNAME="automation"; PASSWORD="theautomationsecret";5.1. ホストおよびフォルダ
この章で説明するリクエストは、Hosts およびFolders サブフォルダにある API ドキュメントに記載されています。 API ドキュメントに記載されている各エンドポイントのタイトルは、以下の見出しです。
すべてのフォルダを表示
ここでは、Main フォルダから再帰的に、セットアップ内のすべてのフォルダが、そのフォルダに含まれるホストをリストせずに表示されます。
user@host:~$ curl -G \
--request GET \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--data-urlencode 'parent=~' \
--data-urlencode 'recursive=true' \
--data-urlencode 'show_hosts=false' \
"$API_URL/domain-types/folder_config/collections/all"フォルダ内のすべてのホストを表示
ここでは、Main > Linux サブフォルダ内のホストが要求されます。
user@host:~$ curl \
--request GET \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
"$API_URL/objects/folder_config/~linux/collections/hosts"フォルダを作成
ここでは、Main > LinuxにサブフォルダProduction Hosts が作成されます。ファイルシステムでは、ディレクトリproduction_hosts として作成されます。
これにより、新しいフォルダには、定義済みホストタググループ Criticalityのホストタグ Productive system が割り当てられます。
user@host:~$ curl \
--request POST \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '{
"attributes": {
"tag_criticality": "prod"
},
"name": "production_hosts",
"parent": "~linux",
"title": "Production Hosts"
}' \
"$API_URL/domain-types/folder_config/collections/all"ホストの作成
ここで、Main > Linux > Production Hosts フォルダに、IPアドレス192.168.0.123 およびホストタグUse piggyback data from other hosts if present を持つホストmylinuxserver が作成されます。
user@host:~$ curl \
--request POST \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '{
"attributes": {
"ipaddress": "192.168.0.123",
"tag_piggyback": "auto-piggyback"
},
"folder": "~linux~production_hosts",
"host_name": "mylinuxserver"
}' \
"$API_URL/domain-types/host_config/collections/all"ホストを表示
ホストを表示すると、そのホストに割り当てられている属性のリストが表示されます。 さらに、ホストを変更するために必要な HTTP ETag (エンティティタグ) も表示されます。 ETag の詳細については、「保留中の変更を表示」セクションをご覧ください。
ETag は応答ヘッダーで返されます。
このヘッダーを表示するには、-v オプション (詳細表示) を指定してcurl を呼び出します。
ここでは、ホストmylinuxserver が照会され、応答の中から ETag を含む行のみが表示されます。
user@host:~$ curl -vG \
--request GET \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
"$API_URL/objects/host_config/mylinuxserver"
...
< ETag: "57db3792f23bd81ca7447ba4885fa2865d0c78aed4753229b29e179e539da48b"
...ホストを更新する
変更を行う前に、前のセクション「ホストの表示」で説明したように、そのホストの ETag を取得します。
次に、If-Match のリクエストヘッダーに ETag を入力します。
ここでは、ホストの作成時に指定されたPiggyback グループからのホストタグが削除され、それを置き換えるために定義済みタグAPI integrations if configured, else Checkmk agent が指定されます。
user@host:~$ curl \
--request PUT \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "If-Match: "57db3792f23bd81ca7447ba4885fa2865d0c78aed4753229b29e179e539da48b"" \
--header "Content-Type: application/json" \
--data '{
"remove_attributes": [
"tag_piggyback"
],
"update_attributes": {
"tag_agent": "cmk-agent"
}
}' \
"$API_URL/objects/host_config/mylinuxserver"ホストでサービスディスカバリーを実行する
サービスディスカバリーが実際に期待されるサービスを確実に提供するように、Linux および Windows ホストでは、まずそれぞれの監視エージェントをインストールして登録する必要があります。
ここでは、Checkmk GUI の「Full service scan 」ボタンに対応する「refresh 」オプションを使用して、ホストmylinuxserver に対してサービスディスカバリーを実行します。
user@host:~$ curl \
--request POST \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '{
"host_name": "mylinuxserver",
"mode": "refresh"
}' \
"$API_URL/domain-types/service_discovery_run/actions/start/invoke"ホストの一括作成
ここでは、Main > Linux > Production Hosts フォルダに 2 つのホストが作成されます。1 つ目のホストには IP アドレスのみ、2 つ目のホストには IPアドレスに加えて親ホストと2つのラベルが指定されています。
user@host:~$ curl \
--request POST \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '{
"entries": [
{
"attributes": {
"ipaddress": "192.168.0.130"
},
"folder": "~linux~production_hosts",
"host_name": "mylinuxserver02"
},
{
"attributes": {
"ipaddress": "192.168.0.131",
"parents": [ "router01" ],
"labels": {
"color": "blue-metallic",
"admin": "Fozzie Bear"
}
},
"folder": "~linux~production_hosts",
"host_name": "mylinuxserver03"
}
]
}' \
"$API_URL/domain-types/host_config/actions/bulk-create/invoke"保留中の変更をアクティブにする
ホストの名前変更という複雑な操作を行う前に、その設定環境に蓄積されているすべての変更をアクティブにする必要があります。
ここでは、サイトmysite の変更を 1 つの操作でまとめてアクティブにしています。
user@host:~$ curl \
--request POST \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '{
"force_foreign_changes": false,
"redirect": false,
"sites": [
"mysite"
]
}' \
"$API_URL/domain-types/activation_run/actions/activate-changes/invoke"ホストの名前を変更する
新しい名前もホストを変更します。
したがって、まず、ホストの現在の ETag を、ホストの表示セクションで説明したように、mylinuxserver から取得し、If-Match のリクエストヘッダーに入力します。
ここでは、ホストの名前がmylinuxserver01 に変更されています。
user@host:~$ curl \
--request PUT \
--header "Authorization: Bearer $USERNAME $PASSWORD" \
--header "Accept: application/json" \
--header "If-Match: "a200832df1b3c5ebe8f30809177630abbdcf8f7cbd9d0f69bd9f229b359f4d00"" \
--header "Content-Type: application/json" \
--data '{
"new_name": "mylinuxserver01"
}' \
"$API_URL/objects/host_config/mylinuxserver/actions/rename/invoke"