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 の最も重要なインターフェースです。 これは、監視対象のすべての ホストおよびサービスのデータ(ライブデータを含む)を最も高速で取得する方法です。たとえば、概要のデータは このインターフェースから直接取得されます。これは RAM から直接読み込まれるため、ハードドライブへのアクセスが遅くなることを回避し、システムに過度の負荷をかけることなく 監視に迅速にアクセスすることができます。

データを構造化するために、このデータはテーブルと列に整理されています。 たとえば、hosts テーブルには、namestate 、およびその他の多数の列が含まれています。hosts テーブルの各行は ホストを表し、services テーブルはサービスを表します。 このようにして、データを簡単に検索および取得することができます。

この記事は、このインターフェースを独自のクエリ、 拡張機能、およびカスタマイズに使用する際に役立つはずです。インスタンスユーザーとして、コピー& ペーストを使用して、この記事で紹介したすべてのクエリおよびコマンドを直接テストすることができます。

2. ライブステータスクエリ言語 (LQL)

2.1. シェルでの LQL の使用

ライブステータスへのアクセスは、Unix ソケットを使用して ライブステータスクエリ言語 (LQL) によって行われます。その構文は HTTP に基づいています。

コマンドラインから、インターフェースにアクセスする方法はいくつかあります。 その 1 つは、printf およびunixcat コマンドを使用して ソケットに指示を送信する方法です。unixcat ツールは、インスタンスユーザー用に Checkmk にすでに含まれています。重要:ソケットへの入力は 大文字と小文字が区別されるため、常に次の点に注意してください。

OMD[mysite]:~$ printf "GET hosts\nColumns: name\n" | unixcat ~/tmp/run/live

インターフェースは、すべてのコマンドとヘッダーを別々の行で入力することを期待しています。 このような改行は、\n でマークすることができます。上記のコマンドの代わりに、lq スクリプトコマンドを使用することもできます。このコマンドを使用すると、入力時に一部のフィールドが自動補完されるため、 作業が少し楽になります。

OMD[mysite]:~$ lq "GET hosts\nColumns: name"

または、対話型入力ストリームを開始し、コマンドの後に ヘッダーを入力することもできます。空白行を入力すると、そのコマンドがヘッダーとともに実行され 、さらに次の行を入力すると、ソケットへのアクセスが終了します。この例では 、空白行の前の部分はすべてコマンドに属し、 1 行目と 2 行目の空白行の間の部分は応答です。

OMD[mysite]:~$ lq
GET hosts
Columns: name

myserver123
myserver124
myserver125

OMD[mysite]:~$

以下の例は、常にlq コマンドで実行されます。クエリが短い場合は直接 フォームで、長いクエリの場合はエントリストリームとして実行されます。

LQL コマンド

最初の例で、2 つのコマンドのうち最初のコマンドを既にご覧になりました。GET を使用すると、使用可能なすべてのテーブルを呼び出すことができます。コマンドリファレンス には、使用可能なすべてのテーブルの説明付きリストが掲載されています。 また、この記事には、ライブステータスの使用に関する一般的な 説明も記載されています。

COMMAND を使用すると、ダウンタイムの設定や通知の完全無効化など、コアに直接コマンドを発行することができます。 使用可能なすべてのコマンドのリストは、コマンド リファレンスのコマンド にあります。

LQLヘッダー

各 GET コマンドには、クエリの結果を制限したり、テーブルの特定の列のみを出力したりなど、さまざまなヘッダーを挿入することができます。 最も重要な 2 つのヘッダーは次のとおりです。 Header

ヘッダー 説明

Columns

クエリから指定した列のみが返されます。

フィルター

特定の条件を満たすエントリのみが生成されます。

すべてのヘッダーのリストとそれぞれの簡単な説明は、こちらでご覧いただけます。

利用可能な列とテーブルを表示

すべてのテーブルとその列を覚えておくことは不可能であり 、このハンドブック(オンライン版の参照情報を含む)にアクセスできない場合もあります 。ただし、必要な情報を提供するクエリをすばやく作成することは可能です。 使用可能なすべてのテーブルのリストを取得するには 、次のクエリを送信し、出力から重複する行をsort で削除してください。出力では、最初の 4 行が例として表示されます。

OMD[mysite]:~$ lq "GET columns\nColumns: table" | sort -u
columns
commands
comments
contactgroups

テーブル内のすべての列をクエリするには、もちろんそれらを指定する必要があります。hosts を目的のテーブルに置き換えてください。ここでも、出力の最初の 4 行は 例として表示されます。

OMD[mysite]:~$ lq "GET columns\nFilter: table = hosts\nColumns: name"
accept_passive_checks
acknowledged
acknowledgement_type
action_url

2.2. Python で LQL を使用する

Checkmk は Python を多用しているため、この言語のスクリプトが実用的です。 以下のスクリプトは、ライブステータスソケットへのアクセス用の基礎として使用できます。

live_example.py
#!/usr/bin/env python
# Sample program for accessing Livestatus from Python

import json, os, socket

# for local site only: file path to socket
address = "%s/tmp/run/live" % os.getenv("OMD_ROOT")
# for local/remote sites: TCP address/port for Livestatus socket
# address = ("localhost", 6557)

# connect to Livestatus
family = socket.AF_INET if type(address) == tuple else socket.AF_UNIX
sock = socket.socket(family, socket.SOCK_STREAM)
sock.connect(address)

# send our request and let Livestatus know we're done
sock.sendall(str.encode("GET status\nOutputFormat: json\n"))
sock.shutdown(socket.SHUT_WR)

# receive the reply as a JSON string
chunks = []
while len(chunks) == 0 or chunks[-1] != "":
    data = sock.recv(4096)
    chunks.append(str(data.decode("utf-8")))
sock.close()
reply = "".join(chunks)

# print the parsed reply
print(json.loads(reply))

2.3. ライブステータス API の使用

Checkmk は、Python、Perl、C++ プログラミング言語用の API を提供しており 、ライブステータスへのアクセスを簡略化しています。各言語の 使用方法を説明するサンプルコードが用意されています。これらのサンプルのパスは 「ファイルとディレクトリ」の章に記載されています。

3. シンプルクエリ

3.1. 列クエリ (列)

これまでの例では、すべてのホストのすべての情報をクエリしていました。 しかし、実際には、特定の列のみが必要になる場合が多いでしょう。 すでに述べたColumns ヘッダーを使用すると、出力をこの列に限定することができます。 個々の列名は、単純な空白文字で区切られます。

OMD[mysite]:~$ lq "GET hosts\nColumns: name address"
myserver123;192.168.0.42
myserver234;192.168.0.73

ご覧のとおり、1 行内で個々の値はセミコロンで区切られています。

重要:これらのヘッダーを使用する場合、出力からヘッダーが省略されます。 ColumnHeadersヘッダーを使用することで、出力にヘッダーを再挿入できます。

3.2. 簡単なフィルターの設定

クエリを特定の行に制限するには、指定した内容に基づいて列をフィルタリングすることができます。 特定のステータスのサービスのみを検索する場合は、フィルタを使用して実現できます。 例

OMD[mysite]:~$ lq "GET services\nColumns: host_name description state\nFilter: state = 2"
myserver123;Filesystem /;2
myserver234;ORA MYINST Processes;2

この例では、CRIT ステータスのすべてのサービスが検索され 、ホスト名、サービス内容、およびステータスが出力されます。 このようなフィルタは、もちろん組み合わせることもでき、CRIT ステータスでまだ承認されていないサービスに制限することもできます。

OMD[mysite]:~$ lq "GET services\nColumns: host_name description state\nFilter: state = 2\nFilter: acknowledged = 0"
myserver234;Filesystem /;2

Columns にリストされていない列でもフィルタリングできることがわかります。

オペレーターと正規表現

これまで、一致する数値のみフィルタリングしてきました。 クエリの中間結果は、数値による「より小さい」検索や、文字列による検索も行うことができます。 使用可能なオペレーターは、コマンドリファレンスの「オペレーター」 章に記載されています。 これにより、たとえば、列で正規表現をフィルタリングすることができます。 適切なオペレーターを使用すると、列をさまざまな方法で検索することができます。

OMD[mysite]:~$ lq "GET services\nColumns: host_name description state\nFilter: description ~~ exchange database|availability"
myserver123;Exchange Database myinst1;1
myserver123;Exchange Availability Service;0
myserver234;Exchange Database myinst3;0

適切なオペレーターを使用すると、さまざまな方法で列を検索することができます。 ライブステータスは、別段の定義がない限り、このような式を「列内のどこにでも出現する」と解釈します。 行の開始は、たとえば「^ 」文字で、 行の終了は「$ 」文字で指定します。 Checkmk の正規表現で使用できる特殊文字の完全なリストは、 正規表現に関する記事をご覧ください。 3.3. 出力の並べ替え (OrderBy)

3.3. 出力の並べ替え (OrderBy)

ヘッダー「OrderBy 」を使用すると、任意の列の内容、あるいは辞書キーの値に応じて出力を並べ替えることができます。 これにより、たとえば、すべてのホストをアルファベット順のリストを作成することができます。

OMD[mysite]:~$ lq "GET hosts\nColumns: name\nOrderBy: name"
ahost
anotherhost
yetanotherhost

暗黙的に、出力は期待どおり昇順(asc )でソートされます。 ただし、desc` を指定することで、希望するソートを明示的に指定したり、ソートを逆順に変更したりすることもできます。

OMD[mysite]:~$ lq "GET hosts\nColumns: name\nOrderBy: name desc"
yetanotherhost
anotherhost
ahost

クエリを少し長くして、たとえばパフォーマンスデータでソートすると、興味深いランキングリストを作成できます。 次の例では、ホストがアップタイムの降順で表示されています。

OMD[mysite]:~$  lq "GET services\nColumns: host_name performance_data\nFilter: description = Uptime\nOrderBy: performance_data.uptime desc"
anotherhost;uptime|249531.1
yetanotherhost;uptime|149142.3
ahost;uptime|48959

4. 複合クエリ

4.1. リストのフィルタ

テーブルの一部の列は、単一の値ではなく、その値のリスト全体を返します。 このようなリストを効果的に検索できるように、これらの場合、 オペレーターには別の機能があります。オペレーターの完全なリストは、 リストのオペレーターを参照してください。 たとえば、オペレーター「>= 」には「contains」という機能があります。これを使用すると、 たとえば、特定の連絡先を検索することができます。

OMD[mysite]:~$ lq "GET hosts\nColumns: name address contacts\nFilter: contacts >= hhirsch"
myserver123;192.168.0.42;hhirsch,hhirsch,mfrisch
myserver234;192.168.0.73;hhirsch,wherrndorf

上記の例のように、連絡先はコンマで区切られてcontacts 列にリストされます。これにより、別の列の先頭ではないことが明確に区別できます。 等価演算子の特別な機能は、リストが空であるかどうかをチェックすることです。 4.2. フィルタの組み合わせ

OMD[mysite]:~$ lq "GET hosts\nColumns: name contacts\nFilter: contacts ="
myserver345;
myserver456;

4.2. フィルターの組み合わせ

いくつかのフィルタは、すでに組み合わせています。直感的には 、データが表示されるためには、すべてのフィルタを通過しなければならないと思われるでしょう。 フィルタは、論理演算子and で連結されます。 特定のフィルタを論理和でリンクするには、フィルタ 文字列コードの最後にor:の後に整数を入力します。カウンターは、 最後の行のうち、or で組み合わせることができる行の数を指定します。この方法により、グループ を必要に応じて形成および組み合わせることができます。以下は簡単な例です。 ここでは、2 つのフィルタが組み合わされ、ステータスがWARN またはUNKNOWNのすべてのサービスが表示されます。

OMD[mysite]:~$ lq
GET services
Columns: host_name description state
Filter: state = 1
Filter: state = 3
Or: 2

myserver123;Log /var/log/messages;1
myserver123;Interface 3;1
myserver234;Bonding Interface SAN;3

OMD[mysite]:~$

組み合わせの結果を否定したり、グループをさらに 他のグループと組み合わせることもできます。この例では、ステータスがOK でなく、説明がFilesystem で始まる、または UNKNOWN 以外のステータスを持つすべてのサービスが表示されます。

OMD[mysite]:~$ lq
GET services
Columns: host_name description state
Filter: state = 3
Filter: description ~ Filesystem
And: 2
Filter: state = 0
Or: 2
Negate:

myserver123;Log /var/log/messages;1
myserver123;Interface 3;1
myserver234;Filesystem /media;2
myserver234;Filesystem /home;2

4.3. 出力形式の指定

出力フォーマットは 2 つの方法で指定できます。 1 つの方法は、標準出力で使用される区切り文字を再定義することです。 もう 1 つの方法は、Python または JSON フォーマットに準拠して出力することです。

csvのカスタマイズ

すでに説明したように、標準出力csv (小文字!) を正確にカスタマイズし、個々のエレメントを どのように区切るかを定義することができます。 Checkmk は、データを構造化するために 4 種類のセパレータを認識します。 コロンに続いて、フィルタが次のように構造化されるように、適切な標準 ASCII 値をコード化してください。 これらのセパレータは、次の機能を持っています。

Separators: 10 59 44 124

これらの区切り文字は次の機能を持ちます:

  1. データセットの区切り文字:10 (改行)

  2. データセット内の列の区切り文字:59 (セミコロン)

  3. リスト内のエレメントの区切り文字:44 (コンマ)

  4. サービスリストのエレメントの区切り文字:124 (縦棒)

これらの値はそれぞれ、出力の構造を自由に設定するために選択できます。 次の例では、データセット内の各列は セミコロン (59) ではなくタブ (9) で区切られています:

OMD[mysite]:~$ lq
GET services
Columns: host_name description state
Filter: description ~ Filesystem
Separators: 10 9 44 124

myserver123     Filesystem /opt     0
myserver123     Filesystem /var/some/path       1
myserver123     Filesystem /home        0

重要: セパレーターの順序は固定されており、変更できません。

出力形式の変更

csv で出力するだけでなく、Livestatus は 他の形式でも出力することができます。これらの形式には、高水準のプログラミング言語で解析しやすいという利点があります。 したがって、出力は次の形式でエンコードすることができます。

フォーマット 説明

Python

2.x 互換のリストとして出力を生成します。テキストは Unicode でフォーマットされます。

python3

同様に、リストとして出力を生成し、その際にデータ型の変更 (テキストの Unicode への自動変換など) を考慮します。

json

出力は同様にリストとして生成されますが、json 互換のフォーマットのみが使用されます。

CSV

RFC-4180 に準拠した形式で出力をフォーマットします。

csv

csv のカスタマイズをご覧ください。これは、他に指定がない場合の標準フォーマットであり、公式の CSV フォーマットに基づいています。

CSV Format を、出力形式が指定されていない場合に使用される Livestatus のcsv-output と混同しないでください。 したがって、大文字と小文字の正しいコーディングは絶対に必要です。 カスタマイズするには、最後にSeparator の代わりにOutputFormat を指定してください。

OMD[mysite]:~$ lq
GET services
Columns: host_name description state
Filter: description ~ Filesystem
OutputFormat: json

[["myserver123","Filesystem /opt",0]
["myserver123","Filesystem /var/some/path",1]
["myserver123","Filesystem /home",0]]

5. 統計情報の取得 (Stats)

5.1. 概要

単一のサービスまたはサービスのグループの状態には興味がない場合もあります。 はるかに重要なのは、現在のWARN 状態にあるサービスの数、または監視されているデータベースの数です。 ライブステータスは、Stats を使用して統計情報を生成および出力することができます。 5.2. 数値

5.2. 数値

Overview は、ホスト、 サービス、およびイベントの統計情報を Livestatus から取得し、Checkmk のインターフェースに表示することでデータを受け取ります。 Livestatus に直接アクセスすることで、独自の要約を作成することができます。

OMD[mysite]:~$ lq
GET services
Stats: state = 0
Stats: state = 1
Stats: state = 2
Stats: state = 3

34506;124;54;20

なお、このような統計情報はすべてのフィルターと組み合わせることができます。

5.3. グループ化

統計は、and/or と組み合わせることもできます。その場合、ヘッダーはStatsAnd またはStatsOr と呼ばれます。出力を逆にする場合は、StatsNegate を使用してください。 この例では、ホストの総数 (最初のStats )が出力され、さらに、stale とマークされ、かつダウンタイムにリストされていないホストの 数も出力されます (Stats 2 と 3 は論理「AND」でリンクされています)。

OMD[mysite]:~$ lq
GET hosts
Stats: state >= 0
Stats: staleness >= 3
Stats: scheduled_downtime_depth = 0
StatsAnd: 2

734;23

フィルタと統計の結果を組み合わせるさまざまなオプションについて、混乱しないでください。 条件を満たすすべてのホストは、 ヘッダーを使用して出力されますが、統計情報を含む出力は xml-ph-0000@deepl.internal フィルタが適用される頻度の合計になります。Filterヘッダーを使用して出力されます。統計では、出力はStats フィルターが適用される頻度の合計になります。

5.4. 最小値、最大値、平均値など

値に対して計算を行い、たとえば 平均値や最大値を出力することもできます。使用可能なすべてのオペレーターの完全なリストは こちらをご覧ください。

次の例では、ホストのチェックプラグインがステータスの計算に要した平均、最小、 最大時間をリストで出力します。

OMD[mysite]:~$ lq
GET services
Filter: host_name = myserver123
Stats: avg execution_time
Stats: max execution_time
Stats: min execution_time

0.0107628;0.452087;0.008593

メトリックを使用した計算は、やや特殊な方法でハンドルされます。 ここでも、Stats ヘッダーのすべての関数を使用できます。 ただし、これらはサービスのすべてのメトリックに 個別に適用されます。 たとえば、次の例では、ホストグループの CPU 使用率のメトリックが 合計されます。

OMD[mysite]:~$ lq
GET services
Filter: description ~ CPU utilization
Filter: host_groups >= cluster_a
Stats: sum perf_data

guest=0.000000 steal=0.000000 system=34.515000 user=98.209000 wait=23.008000

6. 出力の制限 (Limit)

出力の行数を意図的に制限することができます。これは、 たとえば、ライブステータスクエリに対して何らかの応答があるかどうかだけを確認したいが、 複数ページにわたる出力を避けたい場合などに便利です。

OMD[mysite]:~$  lq "GET hosts\nColumns: name\nLimit: 3"
myserver123
myserver234
myserver345

この制限は、他のヘッダーと組み合わせた場合にも機能することに注意してください。 たとえば、Stat で、UP ステータスを持つホストの数をカウントし、 出力を10に制限すると、最初の10台のホストだけがアカウントされます。

7. 時間制限 (Timelimit)

出力する行数を制限できるだけでなく、クエリの実行を許可する最大経過時間も制限できます。 このオプションを使用すると、何らかの理由でクエリがハングアップした場合、ライブステータスクエリが接続を永久にブロックすることを防ぐことができます。 時間制限は、クエリの処理を許可する最大時間を秒単位で指定します。

OMD[mysite]:~$ lq "GET hosts\nTimelimit: 1"

8. 列ヘッダーの有効化 (ColumnHeaders)

ColumnHeaders を使用すると、列の名前を出力に追加することができます。 通常、これらの名前は、さらなる処理を簡単にするために非表示になっています。

OMD[mysite]:~$  lq "GET hosts\nColumns name address groups\nColumnHeaders: on"
name;address;groups
myserver123;192.168.0.42;cluster_a,headnode
myserver234;192.168.0.43;cluster_a
myserver345;192.168.0.44;cluster_a

9. 認可 (AuthUser)

ライブステータスに基づいてスクリプトを利用可能にする場合、ユーザーは おそらく、認可されたデータのみを表示すべきでしょう。 Checkmk は、この機能のためにAuthUser ヘッダーを提供しています。 ただし、このヘッダーは、以下のテーブルでは使用できません。

  • columns

  • commands

  • contacts

  • contactgroups

  • eventconsolerules

  • eventconsolestatus

  • status

  • timeperiods

一方、hostsまたはservices テーブルにアクセスするすべてのテーブルでは、このヘッダーを使用できます。ユーザーがどれを認可されているかは、 ユーザーの連絡先グループによって異なります。

このようにして、連絡先も閲覧が許可されているデータのみがクエリの出力結果として表示されます。 ここで、strictlooseの 許可設定の違いに注意してください。

OMD[mysite]:~$ lq "GET services\nColumns: host_name description contacts\nAuthUser: hhirsch"
myserver123;Uptime;hhirsch
myserver123;TCP Connections;hhirsch
myserver123;CPU utilization;hhrisch,kkleber
myserver123;File /etc/resolv.conf;hhirsch
myserver123;Kernel Context Switches;hhrisch,kkleber
myserver123;File /etc/passwd;hhirsch
myserver123;Filesystem /home;hhirsch
myserver123;Kernel Major Page Faults;hhrisch
myserver123;Kernel Process Creations;hhirsch
myserver123;CPU load;hhrisch,kkleber

10. タイムディレイ(待機)

Wait ヘッダーを使用すると、データの要件が満たされているかどうかを知らなくても、特定のデータセットのクエリを作成できます。 これは、たとえば、特定のエラー状況の比較データが必要であるが、システムに継続的な不要な負荷をかけたくない場合に便利です。 そのため、情報は実際に必要な場合にのみ取得されます。 Wait ヘッダーの完全なリストは、こちらをご覧ください。

Wait ヘッダーの完全なリストは、こちらでご覧いただけます。

次の例では、ESXi サーバーのDisk IO SUMMARY サービスがCPU load サービスの状態が特定のVMCRIT に変更されたら出力されます。WaitTimeout ヘッダーを使用すると、10000ミリ秒経過しても条件が満たされない場合にクエリが実行されます。 これにより、ライブステータス接続が長時間ブロックされるのを防ぐことができます。

OMD[mysite]:~$ lq
GET services
WaitObject: myvmserver CPU load
WaitCondition: state = 2
WaitTrigger: state
WaitTimeout: 10000
Filter: host_name = myesxserver
Filter: description = Disk IO SUMMARY
Columns: host_name description plugin_output

myesxserver;Disk IO SUMMARY;OK - Read: 48.00 kB/s, Write: 454.54 MB/s, Latency: 1.00 ms

さらに、これをコマンドと組み合わせることもできます。 コマンドを発行し、結果が利用可能になり次第、それを取得することができます。 次の例では、サービスから現在のデータをクエリして表示します。 このためには、まずコマンドを送信し、次にクエリを発行します。 これにより、Check_MK サービスからのデータが特定の時点のものよりも新しいかどうかがチェックされます。 前提条件が満たされると、Memory サービスのステータスが出力されます。

OMD[mysite]:~$ lq "COMMAND [$(date +%s)] SCHEDULE_FORCED_SVC_CHECK;myserver;Check_MK;$(date
+%s)"
OMD[mysite]:~$ lq
GET services
WaitObject: myserver Check_MK
WaitCondition: last_check >= 1517914646
WaitTrigger: check
Filter: host_name = myserver
Filter: description = Memory
Columns: host_name description state

myserver;Memory;0

重要:この例で使用されているlast_checkのタイムスタンプは 、必ず適切なものに置き換える必要があります。そうしないと、 条件が常に満たされ、出力が即座に生成されてしまいます。

11. タイムゾーン (Localtime)

多くの監視環境では、グローバルレベルでホストおよびサービスを照会します。 このような場合、異なるタイムゾーンで動作する分散監視 インスタンスがすぐに発生してしまう可能性があります。Checkmk は、タイムゾーンに依存しない Unix 時間を使用しているため、この問題は発生しません。

それでもサーバーが誤ったタイムゾーンに割り当てられている場合Localtime ヘッダーを使用してこの差を補正することができます。 クエリにも現在の時刻を提供してください。Checkmk は自動的に 30 分に切り上げて、その差を調整します。 クエリを直接呼び出す場合は、時刻を自動的に提供することができます。

OMD[mysite]:~$ lq "GET hosts\nColumns: name last_check\nFilter: name = myserver123\nLocaltime: $(date +%s)"
myserver123;1511173526

入力ストリームを使用する場合は、date +%s の結果を提供してください:

OMD[mysite]:~$ lq
GET hosts
Columns: name last_check
Filter: name = myserver123
Localtime: 1511173390

myserver123;Memory;1511173526

12. ステータスコード (ResponseHeader)

API を記述する場合、出力をより適切に処理するために、応答としてステータスコードを受け取りたいと思うでしょう。 ステータスコードは、API ヘッダーの StatusCode フィールドに記述します。 ResponseHeader ヘッダーは、off (標準) およびfixed16 の値をサポートしており、これらを使用して、 応答の最初の行に正確に16バイトの長さのステータスメッセージを提供します。 エラーが発生した場合、後続の行には、 エラーコードの詳細な説明が含まれます。したがって、これらは、 クエリの結果でエラーを探す場合にも非常に役立ちます。

1 行目のステータスレポートは、以下の情報を組み合わせたものです。

  • バイト 1-3: ステータスコード。可能なコードの完全な一覧はここにあります。

  • バイト4: 単純な空白文字(ASCII文字: 32)

  • バイト 5~15:実際の応答の長さを整数で表します。不要なバイトは空白文字で埋められます。

  • バイト16: 改行コード(ASCII文字: 10)

以下の例では、フィルターが実際には列名で誤ってコーディングされている 不具合のあるクエリを実行します。

OMD[mysite]:~$ lq "GET hosts\nName: myserver123\nResponseHeader: fixed16"
400          33
Columns: undefined request header

重要:エラー状況では、出力形式は 常にテキスト形式のエラーメッセージになります。 これは、お客様が行った変更に関係なく適用されます。

13. 接続を維持する (KeepAlive)

特に、ネットワーク経由でライブステータス接続を確立するスクリプトでは 、接続を繰り返し確立する際に発生するオーバーヘッドを節約するために 、チャンネルを開いたままにしておきたい場合があります。 これは、KeepAlive ヘッダーを使用することで実現でき、これにより チャンネルを予約することができます。 ちなみに、コマンドの実行後、ライブステータス接続は 常に開いたままになります。このために追加のヘッダーを入力する必要はありません。

重要:接続中は、そのチャンネルは他のプロセスに対してブロックされます。 そのため、他に使用可能な接続がない場合、問題になる可能性があります。 他のプロセスは、接続が空きになるまで待つ必要があります。 したがって、標準設定では、Checkmk は 20 個の接続を待機状態にします。 必要に応じて、Setup > General > Global Settings > Monitoring Core > Maximum concurrent Livestatus connections で、これらの接続の最大数を増やしてください。 を常に組み合わせる

KeepAlive は必ず、 Response headerと必ず組み合わせてください。 これにより、個々の応答を正しく区別できます:

OMD[mysite]:~$ lq
GET hosts
ResponseHeader: fixed16
Columns: name
KeepAlive: on

200          33
myserver123
myserver234
myserver345
GET services
ResponseHeader: fixed16
Columns: host_name description last_check
Filter: description = Memory

200          58
myserver123;Memory;1511261122
myserver234;Memory;1511261183

最初の応答と 2 番目の要求の間に空行がないことを確認してください。 クエリからヘッダーが省略されると、次の出力の後に、接続は 通常どおり、空白行によって閉じられます。

14. ログの取得

14.1. 概要

ライブステータスのlog テーブルを使用すると、コアの監視ヒストリーに直接アクセスできます。 そのため、LQL を使用して特定のイベントを簡単にフィルタリングすることができます。 たとえば、可用性テーブルは、これらのテーブルを使用して生成されます。 概要を明確にし、クエリを主題ごとに制限するために、次のログクラスにアクセスできます。

クラス 説明

0

他のクラスでカバーされていないすべてのメッセージ

1

ホストおよびサービスのアラート

2

重要なプログラムイベント

3

通知

4

パッシブチェック

5

外部コマンド

6

初期または現在のステータスエントリ (ログのローテーション後など)

7

プログラムのステータスの変更

これらのログクラスを使用するだけで、 表示するエントリのタイプを非常にうまく制限することができます。 クエリで考慮される時間範囲もさらに制限されます。 これは、そうしないと、インスタンスの完全なヒストリーが検索され 、情報の洪水によりシステムに論理的に大きなブレーキがかかる可能性があるため、重要です。

出力の制限としてさらに有効なのは、エントリに表示する (Columns) です。 以下の例では、過去 1 時間に 記録されたすべての通知を検索します。

OMD[mysite]:~$ lq "GET log\nFilter: class = 3\nFilter: time >= $$(date +%s)-3600\nColumns: host_name service_description time state"
myserver123;Memory;1511343365;0
myserver234;CPU load;1511343360;3
myserver123;Memory;1511343338;2
myserver234;CPU load;1511342512;0

重要:エントリストリームの対話モードでは、 例で使用されている変数は使用できないことを確認し、 クエリは常に時間範囲に制限してください。

14.2. 監視ヒストリーの設定

ファイルのローテーションおよび最大サイズを変更することができます。 さらに、Checkmk が中断する前にファイルから読み込む行数を指定することもできます。 これらはすべて、インスタンスの構成に応じて、クエリのパフォーマンスに影響を与える可能性があります。 以下の 3 つのパラメータを使用できます。 これらのパラメータは、Setup > General > Global Settings > Monitoring Core で確認およびカスタマイズできます。

名前 説明

History log rotation: Regular interval of rotations

ここでは、新しいファイルで履歴を継続する時間範囲を定義できます。

History log rotation: Rotate by size (Limit of the size)

時間範囲とは無関係に、ここでファイルの最大サイズを定義します。サイズは、可能な読み取り速度と可能な IO の妥協点となります。

Maximum number of parsed lines per log file

指定された行数が読み込まれると、ファイルの読み込みが停止します。これにより、何らかの理由でファイルが非常に大きくなった場合でもタイムアウトを回避できます。

15. 可用性のチェック

statehist テーブルを使用すると、ホストおよびサービスの可用性に関する生データを照会 することができ、インターフェースの可用性表示で使用されているすべての情報にアクセス することができます。 必ず時間範囲を入力してください。入力しないと、利用可能なすべてのログが検索され 、システムに大きな負荷がかかる可能性があります。 また、以下の追加の仕様も適用されます。

  • ホスト/サービスが特定のステータスであった時間範囲は、絶対時間、Unix 時間、および相対時間、および照会した時間範囲に対する割合として出力することができます。

  • ホスト/サービスが監視されていなかった期間、ステータスは-1 となります。

ホスト/サービスが監視されていたかどうか、いつ、どのくらいの期間監視されていたかを確認することは 、Checkmk では初期ステータスのログ記録によって可能になっています。 これにより、特定の時間にどのステータスがあったかを確認できるだけでなく 、その時点で実際に監視されていたかどうかをさかのぼって確認することもできます。 重要:このログ記録は、Nagios-Core でも有効になっています。 ただし、ここでは無効にすることができます。

~/etc/nagios/nagios.d/logging.cfg
log_initial_states=0

以下の例では、割り当ての割合のクエリと 特定のステータスの絶対時間がどのように表示されるかを確認できます。 時間範囲として過去 24 時間が指定され、クエリは 特定のホストのサービスの可用性に限定されています。

OMD[mysite]:~$ lq
GET statehist
Columns: host_name service_description
Filter: time >= 1511421739
Filter: time < 1511436139
Filter: host_name = myserver123
Filter: service_description = Memory
Stats: sum duration_ok
Stats: sum duration_warning
Stats: sum duration_critical
Stats: sum duration_part_ok
Stats: sum duration_part_warning
Stats: sum duration_part_critical

myserver123;Memory;893;0;9299;0.0620139;0;0.645764

利用可能な列の完全なリストを取得する方法については、 コマンドリファレンスで詳しく説明しています。

16. ライブステータスの変数

Checkmk インターフェースのさまざまな場所で、変数を使用して コンテキストベースの割り当てを行うことができます。このデータの一部は、 ライブステータスからも取得できます。これらの変数は解決する必要があるため、 これらの列はテーブルに 2 回表示されます。 1 回目はリテラルエントリとして、2 回目は変数が 適切な値に置き換えられた形で表示されます。 その例として、notes_url 列があります。この列は、 変数を含む URL を出力します:

OMD[mysite]:~$ lq "GET hosts\nColumns: name notes_url"
myserver123;https://mymonitoring/heute/wiki/doku.php?id=hosts:$HOSTNAME$

ただし、代わりにnote_url_expanded 列をクエリすると、 マクロの実際の値が表示されます。

OMD[mysite]:~$ lq "GET hosts\nColumns: name notes_url_expanded"
myserver123;https://mymonitoring/heute/wiki/doku.php?id=hosts:myserver123

17. ネットワーク経由でライブステータスを使用する

17.1. TCP/IP による接続

ネットワーク経由でライブステータスにアクセスするには、ライブステータスプロセスの Unix ソケットを TCP ポートに接続します。 これにより、リモートマシンでスクリプトを実行し、データを処理すべき場所から直接収集することができます。

サイトがオフになっている場合、TCP 経由のアクセスは、次のコマンドで有効にできます。omd コマンド:

OMD[mysite]:~$ omd config set LIVESTATUS_TCP on

サイトが起動すると、通常、TCP 経由のライブステータスはデフォルトのポート 6557 でアクティブになります。 TCP 経由のライブステータスを使用するサイトが複数ある Checkmk サーバーでは、次に高い未使用のポートが選択されます。

ポートや認可された IP アドレスなどのすべての設定は、omd config で設定できます。 または、これらの設定はセットアップで行うこともできます。 Checkmk では、ライブステータス通信の SSL 暗号化はデフォルトで有効になっています。

Livestatus configuration in Setup.
セットアップでのライブステータスの設定

ローカル SSL 接続テスト

ライブステータスは、サイト作成時に自動的に生成される証明書を使用します。 この証明書は、サイトによって信頼されている他のすべての CA 証明書とともに、var/ssl/ca-certificates.crt ファイルに保存されています。 コマンドラインツールopenssl s_client がライブステータスサーバーで使用されている証明書を検証できるようにするには、このファイルを証明書認証機関ファイルとして指定する必要があります。

ここでは、コマンド呼び出しの出力を大幅に短縮しています。省略部分は、[…​] で示しています。

OMD[mysite]:~$ openssl s_client -CAfile var/ssl/ca-certificates.crt -connect localhost:6557
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 CN = Site 'mysite' local CA
verify return:1
depth=0 CN = mysite
verify return:1
---
Certificate chain
 0 s:CN = mysite
   i:CN = Site 'mysite' local CA
 1 s:CN = Site 'mysite' local CA
   i:CN = Site 'mysite' local CA
---
Server certificate
[...]
    Start Time: 1664965470
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

出力がない状態になったら、LQL コマンドを対話形式で発行し、空行(リターンキーを 2 回押す)で対話を終了できます。 これが機能すれば、Livestatus クエリをパイプで接続し、追加の-quiet パラメータを使用してデバッグ出力を抑制することもできます。

OMD[mysite]:~$ echo -e "GET hosts\nColumns: name\n\n" | \
    openssl s_client -quiet  -CAfile var/ssl/ca-certificates.crt -connect localhost:6557
Can't use SSL_get_servername
depth=1 CN = Site 'mysite' local CA
verify return:1
depth=0 CN = mysite
verify return:1
myserver23
myserver42
myserver123
myserver124

4 つのホスト名の前の出力は、openssl コマンドによって STDERR に書き込まれます。2>/dev/null を追加することで、これを抑制することができます。

ライブステータスへのリモートアクセス

リモートマシンから Livestatus にアクセスする場合は、そのマシンで Checkmk サイトが信頼する証明書のリスト全体を使用しないでください。 その代わりに、セットアップからサイト CA の証明書のみを読み込んでください。

これを行うには、Global Settings > Site management > Trusted certificate authorities for SSL に移動します。 ここで、サイト CA が使用する証明書をコピーして貼り付けることができます。Content of CRT/PEM file の最初の証明書のテキスト全体をファイルにコピーします。この例では、/tmp/mysite_ca.pem を使用しています。

Display of the site CA's certificate in the Setup.
セットアップでのサイト CA の証明書の表示

リモートホストが Livestatus アクセス用に有効になっている場合、この証明書ファイルを使用して、スクリプトによる Livestatus への問い合わせが可能になります。

user@host:~$ echo -e "GET hosts\nColumns: name\n\n" | \
    openssl s_client -quiet  -CAfile /tmp/mysite_ca.pem -connect cmkserver:6557

注記:証明書ファイルは認証機能はありません。転送の暗号化のみを保証します。 アクセス保護は、Livestatus ポートへのアクセスを認可された IP アドレスによってのみ規制されます。

stunnel を使用したライブステータス

暗号化されたリモート Livestatus ポートをローカルで暗号化されていないポートとして利用したい場合は、stunnel プログラムを使用できます。

/etc/stunnel/cmk_myremotesite.conf
[pinning client]
client = yes
accept = 0.0.0.0:6557
connect = <myremotesiteip>:6557
verifyPeer = yes
CAfile = /etc/stunnel/myremotesite.pem

stunnel を再起動すると、ローカルポートへの暗号化されていないアクセスが可能になります。

user@host:~$ echo -e "GET hosts\nColumns: name\n\n" | nc localhost 6557

スクリプトでの SSL

スクリプトを使用して SSL 経由で Livestatus にアクセスする場合は、openssl s_client の使用は避けてください。 このツールの主な目的は、接続の確立をテストし、証明書チェーンをデバッグすることです。 接続に失敗した場合に、期待される出力が完全であるかどうかを確認するには、応答ヘッダーを評価することをお勧めします。 SSL およびヘッダーの評価をサポートする、よくメンテナンスされている API は、share/doc/check_mk/livestatus/api/python で入手できる Python 用 API です。 その他の適切な API は、「ファイルとディレクトリ」の章にリストされています。

17.2. SSH による接続

ローカルネットワーク外からライブステータスにアクセスする必要がある場合、IP アドレスのみによるアクセス保護では不十分な場合があります。 この場合に認証されたアクセス権を取得する最も簡単な方法は、Secure Shell を使用することです。

SSH を使用すると、リモートサーバーで実行されるコマンドを渡すことができます。

user@host:~$ ssh mysite@myserver 'lq "GET hosts\nColumns: name"'
myserver123
myserver234

あるいは、SSH トンネルを介して、Livestatus ポートを現在作業しているホストに転送することもできます。

user@host:~$ ssh -L 6557:localhost:6557 mysite@myserver

接続が確立されたら、2 番目のコンソールセッションで、openssl s_client によるアクセスが可能かどうかをテストできます。

user@host:~$ openssl s_client -CAfile /tmp/mysite_ca.pem -connect localhost:6557

このテストが成功すれば、Livestatus ネットワークに直接アクセスするために作成したスクリプトは、localhost で使用できます。

18. コマンドの設定

18.1. 概要

ライブステータスは、データクエリだけでなく 、コア(CMC または Nagios)に直接コマンドを発行するためにも使用できます。 正しいコマンドには、必ずタイムスタンプが含まれます。これは、実際には必要なものなら何でもかまいません。 ただし、ログでプロセスの実行時間を追跡するために追加で使用されるため 、できるだけ正確な時刻を入力することをお勧めします。 タイムスタンプが欠落しているコマンドは、エラーメッセージを表示せずに破棄され 、ログに単純なエントリが記録されます。 cmc.log!

タイムスタンプをできるだけ正確にするため、コマンドは入力ストリームで設定せず、直接発行することをお勧めします。 このような場合、変数にもアクセスでき、実際の現在の 時刻を指定することができます。 この形式は、Checkmk Raw の Nagios-Core と、商用版の CMC の両方で機能します。

OMD[mysite]:~$ lq "COMMAND [$(date +%s)] DISABLE_NOTIFICATIONS"

このフォーマットは、Checkmk Rawの Nagios-Core と、商業版の CMC の両方で機能します。 ただし、2 つのコアでは、コマンドは部分的にしか重複していません。 Nagios-Core のコマンドの完全なリストは、Nagios のweb サイトに直接掲載されています。 CMC で使用できるコマンドは、 コマンドリファレンス

18.2. Nagios の特殊機能

コマンドのリストでは、構文は次のフォームになっています。

#!/bin/sh
# This is a sample shell script showing how you can submit the CHANGE_CUSTOM_HOST_VAR command
# to Nagios.  Adjust variables to fit your environment as necessary.

now=`date +%s`
commandfile='/usr/local/nagios/var/rw/nagios.cmd'

/bin/printf "[%lu] CHANGE_CUSTOM_HOST_VAR;host1;_SOMEVAR;SOMEVALUE\n" $now > $commandfile

ご存じのとおり、Checkmk ではコマンドの発行にはよりシンプルな形式を使用しています。 Nagios 形式を Checkmk と互換性のある形式にするには、コマンド、タイムスタンプ、および必要に応じて変数 を指定するだけです。

OMD[mysite]:~$ lq "COMMAND [$(date +%s)] CHANGE_CUSTOM_HOST_VAR;host1;_SOMEVAR;SOMEVALUE"

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

パス 機能

~/tmp/run/live

クエリおよびコマンドを送信するための Unix ソケットです。

~/bin/lq

ライブステータスで Unix ソケットへのクエリおよびコマンドの発行を簡略化するためのスクリプトコマンドです。

~/var/log/cmc.log

CMC のログファイル。クエリ/コマンドが他のデータとともに記録されます。

~/var/check_mk/core/history

CMC のログファイル。コアの実行中に発生したすべての変更(ホスト/サービスの状態の変化など)が記録されます。

~/var/check_mk/core/archive/

history-log ファイルはここにアーカイブされます。これらは、必要な場合にのみ読み込まれます。

~/var/log/nagios.log

Nagios-Core のログファイル。クエリ/コマンドが他のデータとともに記録されます。

~/var/nagios/archive/

history-log ファイルはここにアーカイブされます。これらは、必要な場合にのみ読み込まれます。

~/share/doc/check_mk/livestatus/LQL-examples/

このディレクトリには、試すことができるライブステータスクエリの例がいくつかあります。これらの例は、lq スクリプトコマンドに基づいています。lq < 1.lql

~/share/doc/check_mk/livestatus/api/python

Python 用の API はこのディレクトリにあり、いくつかの例も記載されています。このディレクトリにあるREADME もご一読ください。

~/share/doc/check_mk/livestatus/api/perl

Perl 用の API は、こちらにあります。ここにもREADME があります。使用状況の例は、examples サブディレクトリにあります。

~/share/doc/check_mk/livestatus/api/c++

C++ プログラミング言語用のサンプルコードもあります。API 自体のコードも、API の機能をよく理解できるよう、コンパイルされていないフォームでここにあります。

このページでは