Checkmk
DeutschEnglishEspañolFrançaisItaliano日本語
Cloud (SaaS) master2.3.02.2.02.1.02.0.01.6.0
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. 概要

SNMP で動作するチェックプラグインは、エージェントベースのプラグインと同様の方法で開発されています。 違いは、サービスディスカバリープロセスとチェック自体にあります。 エージェントベースのチェックプラグインでは、エージェントプラグインを使用して、Checkmk サイトに送信するデータを決定し、多くの場合、ホスト上で事前フィルタリング（評価は行いません）が行われます。 一方、SNMPでは、必要なデータフィールドを正確に指定し、明示的に要求する必要があります。 SNMPでは、これらの領域（ツリーの枝）または個々のデータフィールド（葉）は、OID（オブジェクト識別子）で識別されます。

理論的には、すべてのデータを完全に転送することは可能です（いわゆるSNMP ウォークを使用）。 しかし、高速デバイスでもこれには数分、複雑なスイッチでは 1 時間以上かかる場合があります。 したがって、これはディスカバリー中に問題となり、チェック自体ではさらに問題になります。 この点、Checkmk はより的を絞ったアプローチを採用しています。 ただし、既存のチェックのデバッグや独自のチェックの開発のために、Checkmk では SNMP ウォークを使用することができます。

SNMP の使用経験がない場合は、SNMP による監視に関する記事をお読みになることをお勧めいたします。

1.1. SNMPでは何が異なるのでしょうか？

Checkmk エージェントのチェックプラグインと比較すると、SNMP にはいくつかの特別な機能があります。 SNMP 用のチェックプラグインでは、サービスディスカバリーは 2 つの段階に分かれています。

まず、SNMP 検出機能を使用してデバイスを検出します。 これは、チェックプラグインがそれぞれのデバイスに関連しているかどうかを判断するためのもので、SNMP によって監視されるすべてのデバイスに対して実行されます。 この目的のために、SNMP ウォークを使用せずに、いくつかの OID が個別に取得されます。 その中で最も重要なものは、sysDescr （OID：1.3.6.1.2.1.1.1.0 ）です。 この OID では、各 SNMP デバイスが、Flintstones, Inc. Fred Router rev23 など、自身に関する説明を提供します。

2 番目のステップでは、SNMP ウォークを使用して、これらの候補それぞれについて必要な監視データを取得します。 これらのデータは表にまとめられ、section 引数でチェックプラグインのディスカバリー機能に提供されます。この機能により、監視する項目が決定されます。 その後、これらの項目ごとにサービスが生成されます。

チェック中に、そのデバイスに対してプラグインを実行すべきかどうかがすでにわかっているため、新しい SNMP 検出は必要ありません。 プラグインに必要な現在の監視データは、SNMP ウォークによってここで取得されます。

では、エージェントベースのプラグインと SNMP 用のチェックプラグインでは、どのような違いがあるのでしょうか？

  1. エージェントプラグイン は必要ありません。

  2. SNMP検出に必要なOIDと、それらに含まれるテキストを定義します。

  3. 監視のために SNMP ツリーのどのブランチとリーフを取得するかを決定します。

1.2. MIB を恐れないでください！

この簡単な紹介では、多くの偏見がある悪名高い SNMP MIB についてご説明します。 良いニュースです。 Checkmk は MIB を必要としません。 ただし、チェックプラグインの開発や、既存のチェックプラグインのトラブルシューティングには、MIB が重要な助けとなる場合があります。

MIB とは何ですか？ MIB は、Management Information Base（管理情報ベース）の略で、その略語が示すとおりの情報しか含まれていません。 基本的に、MIB は、SNMP データツリーのブランチおよびリーフを記述した、人間が読めるテキストファイルです。

OIDは、枝や葉を識別します。 枝の記述には、その枝が提供するシステムやサブシステムの情報が含まれます。 OID がリーフを参照する場合、MIB には、データ型 (文字列、固定小数点数、16 進文字列など)、値の範囲、および表現に関する情報が含まれます。 たとえば、温度は、0.1° の解像度で、摂氏スケールで符号付き固定小数点数として、または 1.0° 刻みでケルビンスケールで符号なしとして保存できます。

Checkmk は、自由にアクセスできる一連の MIB ファイルを提供しています。 これらのファイルは、グローバル OID ツリー内の非常に一般的なフィールドについて記述していますが、メーカー固有のフィールドは含まれていません。 したがって、自社開発のチェックプラグインにはあまり役立ちません。

そのため、お使いのデバイスに関連する MIB ファイルは、製造元の web サイト、あるいはデバイスの管理インターフェースで探してください。 これらのファイルを、Checkmk サイトの~/local/share/snmp/mibs/ ディレクトリにインストールしてください。 そうすることで、SNMP ウォークを使用して OID 番号を名前に変換し、監視に必要なデータをより迅速に見つけることができます。 すでに述べたように、よく管理されている MIB には、コメントにも興味深い情報が含まれています。 MIB ファイルは、テキストエディタまたはページャーless を使用して簡単にビューできます。

2. 正しい OID の特定

SNMP ベースのチェックプラグインを開発するための重要な前提条件は、関連する情報がどの OID に含まれているかを知っていることです。 この例では、Flintstones, Inc. のルーター「Fred Router rev23」を複数台導入したと仮定します。 この架空のデバイスは、メーカーのドキュメントや MIB のコメントでよく見られます。 しかし、一部のデバイスの連絡先や設置場所の情報を入力し忘れてしまいました。 Checkmk 用に自作したチェックプラグインを使用すると、これらのデバイスを識別できるはずです。

Tip

当社が用意したサンプルプラグインは、ほぼすべての SNMP 対応デバイスで実行できるように作成されています。 比較する文字列を適宜変更するだけで使用できます。 手元にデバイスがない場合は、「トラブルシューティング」の章でさまざまなシミュレーションオプションをご覧いただけます。

まず、完全な SNMP ウォークを実行します。 これは、SNMP 経由で利用可能なすべてのデータを取得することです。 Checkmk を使用すると、これは非常に簡単に行うことができます。 まず、チェックプラグインを開発するデバイスを監視対象に追加します。 そのデバイスが基本機能で監視できることを確認してください。 少なくとも、SNMP Info およびUptime サービスが見つかり、おそらく少なくとも1つのInterface.これにより、SNMPアクセスが正しく機能することが保証されます。

次に、Checkmk サイトのコマンドラインに切り替えます。 ここでは、次のコマンドを使用して、完全なウォークを実行できます。次の例では、ホスト名mydevice01 のデバイスを対象としています。-v オプション（詳細表示）も使用することをお勧めします。

OMD[mysite]:~$ cmk -v --snmpwalk mydevice01
mydevice01:
Walk on ".1.3.6.1.2.1"...3898 variables.
Walk on ".1.3.6.1.4.1"...6025 variables.
Wrote fetched data to /omd/sites/mysite/var/check_mk/snmpwalks/mydevice01.

前述のように、完全な SNMP ウォークには数分から数時間かかる場合があります（後者はまれですが）ので、完了までに時間がかかっても心配しないでください。 ウォークの結果は、~/var/check_mk/snmpwalks/mydevice01 ファイルに保存されます。 これは読みやすいテキストファイルで、次のように始まります。

~/var/check_mk/snmpwalks/mydevice01
.1.3.6.1.2.1.1.1.0 Flintstones, Inc. Fred Router rev23
.1.3.6.1.2.1.1.2.0 .1.3.6.1.4.1.424242.2.3
.1.3.6.1.2.1.1.3.0 546522419
.1.3.6.1.2.1.1.4.0 barney@example.com
.1.3.6.1.2.1.1.5.0 big-router-01
.1.3.6.1.2.1.1.6.0 Server room 23, Stonestreet 52, Munich
.1.3.6.1.2.1.1.7.0 72
.1.3.6.1.2.1.1.8.0 0

各行には、OID とその値が記載されています。 最も重要なものは、最初の行、つまりsysDescr です。 これは、ハードウェアモデルの一意の識別子です。

2 行目も興味深いものです。1.3.6.1.4.1 の下には、ハードウェアメーカーが独自に割り当てることができるブランチがあります。ここでは、Flintstones, Inc.が架空のメーカー ID424242 を割り当てています。 その下には、同社がルーター用に2 、同じモデル用に3 を割り当てています。 このブランチには、デバイス固有の OID が含まれています。

ただし、これらの OID はあまり意味がありません。 正しい MIB がインストールされている場合は、2 番目のステップでこれらを名前に変換することができます。 ターミナルに表示される以下のコマンドの出力を、ファイルにリダイレクトすることをお勧めします。

OMD[mysite]:~$ cmk --snmptranslate mydevice01 > /tmp/translated

このファイルがtranslated になると、元の walk と同じ内容になり、さらに各行の--> の後に OID の名前が表示されます。

/tmp/translated
.1.3.6.1.2.1.1.1.0 Flintstones, Inc. Fred Router rev23 --> SNMPv2-MIB::sysDescr.0
.1.3.6.1.2.1.1.2.0 .1.3.6.1.4.1.424242.2.3 --> SNMPv2-MIB::sysObjectID.0
.1.3.6.1.2.1.1.3.0 546522419 --> DISMAN-EVENT-MIB::sysUpTimeInstance
.1.3.6.1.2.1.1.4.0 barney@example.com --> SNMPv2-MIB::sysContact.0
.1.3.6.1.2.1.1.5.0 big-router-01 --> SNMPv2-MIB::sysName.0
.1.3.6.1.2.1.1.6.0 Server room 23, Stonestreet 52, Munich --> SNMPv2-MIB::sysLocation.0
.1.3.6.1.2.1.1.7.0 42 --> SNMPv2-MIB::sysServices.0
.1.3.6.1.2.1.1.8.0 27 --> SNMPv2-MIB::sysORLastChange.0

上記の出力例では、OID1.3.6.1.2.1.1.4.0 の値はbarney@example.com で、名前はSNMPv2-MIB::sysContact.0 です。 OID の名前を表示する追加情報は、関心のある OID を特定する際に重要な情報を提供します。 この例では、1.3.6.1.2.1.1.4.0 から1.3.6.1.2.1.1.6.0 までの OID が十分です。

3. 簡単なチェックプラグインの記述

これで準備作業が完了しました。 読み込んで評価する OID のリストができました。 次の作業では、これらのメモを使用して、どのサービスがいつ生成され、WARN またはCRIT に送信されるかを Checkmk に教えます。 このために使用する Python によるチェックプラグインのプログラミングは、エージェントベースのチェックプラグインと多くの共通点があります。 考慮すべき微妙な点があるため、使用するすべての機能を含む完全な構造を示します。

3.1. ファイルの準備

独自のチェックプラグインを作成するには、サイトディレクトリの local 階層に、すでに準備されているベースディレクトリを使用します。 これは~/local/lib/python3/cmk_addons/plugins/ です。 このディレクトリはサイトユーザーに属しているため、書き込み可能です。

このディレクトリでは、プラグインはプラグインファミリーごとに整理されており、ディレクトリ名は自由に選択できます。 たとえば、Cisco デバイスに関連するすべてのプラグインはcisco フォルダに、Flintstones, Inc. 社のルーターに関連するすべてのプラグインはflintstone フォルダに保存されます。

このサブディレクトリ<plug-in_family> には、さまざまな API に応じて、必要に応じて、あらかじめ定義された名前のサブディレクトリがさらに作成されます。たとえば、SNMP ベースのチェックプラグインを含むエージェントベースのプラグインのチェック API には、agent_based が作成されます。

新しいチェックプラグイン用の 2 つのサブディレクトリを作成し、それらに切り替えて作業を開始してください。

OMD[mysite]:~$ mkdir -p local/lib/python3/cmk_addons/plugins/flintstone/agent_based
OMD[mysite]:~$ cd local/lib/python3/cmk_addons/plugins/flintstone/agent_based

ここに、チェックプラグイン用のファイルflintstone_setup_check.py を作成します。 ファイル名は、チェックプラグインがCheckPlugin クラスのインスタンスとして作成されたときに定義されたチェックプラグインの名前と同じにするのが慣例です。 Checkmk バージョン2.0.0 以降、チェックプラグインは常に実際の Python モジュールであるため、ファイル名は必ず .py で終わる必要があります。

実行可能な基本フレームワーク（GitHubからダウンロード）は、以下の通りです。このフレームワークを以下の手順で段階的に展開していきます：

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
#!/usr/bin/env python3

from cmk.agent_based.v2 import (
    CheckPlugin,
    CheckResult,
    startswith,
    DiscoveryResult,
    Result,
    Service,
    SimpleSNMPSection,
    SNMPTree,
    State,
    StringTable,
)

def parse_flintstone(string_table):
    return {}

def discover_flintstone(section):
    yield Service()

def check_flintstone(section):
    yield Result(state=State.OK, summary="Everything is fine")

snmp_section_flintstone_setup = SimpleSNMPSection(
    name = "flintstone_base_config",
    parse_function = parse_flintstone,
    detect = startswith(".1.3.6.1.2.1.1.1.0", "Flintstone"),
    fetch = SNMPTree(base='.1.3.6.1.2.1.1', oids=['4.0']),
)

check_plugin_flintstone_setup = CheckPlugin(
    name = "flintstone_setup_check",
    sections = [ "flintstone_base_config" ],
    service_name = "Flintstone setup check",
    discovery_function = discover_flintstone,
    check_function = check_flintstone,
)

まず、チェックプラグインに必要な関数およびクラスを Python モジュールからインポートする必要があります。import * は、メモリを不必要に消費し、実際に使用可能になっている名前空間が不明になるため、使用は推奨しません。 この例では、この記事の残りの部分で必要になる、または役立つと思われるもののみをインポートします。

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
from cmk.agent_based.v2 import (
    CheckPlugin,
    CheckResult,
    startswith,
    DiscoveryResult,
    Result,
    Service,
    SimpleSNMPSection,
    SNMPTree,
    State,
    StringTable,
)

エージェントベースのチェックプラグインと比較すると、SNMP 専用の新しい関数およびクラスが際立っています。SNMPTree 、SimpleSNMPSection 、startswith です。SNMPTree は、SNMP ツリーを表示するためのクラスであり、その機能は自明です。SimpleSNMPSection クラスは、SNMP セクションを作成するために使用されます。startswith() 関数は、SNMP リーフの内容を文字列と比較します。 これについては後で詳しく説明します。

3.2. SNMP セクションの作成

正しい OID を特定したら、実際にチェックプラグインを開発します。 SNMP セクションを作成する際には、2 つのことを指定します。

  1. チェックプラグインを実行するデバイスを指定します。
    以下の例では、startswith() 関数を使用して、文字列とOIDリーフの内容の先頭部分を比較しています。 追加の割り当てオプションは以下に示されています。

  2. 監視のために取得する OID ブランチまたはリーフを宣言します。
    これは、SNMPTree クラスのコンストラクタを使用して行います。

プラグインが少数のデバイス（ここではFlintstones, Inc. Fred Router モデル）に対してのみ実行されるように、準備したサンプルファイルを拡張します。 次に、これらのデバイスについて、連絡先、デバイス名、および場所のOIDが取得されます。 これら3つのOIDは、各デバイスによって提供されます。 実際のSNMP対応デバイスでサンプルをテストする場合は、認識するモデル名をカスタマイズするだけで十分です。

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
snmp_section_flintstone_setup_check = SimpleSNMPSection(
    name = "flintstone_base_config",
    parse_function = parse_flintstone,
    detect = startswith(
        ".1.3.6.1.2.1.1.1.0",
        "Flintstones, Inc. Fred Router",
    ),
    fetch = SNMPTree(
        base = '.1.3.6.1.2.1.1',
        oids = ['4.0', '5.0', '6.0'],
    ),
)

この例には、生成された SNMP セクションを識別するためのname パラメータと、後で説明する解析関数も含まれています。

SNMP検出

detect パラメータを使用して、ディスカバリー機能を実行する条件を指定します。 この例では、OID1.3.6.1.2.1.1.1.0 (つまり、sysDescr) の値が「Flintstones, Inc. Fred Router 」 (大文字小文字は区別されません) で始まる場合に、この条件が満たされます。startswith 以外にも、識別にはさまざまな関数を使用できます。 また、各関数には、not_ で始まる否定フォームもあります。 各関数は、import ステートメントで個別に指定する必要があることに注意してください。

属性 関数 否定

equals(oid, "needle")

OID の値がテキストneedle と一致します。

not_equals(oid, "needle")

contains(oid, "needle")

OID の値が、どこかに「needle 」というテキストを含みます。

not_contains(oid, "needle")

startswith(oid, "needle")

OID の値が「needle 」で始まります。

not_startswith(oid, "needle")

endswith(oid, "needle")

OID の値が「needle 」で終わっています。

not_endswith(oid, "needle")

matches(oid, regex)

OID の値は、後と前にアンカーされた、つまり完全一致の正規表現 regex に対応しています。部分文字列のみが必要な場合は、先頭または末尾に.* を追加してください。

not_matches(oid, regex)

exists(oid)

OID はデバイスで使用可能です。その値は空でもかまいません。

not_exists(oid)

all_of またはany_of を使用して、複数の属性をリンクするオプションもあります。

all_of は、肯定的な認識のために複数のチェックが成功する必要があります。 次の例では、 sysDescr のテキストが (または または ) で始まりfoo FOO Foo、 OID にテキスト が含まれている場合に、チェックプラグインをデバイスに割り当てます。1.3.6.1.2.1.1.2.0 .4.1.11863.

detect = all_of(
    startswith(".1.3.6.1.2.1.1.1.0", "foo"),
    contains(".1.3.6.1.2.1.1.2.0", ".4.1.11863.")
)

一方、any_of は、いずれかの条件が満たされていれば成立します。 以下は、sysDescr に異なる値が許可されている例です：

detect = any_of(
    startswith(".1.3.6.1.2.1.1.1.0", "foo version 3 system"),
    startswith(".1.3.6.1.2.1.1.1.0", "foo version 4 system"),
    startswith(".1.3.6.1.2.1.1.1.0", "foo version 4.1 system"),
)

ちなみに：正規表現に慣れていますか？ もしそうなら、この例を簡素化して、1 行で済ませられるかもしれません：

detect = matches(".1.3.6.1.2.1.1.1.0", "FOO Version (3|4|4.1) .*")

なお、もう 1 つ重要な注意点があります。 チェックプラグインの SNMP 検出に渡す OID は、SNMP によって監視されているすべてのデバイスから取得されます。 Checkmk は、この方法によってのみ、チェックプラグインを適用するデバイスを決定することができます。

したがって、メーカー固有の OID を使用する場合は、十分にご注意ください。 SNMP 検出は、sysDescr (1.3.6.1.2.1.1.1.0) およびsysObjectID (1.3.6.1.2.1.1.2.0) が最初にチェックされるように設計してください。

正確な識別のために異なる OID が必要な場合は、all_of() を使用し、以下の手順に従ってください：

  1. まず、sysDescr またはsysObjectID をチェックします。

  2. さらに、引数で、プラグインを実行するデバイスのグループをさらに制限することができます。

detect = all_of(
    startswith(".1.3.6.1.2.1.1.1.0", "Flintstone"),   # first check sysDescr
    contains(".1.3.6.1.4.1.424242.2.3.37.0", "foo"),  # fetch vendor specific OID
)

これは、遅延評価の原則によって機能します。 前のチェックのいずれかが失敗すると、それ以降のチェックは実行されません。 上記の例では、OID1.3.6.1.4.1.424242.2.3.37.0 は、sysDescr にFlintstone も含まれているデバイスからのみ取得されます。

3.3. パーサ関数の作成

エージェントベースのプラグインと同様に、SNMP ベースのチェックプラグインの解析関数も、受信したエージェントデータを、簡単に、そして何よりも高性能で処理できるフォームに変換する役割があります。

ここでも、データはリストとして受け取ります。 ただし、リーフをクエリするか、ブランチをクエリするかによって違いがあるため、いくつかの注意点があります。 念のため、上記の例ではリーフが要求されています。

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
    fetch = SNMPTree(
        base = '.1.3.6.1.2.1.1',
        oids = ['4.0', '5.0', '6.0'],
    )

print() 関数で解析関数を一時的に拡張すると、チェックプラグインのテスト時に、Checkmk がこのクエリから提供するデータを表示することができます。

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
def parse_flintstone(string_table):
    print(string_table)
    return {}

最初のレベルに 1 つのエレメントのみを含むネストされたリスト、つまり取得された値のリストが表示されます。

[
    ['barney@example.com', 'big-router-01', 'Server room 23, Stonestreet 52, Munich']
]

複数のリーフを含むブランチを取得すると、結果は少し異なって見えます。 ルーターには、名前、接続ステータス、および速度が以下で読み込める、可変数のネットワークカードを搭載できると仮定します。1.3.6.1.4.1.424242.2.3.23 …

    fetch = SNMPTree(
        base = '.1.3.6.1.4.1.424242.2.3.23',
        oids = [
            '6', # all names
            '7', # all states
            '8', # all speeds
        ],
    )

… 場合、2 次元リストは次のようになります。

[
    # Name, State, Speed
    ['net0', '1', '1000'],
    ['net1', '0', '100'],
    ['net2', '1', '10000'],
    ['net3', '1', '1000'],
]

OID で利用可能なすべてのリーフは、テーブルの列に書き込まれます。 したがって、データを表示するには、一致する OID のみをクエリする必要があることは明らかです。

Tip

OID 枝を取得する最後の例は、GitHub で提供しているSNMP ウォークの一部でもあり、シミュレーションに利用できます。

では、連絡先、デバイス名、および場所の OID リーフをクエリする例に戻りましょう。 次の parse 関数は、内部リストの各エレメントを、返される辞書内のキーと値のペアにコピーするだけです。

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
def parse_flintstone(string_table):
    # print(string_table)
    result = {}
    result["contact"] = string_table[0][0]
    result["name"] = string_table[0][1]
    result["location"] = string_table[0][2]
    # print(result)
    return result

parse関数の結果は次のようにになります：

{
    'contact': 'barney@example.com',
    'name': 'big-router-01',
    'location': 'Server room 23, Stonestreet 52, Munich'
}

3.4. チェックプラグインの作成

チェックプラグインは、エージェントベースのチェックプラグインで説明したとおりに作成します。

ほとんどの場合、複数の SNMP ブランチをクエリし、その結果、複数の SNMP セクションが生成されるため、通常、評価するセクションのリストを含むsections パラメータが必要です。

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
check_plugin_flintstone_setup = CheckPlugin(
    name = "flintstone_setup_check",
    sections = [ "flintstone_base_config" ],
    service_name = "Flintstone setup check",
    discovery_function = discover_flintstone,
    check_function = check_flintstone,
)

3.5. ディスカバリー関数の記述

ディスカバリー関数も、エージェントベースのチェックプラグインの例に対応しています。 ホストごとに 1 つのサービスしか生成しないチェックプラグインの場合は、yield() を 1 つだけ用意すれば十分です。

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
def discover_flintstone(section):
    yield Service()

3.6. チェック関数の記述

この例では、連絡先、デバイス名、および位置情報が利用可能かどうかをチェックします。 したがって、チェック関数でどのフィールドが空であるかを確認し、それに応じてステータスをCRIT （何かが欠落している場合）またはOK （すべてが利用可能な場合）に設定するだけで十分です。

~/local/lib/python3/cmk_addons/plugins/flintstone/agent_based/flintstone_setup_check.py
def check_flintstone(section):
    missing = 0
    for e in ["contact", "name", "location"]:
        if section[e] == "":
            missing += 1
            yield Result(state=State.CRIT, summary=f"Missing information: {e}!")
    if missing > 0:
        yield Result(state=State.CRIT, summary=f"Missing fields: {missing}!")
    else:
        yield Result(state=State.OK, summary="All required information is available.")

チェック関数が作成されると、チェックプラグインを使用できるようになります。

この完全なチェックプラグインはGitHub で入手できます。

3.7. チェックプラグインのテストと有効化

テストと有効化は、エージェントベースのチェックプラグインと同じ方法で行います。

まず、プラグインのサービスディスカバリーを行います。

OMD[mysite]:~$ cmk -vI --detect-plugins=flintstone_setup_check mydevice01
Discovering services and host labels on: mydevice01
mydevice01:
+ FETCHING DATA
No piggyback files for 'mydevice01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
Get piggybacked data
+ ANALYSE DISCOVERED HOST LABELS
SUCCESS - Found no new host labels
+ ANALYSE DISCOVERED SERVICES
+ EXECUTING DISCOVERY PLUGINS (1)
  1 flintstone_setup_check
SUCCESS - Found 1 services

予想通り、サービスディスカバリーは正常に完了しました。 これで、チェックプラグインに含まれるチェックをテストできます。

OMD[mysite]:~$ cmk -v --detect-plugins=flintstone_setup_check mydevice01
+ FETCHING DATA
No piggyback files for 'mydevice01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
Get piggybacked data
Flintstone setup check All required information is available.
No piggyback files for 'mydevice01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
[snmp] Success, [piggyback] Success ...

監視コアを再起動すると…

OMD[mysite]:~$ cmk -R
Generating configuration for core (type nagios)...
Precompiling host checks...OK
Validating Nagios configuration...OK
Restarting monitoring core...OK

…新しいサービスが監視に表示されます。

The new service created by the check plug-in in the monitoring.
3 つの SNMP リーフのすべてのフィールドが入力されているため、サービスはOK

4. トラブルシューティング

エージェントベースのチェックプラグインのトラブルシューティングは、基本的に SNMP ベースのチェックプラグインにも適用されるため、ここでは SNMP に関する事項のみ説明します。

4.1. シミュレーションオプション

Checkmk で保存した SNMP ウォークの使用

SNMP による監視に関する記事では、GUI から SNMP ウォークを作成する方法、およびそれをシミュレーションに使用する方法を詳しく説明しています。 これにより、プラグインを開発している SNMP ホストにアクセスできないテストシステムで、チェックプラグインを開発することも可能になります。 GitHub リポジトリには、この記事で使用しているSNMP ウォークの例があります。この例を使用して、チェックプラグインの開発およびテストを行うことができます。

ダミー SNMP ディーモン

特定の OID が相互に依存して変化することを確認したい場合は、一貫したデータを配信するダミーの SNMP ディーモンをプログラムすると便利です。 Python のsnmp-agent モジュールは、このようなダミーのプログラム作成に役立ちます。

4.2. 協力的なハードウェア

新しい SNMP ベースのチェックプラグインでデバイスを監視するには、まずそのデバイスが SNMP 経由で監視可能になっている必要があります。 そのため、SNMP による監視の記事で、既知の問題と解決策の概要を確認してください。

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

ファイルパス 説明

~/local/lib/python3/cmk_addons/plugins/

プラグインファイルを保存するためのベースディレクトリです。

~/local/lib/python3/cmk_addons/plugins/<plug-in_family>/agent_based/

チェック API V2 に従って作成されたチェックプラグインの保存場所です。

~/local/share/snmp/mibs/

自動的に読み込むSNMP MIBファイルをここに保存します。
このページでは