 |
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 には、ほぼ無料で利用できるまったく別の機能があります。 それは、ハードウェア/ソフトウェアインベントリ（略称HW/SW インベントリ）です。 この機能により、ホスト上のエレメントを自動的に識別することができます。
サーバーにインストールされているソフトウェアパッケージとそのバージョンは？
サーバーにはどのような RAM コンポーネントが搭載されていますか？
マザーボードにインストールされている BIOS のバージョンは？
インストールされているハードディスクのシリアル番号は？
スイッチのポートのうち、しばらく使用されていない（したがって、おそらく空いている）ポートはありますか？
… など、さらに多くの情報
hardware.cpuにある CPU データ HW/SW インベントリを使用すると、次のようなさまざまなタスクを実行できます。
ライセンス管理システムにインストールされているソフトウェアに関するデータを提供します。
スペアパーツ注文用の部品型番の決定（RAM、ハードディスク、ファン）
CMDB に定期的にインポートするための一般的なハードウェアおよびソフトウェアデータを提供し、これらのデータを最新のものにする
ハードウェアまたはソフトウェアの変更を追跡し、たとえば、特定の BIOS アップデートがいつ実行されたかを特定します。
ハードウェアまたはソフトウェアに変更があった場合に通知を受け取る
特定のサービスパックがまだインストールされていないサーバーを特定する
他の同等のシステムに対する最大の利点は明らかです。Checkmk の既存のインフラストラクチャをそのまま利用でき、別のソフトウェア環境の設定や管理の手間が省けます。 追加で必要なのは、1 つのエージェントプラグインのデプロイだけです。 SNMP デバイスでは、インベントリスキャナも SNMP をサポートしており、このルートを介してデータを取得するため、プラグインも不要です。
さらに、Checkmk は他のインベントリスキャナに隠れる必要もありません。 チェックプラグインと同様、データスキャン機能の拡張にも絶えず取り組んでいます。 Checkmk のバージョンがアップするたびに、インベントリスキャナ用の新しいプラグインが追加され、収集できる情報もより詳細かつ広範になっていきます。
2. インストール
HW/SW インベントリのインストールは 2 つのステップで行います。 前提条件として、Checkmk エージェントがホストにすでにインストールされている必要があります (SNMP 経由で監視されていない場合)。
目的のホストのインベントリをオンにします。
これらのホストにインベントリアエージェントプラグインをデプロイします。
2.1. 目的のホストのインベントリを有効にする
ルールの作成
いつものように、特定のホストに対して設定を行う場合は、ルールの助けを借りて行うこともできます。
このルールセットは、Setup > Hosts > HW/SW Inventory rules > Do HW/SW Inventory.にあります。
もちろん、inventory という単語を使用してルール検索を使用すると、さらに簡単です。
後で説明するように、これはエージェントプラグイン用の HW/SW Inventory (Linux, Windows, Solaris, AIX) ルールセットと混同しないでください。
Do HW/SW Inventory ルールセットでは、ホストラベルを参照する一部のルールは、デフォルトで既に有効になっています。 目的のホストにそのようなラベルがある場合、HW/SW インベントリ用のサービスは既に設定されています。 そうでない場合は、新しいルールを作成する必要があります。
Add rule を使用して、インベントリを有効にするホストの新しいルールを作成します。 そこにはいくつかの設定があります。
現在は、すべてをデフォルト設定のままにしておいてください。 ここで表示される各種オプションについては、以下で説明します。
次回変更をアクティブにすると、作成したルールは、各ホストに対して、そのホストのすべてのインベントリデータを収集するアクティブチェックを生成します。このデータは、通常の Checkmk エージェントから受信したデータ、または追加の SNMP クエリによって取得されます。 新しいサービス「Check_MK HW/SW Inventory 」は、サービスリストのホストに表示され、次のような形式になります。
チェックでいくつかの項目しか見つからなかった場合でも、心配する必要はありません。これは、プラグインがまだデプロイされていないためです。
間隔の定義
インベントリデータはめったに変更されることはなく、通常、変更を認識する上で時間的制約はそれほど厳しくありません。 そのため、通常の 1 分間隔ではなく、インベントリチェックを実行する間隔を調整して使用するのが理にかなっています。 その主な理由は、アクティブチェックでのインベントリデータの処理には、通常のサービスよりもはるかに多くの計算時間が必要になるためです。
Checkmk サイトには、 Setup > Service monitoring rules > Service Checks > Normal check interval for service checks ルールセットに、Check_MK HW/SW Inventory という名前のすべてのサービスのインターバルを 1 日に設定するルールが標準で用意されています。
もちろん、1 日 1 回では不十分である場合は、このルールを 4 時間または 8 時間などにカスタマイズすることもできます。 当然、ホストごとに複数のルールを使用して、それぞれ異なる設定を行うことも可能です。
2.2. これらのホストにインベントリアエージェントプラグインをデプロイする
最も重要な手順は、インベントリ用のエージェントプラグインを関連するホストにインストールすることです。 これは、手動またはエージェントベーカリー（商業版のみ）を使用して実行できます。
手動インストール
手動でインストールするには、まずプラグインが必要です。 プラグインは、商業版ではSetup > Agents > Windows, Linux, Solaris, AIX > Related ページ、Checkmk RawではSetup > Agents.すべてのエディションで、さまざまなオペレーティングシステム用のメニュー項目があります。
オペレーティングシステムに応じて、Plug-ins ボックスで以下のプラグインを使用してください。
| オペレーティングシステム | プラグイン |
|---|---|
Windows |
|
Linux |
|
AIX |
|
Solaris |
|
これらのファイルは、Checkmk サイトのコマンドライン、~/share/check_mk/agents/plugins (Linux/Unix) サブディレクトリ、または~/share/check_mk/agents/windows/plugins (Windows) にもあります。
プラグインを、プラグイン用の正しいディレクトリにあるターゲットホストにコピーします。
Windows エージェントの場合は、C:\ProgramData\checkmk\agent\plugins です。
詳細については、Windows エージェントの記事をご覧ください。
Linux および Unix の場合、ディレクトリは/usr/lib/check_mk_agent/plugins です。
ファイルが実行可能（chmod +x ）であることを確認してください。
詳細については、Linux エージェントの記事をご覧ください。
重要なことは、エージェントが Checkmk によって、通常は 1 分に 1 回呼び出されることです。 ただし、インベントリアエージェントプラグインは、たとえば、多くのディレクトリでインストールされているソフトウェアを検索する必要があるため、通常のプラグインよりも多くの処理時間を必要とします。 また、生成されるデータ量も大幅に多くなります。 そのため、4 時間（14400 秒）ごとに新しいデータのみを生成して配信するように設計されています。
したがって、何らかの重要な理由により、インベントリチェックの間隔を 4 時間よりも短く設定した場合、実際には 4 時間ごとに新しいデータしか取得されません。 このような場合、より多くのデータを収集したい場合は、デフォルトの計算間隔を変更する必要があります。
Windows の場合、プラグインファイル内の数値を直接置き換えてください。14400 という数値を探し、別の秒数に置き換えてください。
この数値は、次のような場所にあります (詳細)。
Dim delay
Dim exePaths
Dim regPaths
'These three lines are set in the agent bakery
delay = 14400
exePaths = Array("")
regPaths =
Array("Software\Microsoft\Windows\CurrentVersion\Uninstall","Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall")Linux および Unix では、この操作は少し異なります。
この目的のために、次の行を含む設定ファイル/etc/check_mk/mk_inventory.cfg を作成してください（この例では 7200 秒）。
INVENTORY_INTERVAL=7200もう 1 つ注意があります。 インベントリアエージェントプラグイン自体は、4 時間ごとにのみ実行するように設定されています。 したがって、より長い間隔でプラグインを非同期で実行するために、エージェントのメカニズムを使用しないでください。 プラグインは、直接実行するために、通常の簡単な方法でインストールしてください。
エージェントベーカリーを使用した設定
もちろん、商業版でエージェントベーカリーを使用してエージェントを設定する場合は、さらに簡単です。 オペレーティングシステムに依存しない、HW/SW Inventory (Linux, Windows, Solaris, AIX) という名前のルールセットが 1 つだけあります。 このルールセットは、必要なプラグインのデプロイとその設定を制御します。 これは、Setup > Agents > Windows, Linux, Solaris, AIX > Agents > Agent rules にあります。
Windows では、間隔に加えて、システムにインストールされているソフトウェアを検索する際に、実行可能な.EXE ファイルを検索するパスも指定できます。
また、インストールされているソフトウェアの指標として、Windows レジストリのパスも設定できます。
2.3. テスト
プラグインが正しくデプロイされている場合、次回ホストのインベントリチェックを実行すると、記録が大幅に増えるはずです。 結果は次のようになります。
3. 在庫データとの連携
インベントリデータは、もちろん個々のホストごとに、一部はツリー形式、一部はテーブル形式で表示されます。 これらの正確な機能とアクセス方法については、以下で説明します。 ただし、ホスト環境全体に影響するビュー、特に検索もあります。 これらは、[Monitor ] メニューの [HW/SW Inventory ] エントリからアクセスできます。
3.1. ツリー構造表示
ホストのインベントリデータは、ホストごとにツリー構造で表示されるほか、テーブル形式でも表示されます。 たとえば、ツリー図は、ホストビューのメニュー項目「Host > HW/SW Inventory > Inventory of host 」から開くことができます。
あるいは、ホストをリスト表示するビューで、ホストのメニューを呼び出し、そこからインベントリを呼び出すこともできます。
どちらの場合も、ホストのインベントリデータのツリービューが表示されます。Hardware 、Networking 、Software の 3 つの基本カテゴリから、ツリーのサブブランチを展開および折りたたむことができます。
上の画像では、個々のエントリの背後に括弧で囲まれたインベントリパスが表示されています。これは、Display > Modify display options およびShow internal tree paths オプションを使用して表示することができます。
これにより、インベントリに内部指定が表示されます。たとえば、Processor セクションの内部パスはhardware.cpu です。
CPU モデルおよびアーキテクチャの指定（model およびarch）は、以下の CPU データに記載されています。
これらの内部指定を使用して、連絡先グループに対して個々のパスだけを有効にすることができます。
上記のhardware.cpu 、model、および arch エントリだけが割り当てられた連絡先グループのユーザーには、簡略化されたインベントリだけが表示されます。
3.2. 表形式の表示
インベントリデータの多くは、Hardware > System > Manufacturer > Apple Inc. エントリなど、ツリー内の非常に特定のパスにある個々の値です。 しかし、ツリーには、類似のオブジェクトのテーブルがある場所もあります。 その非常に重要な例が、Software > Packages テーブルです。
インベントリデータのこの部分の特別な点は、Host > HW/SW Inventory > Software packages から別のビューでパッケージを呼び出すことができることです。 そこでは、パッケージを検索するための特別なフィルタがあります（画像では大幅に省略しています）。
複数のホストのソフトウェアパッケージも検索できます。 対応するビューは、[Monitor > HW/SW Inventory > Search software packages] の [Monitor] メニューにあります。 インベントリに関するその他のすべてのテーブルビューも、[Monitor ] メニューにリストされています。これには、特定の Oracle データなどの詳細検索も含まれます。
ホストに対する一般的なフィルタの多くは、ビューではデフォルトでは使用できません。 これらは、ビューを編集してホストフィルタを追加すると使用可能になります。
ビューで実行できるその他の操作：
ちなみに、このようなインベントリデータは、テーブル形式ではないビューにも含めることができます。 インベントリツリー内のよく知られたパスごとに列タイプがあり、ホストのビューに追加することができます。 その例としては、定義済みのサンプルビュー「CPU inventory of all hosts 」があります。 これは、ホストごとのインベントリからの追加データを表示するホストのテーブルです。 ホストの物理 CPU 数の列をテーブルに追加する列定義の例を以下に示します。
4. インベントリデータのヒストリー
ホストの HW/SW インベントリを設定すると、Checkmk はインベントリデータのすべての変更を記録し、そのヒストリーも保存します。 これらは、インベントリデータを含むビューで確認できます。Host > HW/SW Inventory > Inventory history of host.
以下は、ヒストリーの抜粋です。 この表には、前回のチェック以降に変更された IP データの一部が表示されています。
必要に応じて、ソフトウェアまたはハードウェアに変更があった場合に通知を受けることができます。 これは、サービスCheck_MK HW/SW Inventory のステータスによって行われます。 これを行うには、この記事の最初で作成したルール（Do HW/SW Inventory ルールセット）を編集します。 そこでは、ルールの値に、履歴に影響するいくつかの設定があります。 次の例は、ソフトウェアまたはハードウェアに変更があった場合に、サービスWARN を設定しています。
次回、インベントリチェックで変更が検出されると、WARN に移動します。 すると、次のように表示されます。
次回のチェック実行時に、その間に変更がない場合、これは自動的にOK にリセットされます。 手動で実行をトリガーすることで、次の通常の定期実行を待たずに、サービスをOK に手動でリセットする方法もあります。
5. ステータスデータ
インベントリデータのツリーは、最新の適切なステータスデータで自動的に更新することができます。 これは、場合によっては非常に便利です。 その例としては、Oracle テーブルスペースがあります。 実際のインベントリデータには、SID、名前、タイプなどの比較的静的な情報しか含まれていません。 現在のステータスデータは、現在のサイズ、空き容量などの情報を補足することができます。
ツリーにステータスデータを見たい場合（これはまったく問題ありません）、最初に「Do HW/SW Inventory 」で作成したルールで、対応するオプションを有効にするだけです。
ちなみに、ステータスデータの変更によってヒストリーが変更される ことはありません。 そうなるといつも変化し続けてしまい、この機能が使い物にならなくなってしまいます。 ステータスデータはファイルには保存されず、チェックの結果と同様に、監視カーネルのメインメモリに直接保持されます。
6. データへの外部アクセス
6.1. 独自の Web API によるアクセス
ホストの HW/SW インベントリデータは、インベントリ独自の web API 経由でエクスポートできます。
注：ここでいうインベントリ独自の web API は、2.2.0 で Checkmk から削除された web APIではありません。
その URL は次のとおりです。
http://myserver/mysite/check_mk/host_inv_api.py?host=myhost
この場合の出力形式は Python ソースコードです。
JSON を使用する場合は、URL の最後に&output_format=json を追加してください。
http://myserver/mysite/check_mk/host_inv_api.py?host=myhost&output_format=json
結果は、省略形式では次のように表示されます。
result:
Attributes: {}
Nodes:
hardware:
Attributes: {}
Nodes:
memory:
Attributes:
Pairs:
total_ram_usable: 16495783936
total_swap: 1027600384
total_vmalloc: 35184372087808
Nodes: {}
Table: {}
Table: {}
... usw. ...
result_code: 0同様に、XML形式での出力をリクエストすることもできます:
http://myserver/mysite/check_mk/host_inv_api.py?host=myhost&output_format=xml.
ブラウザのアドレスバーにそれぞれの URL を入力すると、Checkmk にすでにログインしているため、すぐに結果が表示されます。 HW/SW インベントリデータは、結果キーの後のセクションの出力ファイルにあります。 スクリプトからは、オートメーションユーザーとして認証することをお勧めします。
エラーが発生した場合、たとえば指定したホストが見つからない場合、result_code が 1 に設定され、適切なエラーメッセージが表示されます。
{"result": "Found no inventory data for this host.", "result_code": 1}
複数のホストのクエリ
複数のホストの HW/SW インベントリデータを 1 つの出力でクエリすることもできます。 これを行うには、クエリを必要なすべてのホストに拡張します。
http://myserver/mysite/check_mk/host_inv_api.py?request={"hosts":["myhost","myhost2"]}&output_format=json
このクエリの結果は、上記の出力とほとんど同じになります。 ただし、最上位レベルでは、ホスト名がキーとして使用されます。 ホストに関する情報は、ディレクトリツリーの下に次のように表示されます。
result:
myhost:
Attributes: {}
Nodes:
hardware:
Attributes: {}
Nodes:
memory:
Attributes:
Pairs:
total_ram_usable: 16495783936
total_swap: 1027600384
total_vmalloc: 35184372087808
Nodes: {}
Table: {}
Table:
networking:
Attributes:
Pairs:
available_ethernet_ports: 1
hostname: "MyServer"
total_ethernet_ports: 3
total_interfaces: 4
... etc. ...
myhost2:
Attributes: {}
Nodes: {}
Table: {}
result_code: 0ホストのインベントリデータが見つからない場合、そのホストにはエラーメッセージの代わりに空のインベントリエントリが表示されます。
クエリを特定のデータに制限する
すべてのインベントリデータをクエリするのではなく、特定の情報を検索したい場合があります。 その場合は、必要な情報を指定する、いわゆるインベントリパスを指定してください。 そうすることで、これらのパス/情報を持つホストからの情報のみを受け取ることができます。
たとえば、ホストmyhost のストレージとスワップスペースの合計情報のみを表示するには、次の URL を使用します。
http://myserver/mysite/check_mk/host_inv_api.py?host=myhost&request={"paths":[".hardware.memory.total_ram_usable",".hardware.memory.total_swap"]}&output_format=json
要求した情報が返されます:
result:
Attributes: {}
Nodes:
hardware:
Attributes: {}
Nodes:
memory:
Attributes:
Pairs:
total_ram_usable: 16495783936
total_swap: 1027600384
Nodes: {}
Table: {}
Table: {}
Table: {}
result_code: 06.2. ファイル経由でのアクセス
あるいは、Checkmk が生成したファイルを読み込むこともできます。
これらのファイルは、~/var/check_mk/inventory ディレクトリに Python 形式で保存されています。
各ホストについて、圧縮されていないファイル (myhost など) と圧縮されたファイル (myhost.gz など) が 1 つずつあります。
7. 分散監視におけるインベントリ
商業版では、HW/SW インベントリは分散監視でも機能します。
ここでは、インベントリデータはまずローカルサイトで決定され、~/var/check_mk/inventory/ にローカルに保存されます。
ライブステータスプロキシディーモンは、更新されたすべてのインベントリデータをリモートサイトからセントラルサイトに定期的に転送し、~/var/check_mk/inventory/ にも保存します。
このデータはサイズが大きすぎるため、その時点でクエリを実行してもライブで取得できないため、この処理は重要です。
セントラルサイトがインベントリデータについてクエリを実行すると、これらのファイルが読み込まれ、現在のステータスデータとマージされます。その後、ライブステータスを介してリモートサイトから取得されます。
要するに、何も心配する必要はありません。
Checkmk Raw にはライブステータスプロキシがないため、セントラルサイトの GUI では HW/SW インベントリが不完全になり、ステータスデータのみが表示されます。~/var/check_mk/inventory/ ディレクトリ内のファイルを、スクリプトなどを使用して定期的にセントラルサイトに転送することで、この問題に対処できます。
ファイル拡張子.gz 以外のファイルをコピーするだけで十分です。
効率的なデータ転送には、rsync などが適しています。
8. ファイルおよびディレクトリ
8.1. Checkmk サーバー上のディレクトリ
| パス | 説明 |
|---|---|
|
Linux および Unix 用のエージェントプラグインの保存場所 |
|
Windows 用のエージェントプラグインの保存場所 |
|
個々のホストのインベントリデータを Python ファイル（圧縮および非圧縮）として保存します。 |
8.2. 監視対象ホスト上のディレクトリ
| パス | 説明 |
|---|---|
|
Windows エージェントのインベントリプラグインの保存場所 |
|
Linux/Unix エージェントのインベントリプラグインの保存場所 |
|
Linux/Unix エージェントのインベントリプラグインの設定 |