SNMP による監視

ルーター、スイッチ、ファイアウォール、プリンター、アプライアンス、UPS、ハードウェアセンサー、およびその他の多くのデバイスでは、Checkmkエージェントをインストールできません。 ただし、これらのデバイスには、メーカーが提供する監視用のインターフェイス（SNMPエージェント）がすでにビルトインされています。 このエージェントには、シンプルネットワーク管理プロトコル（SNMP）を介してアクセスできます。 Checkmkは、SNMPを使用してこのようなデバイスを監視します。 この方法の利点は、監視の設定が非常に簡単であることです。

Windows および Linux 用の SNMP エージェントもありますが、Checkmkエージェントの代わりに使用することは推奨されません。 SNMP はパフォーマンスがあまり高くないため、これを監視に使用すると、通常、Checkmk サーバーは、独自のエージェントを使用する場合よりも、ホストごとに多くの CPU およびメモリを必要とします。 さらに、SNMP 経由で提供されるデータは不完全です。 ただし、Checkmkエージェントに加えてSNMP による監視が役立つ場合もあります。 このトピックスの詳細については、SNMP および Checkmk エージェントの章をご覧ください。

ただし、特定のハードウェアまたはソフトウェアコンポーネント（RAID コントローラなど）を監視するための Checkmk エージェントプラグインがないが、そのコンポーネントに SNMP インターフェースがある場合は、SNMP 経由で追加の監視データを収集することができます。 その場合は、クエリ間隔を十分に長く設定してください。

Checkmk による SNMP デバイスの監視は非常に簡単です。 SNMP をすぐに使い始めたい場合は、ビギナーズガイドの SNMP に関する短いセクションをお読みください。 一方、この記事では、Checkmk による SNMP 監視について、より深く掘り下げ、詳細や具体的なシナリオを紹介しています。

SNMP プロトコルには、さまざまなバージョンがあります。 これらのプロトコルは互いに互換性がありません。そのため、監視システムと監視対象デバイスは、常に同じプロトコルバージョンを使用する必要があります。 Checkmk は、バージョン v1、v2c、および v3 をサポートしています。 実際には、インストール例の 99% が v2c を使用しています。 SNMP の関連バージョンすべての概要は、次のとおりです。

Checkmk は、SNMP 監視にアクティブな要求、つまりプル方式を使用します。 Checkmk は、特定のデータの提供を要求する SNMP 要求を含む UDP パケット (ポート 161) をデバイスに送信します。 その後、デバイスは、応答データ (またはエラーメッセージ) を含む UDP パケットで応答します。

SNMP には 2 つ目のプロセス、SNMP トラップがあります。 これは、デバイスが、設定されたアドレスに UDP (ポート 162) 経由でプッシュモードで送信する自発的なプッシュメッセージです。 トラップには、アクティブリクエストに比べて多くの欠点があるため、監視にはあまり重要ではありません。 その欠点のいくつかを以下に示します。

ただし、トラップを使用したい、または使用する必要がある場合は、イベントコンソールがソリューションとなります。 イベントコンソールは、トラップを受信し、そこからイベントを生成することができます。

まず、デバイスを準備します。 SNMP をサポートする各デバイスには、その設定のどこかに独自の設定マスクがあります。 この設定マスクで、以下の設定を行います。

コミュニティは、SNMP にはユーザー名がないことを除いて、一種のパスワードです。 コミュニティはpublic とするのが慣例です。 これは多くのデバイス、および Checkmk のデフォルト設定です。 もちろん、これは安全ではないため、別のコミュニティを指定すべきだと主張することもできます。 これは確かに理にかなっていますが、SNMP はコミュニティをプレーンテキストで送信します（SNMP バージョン 3 を除く）。したがって、パケットを傍受できる者は誰でも、コミュニティを非常に簡単に特定することができます。 その一方で、アクセスは読み取り専用に制限されており、SNMP 経由で取得できる情報のほとんどはそれほど重要ではありません。

さらに、デバイスごとに異なるコミュニティを使用すると、そのハンドルが非常に面倒になります。 結局、コミュニティはデバイスだけでなく、監視システムでも管理する必要があります。 そのため、実際には、ユーザーは通常、どこでも同じコミュニティを使用します。少なくとも、地域、部門、データセンターなど、同じ場所では同じコミュニティを使用します。

ヒント：SNMP バージョン 3 を使用せずにセキュリティを強化したい場合は、ネットワークの概念を拡張して、管理サービス（つまり SNMP も）のトラフィックを別の管理 VLAN に配置し、そのアクセスをファイアウォールで保護することをお勧めします。

通常どおり、監視対象デバイスを Checkmk にホストとして追加します。 SNMP デバイスを 1 つのフォルダにのみ格納するようにフォルダ構造を設定した場合は、そのフォルダで直接その他の設定を行うことができます。 これにより、後でホストを追加するのが容易になり、エラーも回避できます。

ホスト（またはフォルダ）のプロパティで、[Monitoring agents ] ボックスの [Checkmk agent / API integrations ] を [No API integrations, no Checkmk agent] に設定します。

同じボックスで、[SNMP ] も有効にし、SNMP プロトコルとして [SNMPv2 or v3] を選択します。 プロトコルバージョン 1 の選択は、非常に古いデバイス向けの暫定的な解決策です。 これは、v2 が本当にサポートされていないことが分かっている場合、またはデバイスの実装に欠陥がある場合（実際にはごくまれなケース）にのみ使用してください。 何よりも、SNMP バージョン 1 は一括アクセスをサポートしていないため、非常に低速です。 この違いは非常に大きいです。

3 番目の最後の設定は、SNMP credentials です。 ここでも、v2c と v3 が異なるため、プロトコルのバージョンを選択する必要があります。 バージョン 3については、以下で説明します。 セキュリティ要件がそれほど高くない場合は、v2c で十分です。または、SNMP 通信を管理 VLAN に配置して、セキュリティを確保することもできます。 SNMPv2c では、前述のようにコミュニティの入力が必要です。

SNMP 認証情報をフォルダ構造で簡単に渡すことができない場合は、SNMP 認証情報を設定する別の方法があります。Setup > Agents > SNMP rules > SNMP credentials of monitored hosts ルールセットです。 これにより、ホストタグ、ラベル、および同様のプロパティに基づいて認証情報を割り当てることができます。 原則として、ホストまたはフォルダで直接設定されたコミュニティは、ルールよりも常に優先されます。

設定が完了したら、診断ページに少し立ち寄ってみてください。 そのためには、アクションバーボタン「Save & go to connection test 」で保存してください。 以下は、スイッチの診断の例です。 SNMP のさまざまなプロトコルバージョンが同時に試されます。

通常の現代的なデバイスは、4つのバリエーションすべてに対して同じデータで応答する必要があります。ただし、設定によっては制限される場合があります。 結果は次のように表示されます:

4つの情報出力は次のように説明されています:

SNMP を実装する際に理論的に起こりうるミスは、実際にはすべて、あるメーカーによってすでに犯されているようです。 そのため、SNMP は問題なく動作するものの、プロトコルの特定の部分が機能しない、または誤って実装されているデバイスがあります。

問題が発生するのは商業版の場合、その理由の一つとして、デフォルトで有効になっている、より高性能なインライン SNMP実装が、snmpget よりも標準への準拠に重きを置いていることが考えられます。 デバイスがまったく応答しない、または応答が不安定な場合は、影響を受けるデバイスのインライン SNMP をオフにして、より堅牢で大幅に速度の遅いsnmpget を有効にすると、問題が解決する場合があります。

コマンドラインでのテストでは、コマンドcmk には、いくつかのオプションに追加の--snmp-backend オプションがあり、inline (インライン SNMP を使用)、classic (snmpget を使用)、stored-walk (保存されたSNMP ウォークを使用) をパラメータとして受け付けます。 コマンドラインでのテストが成功した場合は、Hosts not using inline SNMP ルールセットを使用して、インライン SNMP を永続的に使用しないホストを指定することができます。

SNMP デバイスを監視対象に含めたにもかかわらず、Checkmk はSNMP Info およびSNMP Uptime サービスとインターフェースしか認識しません。 この問題には、いくつかの原因が考えられます。

ping は機能するが、SNMP プロトコルのどのバージョンも機能しない場合、いくつかの原因が考えられます。

デフォルトでは、SNMP は暗号化されていないため、ネットワーク上でプレーンテキストとして送信されるコミュニティによる認証は非常に脆弱です。 このレベルは、監視が読み取り専用の操作に限定されているローカルで孤立したネットワークではまだ十分であるかもしれません。

さらに高いセキュリティレベルが必要な場合は、SNMP バージョン 3 が必要です。 これにより、暗号化と本物の認証のオプションが利用可能になります。 ただし、このためには、対応する設定も必要です。

SNMPv3 では、さまざまなセキュリティレベルが認識されます。

Checkmk で必要な設定は、コミュニティを定義した場所、つまりホストのプロパティまたはSNMP credentials of monitored hosts ルールで行います。 そこで、SNMP Community の代わりに、v3 の 3 つのレベルから 1 つを選択し、必要な値を設定します。

SNMPv3 では、コンテキストの概念が導入されています。 デバイスは、SNMP ツリー内の同じポイントで、クエリで指定されたコンテキスト IDに応じて異なる情報を表示することができます。

このようなコンテキストで動作するデバイスがある場合は、Checkmk で 2 つの設定を行う必要があります。

幸い、コンテキストを使用しなければならない状況はごくわずかです。なぜなら、監視ではコンテキストを自動的に認識することができないからです。 コンテキストは、常に手動で設定する必要があります。

パフォーマンスは、特にホストの多い環境では常に重要な要素です。SNMP による監視は、Checkmk エージェントによる監視よりも CPU およびメモリの消費量が多くなります。

Checkmk Raw は、snmpget またはsnmpbulkwalk コマンドを使用して従来の方法で SNMP 要求を実行しますが、商業版には、追加のプロセスを生成することなく SNMP 要求を非常に効率的に実行する SNMP エンジンがビルトインされています。 これにより、SNMP 処理の CPU 負荷が約半分になります。 ポーリング時間が短縮されるため、同時に必要な Checkmk プロセスの数も減り、メモリ使用量も削減されます。

リソースが限界に達した場合、または 1 台のデバイスのポーリングに 60 秒以上かかる場合は、Checkmk がホストにクエリを送信する間隔を短縮することができます。 ホストの Checkmk サービスに特別に適用する「Normal check interval for service checks 」ルールセットを使用すると、1 分間の一般的な間隔を 2 分や 5 分などに延長することができます。

特に SNMP チェックには、Fetch intervals for SNMP sections ルールセットもあります。 これにより、個々のチェックプラグインの間隔を短縮することができます。Check_MK サービスによる一般的な監視の間隔よりも短い間隔を設定することはできないことをご留意ください。

ただし、監視は、1 分間の標準間隔を維持し、例外的な場合のみ、個々のホストまたはチェックの間隔を長くするように設計することをお勧めします。

デフォルトでは、Checkmk は SNMP 要求に対して 1 秒以内に応答を期待します。 また、応答がない場合は合計 3 回試行します。 応答が非常に遅いデバイス、または非常に遅いネットワーク経由でしかアクセスできないデバイスでは、これらのパラメータを変更する必要がある場合があります。 この設定は、Timing settings for SNMP access ルールセットで行います。

これらの設定は個々の SNMP 要求に適用されることにご注意ください。 ホストの監視プロセス全体は、多くの個別の要求で構成されています。 したがって、合計タイムアウトは、ここで指定した設定の倍数になります。

デフォルトでは、SNMP は 1 つのGetBulk リクエストにつき 10 件の応答を 1 つのパケットで送信します。Bulk walk: Number of OIDs per bulk 実験的なルールセットを試して、より大きな値の方がパフォーマンスが向上するかどうかを確認してください。 ただし、これは、ホストに大規模なテーブルが転送される場合（たとえば、多くのポートを備えたスイッチの場合）にのみ当てはまります。

SNMP は、実際に必要なレコードを含む、指定した数までパケットを常に埋めます。 これらのレコードのうち実際に必要なものがごくわずかである場合は、余分なデータが無駄に転送され、オーバーヘッドが増加します。

一方、実際には、一括あたり 10 OID というデフォルト値の設定のデバイスで問題が発生する場合があります。 そのような場合は、この数を減らすとよいでしょう。

Checkmk は通常、実際に監視されていないスイッチポートもすべて取得して動作します。 これは、効率的な一括リクエストでは単一のクエリを実行できないため、通常はこの方が高速であるため、良いことです。 さらに、当社の観点からは、エラー率の高いポートやケーブルを見つけるために、すべてのポートを監視することを常にお勧めしています。 ポートが確実に UP になっていない場合は、リンクステータスDOWN をOK としてフラグを立てることもできます。

ただし、スイッチのポート数が非常に多く、何らかの理由で応答が非常に遅い、または SNMP の処理効率が非常に悪いという、ごくまれなケースがあります。このような場合、すべてのポート情報を完全に取得して監視することはできなくなります。

このような場合、Bulk walk: Limit SNMP OID Ranges ルールセットを使用します。 これにより、照会するデータ (ポートなど) のリストを静的に制限することができます。 ルールの値では、特定のチェックプラグインごとに、対応するテーブルのどのインデックスを取得するかを指定します。

スイッチポートの通常のチェックタイプは、SNMP interface check with 64 bit counters (using v2c) です。 次の例は、SNMP 経由で最初の 2 つのポートのみを取得する設定を示しています。

注：このフィルタリングは、サービスディスカバリーおよび監視の前に有効になります。Network interface and switch port discovery の設定によっては、この 2 つのポートが実際に監視されるとは限りません。

Checkmk SNMP エンジンには、非常に便利な機能があります。監視対象デバイスに、その SNMP データの完全なスナップショット（SNMP ウォーク）をファイルに書き込むことができます。 このファイルは、後で別の Checkmk サーバーでデバイスの監視をシミュレートするために使用できます。この別のサーバーがデバイスに実際にネットワーク接続していなくても問題ありません。

この機能は、サポートチームがお客様のために新しいチェックプラグインを開発する場合などに、非常に頻繁に使用されます。 そのため、開発者はお客様のデバイスにアクセスする必要はなく、SNMP ウォークだけで済みます。

SNMP ウォークは、GUI から直接作成できます。 この機能は、ホストのCheck_MK サービスのアクションメニュー、およびホストのアクションメニュー（Download SNMP walk エントリ）にあります。

ウォークの作成は、最良の場合数秒で完了しますが、数分かかることも珍しくありません。 作成が完了すると、Result ラインから作成されたファイルをダウンロードできます。

または、コマンドラインからウォークを作成することもできます。 デバイスが監視されているサイトにログインします。 ウォークの作成は、cmk --snmpwalk コマンドと指定したホスト（監視で設定する必要があります）を指定するだけで簡単に行えます。

また、-v スイッチを使用すると、進行状況の詳細出力を表示できます。

ファイルは、var/check_mk/snmpwalks ディレクトリに、単にホスト名という名前で保存されます。 これはテキストファイルです。 興味がある場合は、lessなどを使ってこのファイルを表示し、Q キーでプログラムを終了することができます。

コマンドcmk --snmpwalk には、さらに便利なオプションがあります。

このウォークを別の (または同じ) Checkmk サイトでシミュレーションに使用したい場合は、このサイトのホスト名でウォークファイルをvar/check_mk/snmpwalks に保存してください。 サイトユーザーがファイルの所有者であり、許可が0600 (所有者のみが読み書き可能) に設定されていることを確認してください。

次に、Simulating SNMP by using a stored SNMP walk ルールセットで、影響を受けるホストにアクセスするルールを作成します。

これ以降、保存したファイルのみがホストの監視に使用されます。 ホストへのネットワークアクセスは、ホストチェックのための ping および設定済みのアクティブチェックを除き、一切行われません。 ホストに IP アドレス127.0.0.1 を指定することで、これらを Checkmk サーバーにリダイレクトすることができます。