SNMP は、最も広く使用されるネットワーク管理プロトコルになるように開発され、現在適用されているバージョンには主に SNMP v1、SNMP v2c、SNMP v3 があります。各バージョンの主な違いは、情報の定義、通信プロトコルの動作、セキュリティ機構にありますが、同時に、SNMP アプリケーションの 2 つの拡張機能である RMON (Remote Network Monitoring) と RMON2 も登場しました。
物理層の観点から見ると、SNMP を使用してネットワークを管理するには、ネットワーク管理ステーション (NMS)、エージェント (エージェント)、およびプロキシ サーバー (プロキシ) を含める必要があります。ネットワーク管理では、指示を発行したり通知情報を受信したりするために、少なくとも 1 つの NMS が必要です。エージェントは管理ノードからの要求に応答し、通知情報を積極的に生成することもでき、ネットワーク管理には 1 つ以上のエージェントが存在できます。プロキシは、異なるネットワークまたは異なるバージョン間で SNMP リクエストと通知メッセージを転送します。
プロトコル層の観点から見ると、SNMP には、SMI (管理情報の構造、管理情報構造) と MIB (管理情報ベース、管理情報ベース) が含まれます。 SMI は ASN.1 (Abstract SyntaxNotation one) のサブセットです。SMI では、ASN.1 の要素、カスタム データ型、およびマクロを SNMP で使用できると規定しています。これらの要素、データ型、マクロ、およびその他の関連構文を定義するために使用できます。 SNMP の MIB。 MIB は、エージェントで管理可能なオブジェクトの抽象的な記述です。 SNMP では、MIB はツリー構造で構成され、表示されます。ツリー内の各ノードは OID (オブジェクト識別子) と呼ばれ、Web サイトのドメイン名と同様の方法で構成され、各ノードは証明書によって表されます。 1.3.6.4として。
SNMP は、HTTP プロトコルや FTP プロトコルと同様、TCP/IP プロトコル スタックに属するアプリケーション層プロトコルです。 SNMP トランスポート層が UDP プロトコルを使用するだけです。
SNMP v1 では、NMS からエージェントへの簡易認証モード (コミュニティ) が提供されています。NMS は、エージェントにリクエストを送信するときにコミュニティ文字列を提供する必要があります。エージェントは文字列を受信した後に確認する必要があります。一貫性があるかどうか地元の人と一緒ですか?コミュニティの転送にクリア テキストを使用するため、明らかなセキュリティ リスクが存在します。
1996 年に、IETF は SNMP v2c (Community-BasedSNMP v2) をリリースしました。このバージョンでは、v1 に基づいて管理ステーション間の通信が定義されました。すべて分散ネットワーク管理をサポートしていますが、セキュリティ メカニズムの点では v1 と同じです。
1998 年に IETF は SNMP v3 をリリースし、SNMP v2 に基づいてセキュリティ (ユーザーベースのセキュリティ モデルとビューベースのアクセス制御モデル) と管理メカニズムを拡張しました。セキュリティの面では、v3 バージョンではプロトコル メッセージにセキュリティ パラメーターが追加され、暗号化された送信とメッセージの必須検証が可能になり、安全なプロトコルです。 SNMP v3 は、モジュラーの考え方を使用してプロトコル内の各コンポーネント モジュールを定義し、プロトコル アーキテクチャを改善し、最も重要なことに、SNMP v1 および SNMP v2 との互換性を維持します。
SNMP のエージェントは、主に情報のアップロードを担当します。SNMP プロトコルのレベルの機能に加えて、NMS には、SNMP プロトコルのレベルの機能に加えて、情報をログに記録し、通知する機能もあります。送受信された記録、管理、構成機能を備え、グラフィカルな構成および管理インターフェイスを提供できます。
これらの機能を実現するために、SNMP には主に次のような一連の操作コマンドが含まれています。
読み取りコマンド: Get シリーズ コマンド、NMS は次のようなコレクション管理のリクエストを送信します。エージェント情報。
Set コマンド: Set コマンド。NM は、メッセージに含まれるデータをエージェントに書き込みます。
アラーム機能: トラップ シリーズ、エージェントはアラーム/イベント メッセージ情報を NMS にアクティブに送信します。
図 13-1
1. Get オペレーション
Get オペレーションは、NMS によってアクティブに開始されるオペレーションです。 。送信メッセージには、Get リクエスト フラグに加えて、リクエスト対象の OID 名と値のペアも含まれており、管理オブジェクト情報は、この名前と値のペアをバインドする形式で転送されます。もちろん、Get オペレーションの OID に対応する値は NILL です。
2. Get-Next オペレーション
Get-Next オペレーションは Get 関数に似ていますが、クエリされる情報がメッセージにバインドされている OID 情報ではなく、次の情報である点が異なります。オブジェクトの OID 情報 (次の OID 情報が読み取り可能な場合)。たとえば、NMS がエージェント側の sysName の次のノードである sysLocation の情報を収集したいとすると、要求メッセージでは sysName.0 となり、返されるメッセージは sysLocation.0 と value にバインドされます。
3. Get-Bulk オペレーション
は、実際には複数の Get-Next オペレーションの集合であり、SNMP v2 で新たに追加されたオペレーション メソッドです。
4. Set オペレーション
Set オペレーションでは、書き込み可能な権限を持つ OID のパラメータを設定し、デバイスのパラメータ管理、構成、制御を実現します。 Get 操作のバインド変数とは異なり、Set は対応する OID 設定の値をバインドする必要があります。
5. Get-Response
Get-Response は、NMS の Get および Set コマンドに対する応答であり、コマンドとコマンド内のパラメーターに応じて、対応する戻り変数がバインドされます。情報やエラーステータス情報(コマンド実行の成否を示す)など
6. トラップ シリーズ
トラップは、エージェントが重要なイベントを NMS に積極的に報告するためのメカニズムであり、このような報告に対して、NMS はエージェントに応答する必要はありません。トラップ情報の内容は、いつ、どこで何が起こったかを示します。
1、SMI
SMI は、SNMP の ASN.1 構文で定義された情報モジュールであり、ASN.1 のサブセットです。これらのモジュールには、多くの SNMP 固有のマクロ、カスタム データ型およびルールなどが含まれています。これらのマクロ、データ型、およびルールを定義する主な目的は 3 つあります: 1 つは SNMP アプリケーションで一意のデータ型を表現および定義すること、もう 1 つは管理オブジェクトの定義方法を簡素化すること、3 つ目はオブジェクト識別子スペースを割り当てることです。 SNMPコーディング方式での管理オブジェクトと管理オブジェクト。 SNMP は、RFC 文書で定義されたこれらの情報モジュールに基づいてプロトコルを標準化し、さまざまな組織、企業、個人が管理オブジェクトを定義する際の一貫性を維持できるようにします。
SNMP では、実際には 2 つのバージョンの SMI が定義されています。つまり、RFC 1151 で定義された SMI v1 と RFC 2578 で定義された SMI v2 です。 SMI v1 では、いくつかのデータ型、ルール記述、OBJECT-TYPE マクロなどが単純に定義されていますが、SMI v2 では、すべての関連コンテンツがモジュール定義方式で完全に編成されています。
SMI v1 で定義されている基本データ型は次のとおりです。
INTEGER: 実際には 32 ビット整数です。
オクテット文字列: 0 個以上の 8 ビット文字 (シングル バイト)。テキスト文字または物理アドレスを表すことができます。値の範囲は 0 ~ 65535 です。
オブジェクト識別子: ドット付き 10 進表記で表される OID。
NULL: SMI v1 でのみ定義されており、SMI v2 では使用されなくなりました。
シーケンス: 定義リスト。
シーケンス: テーブルを定義します。
SMI v2 では、上記のデータ型の範囲制限と更新がさらに明確になり、BITS 型も導入されました。
SMI v1 のカスタム データ タイプには、次のものが含まれます。
NetworkAddress (ネットワーク アドレス)。これは、インターネット以外のネットワーク アドレス ファミリにすることができます。
2
、MIBMIB は管理情報の集合であり、ビジネス ニーズやネットワーク管理標準に基づく契約に従って編成されています。 . ルールと定義構文で記述された構造化テキスト ファイル。
管理情報ベース (MIB) 内の各管理オブジェクトは、名前、説明、データ型、その他の情報を含むすべての属性を明確に記述する必要があります。これらのプロパティの内容は、オブジェクトの一意の識別子 (OID) を通じて通信当事者によって識別できます。つまり、MIB は NMS とエージェント間の通信のブリッジであり、エージェントが MIB を実装し、NMS が MIB を認識している場合にのみ、両者は正しく連携して、対応する管理機能を実装できます。 MIB が NMS にインポートされた後でのみ、NMS は管理対象オブジェクトの詳細をすべて知ることができます。 MIB で定義された管理オブジェクトがエージェントに実装されている場合、エージェントは MIB をサポートします。エージェントは複数の MIB を実装でき、各 MIB には多かれ少なかれ管理オブジェクトを含めることができますが、明確な要件はありません。 MIB は主に 2 つの部分から構成されており、1 つは国際標準化機構によって定義された標準管理オブジェクトであり、MIB-I (RFC1156) と MIB-II (RFC1213) があります。ネットワークに接続されているすべてのデバイスは、標準 MIB で定義されている一般および基本の管理オブジェクトをサポートしています。もう 1 つは、大手メーカーや組織、個人がカスタマイズしたプライベート MIB で、機器管理のニーズや標準 MIB にはない管理対象に応じてメーカーがカスタマイズしたものです。プライベート MIB はノード エンタープライズ (1.3.6.1.4.1) の下に定義されます。
標準 MIB は、管理オブジェクトを 10 のグループに分割しており、これらは MIB ツリーの 10 のブランチです。それらは次のとおりです: システム、インターフェイス、AT (アドレス変換。ステータスは非推奨であり、次のバージョンではサポートされないことを示します)使用)、IP、ICMP、TCP、UDP、EGP、Transmission、SNMP、それらの親ノードは 1.3.6.1.2.1 (mib-2) です。これら 10 個のグループの管理オブジェクトは、ネットワーク管理の最も重要な部分の 1 つです。
システム グループ: 主にエージェントのシステム レベルの情報を説明するために使用されます。 sysName、sysLocation、sysDescr、sysServices、sysUpTime、sysContact、sysObjectID などが含まれます。これらの OID は、デバイスの名前、場所、オンライン時間など、ネットワーク管理において非常に重要な情報を提供しますが、実際の環境では、この情報の更新が間に合わず、無視されがちです。
Interfaces グループ: このグループは、ネットワーク デバイスのすべてのインターフェイス情報を提供するために使用されます。インターフェイス タイプ、インターフェイスの説明、インターフェイス レート、インターフェイス ステータスなどが含まれます。
AT グループ: アドレス変換グループ。この時間のグループは、ネットワーク アドレスと物理アドレスの間のマッピング関係を実装するテーブル オブジェクトです。テーブルをトラバースすることにより、IP アドレスと MAC アドレスの対応関係を取得できます。
IP グループ: IP 層関連情報の管理オブジェクトを定義します。これらのオブジェクトには、IP パケット、エラー情報、アドレス情報、ルーティング情報、およびアドレス マッピング情報が含まれます。
ICMP グループ: このグループは、さまざまな ICMP メッセージの送受信を記述する 26 個のスカラー オブジェクトを定義します。これらはすべて Counter タイプです。これらのオブジェクトは、メッセージの送受信速度、およびさまざまな ICMP メッセージ タイプ (要求、応答) の速度を簡単に提供できます。
TCP グループ: このグループには主に、構成管理のための TCP 再送信ポリシー、最長および最短の再送信時間を持つオブジェクト、およびパフォーマンス管理のためのリンク拒否リクエストが含まれます。 TCP 通信状態間の転送レコード、再送信の総数、受信エラーの総数、課金管理に使用される TCP データ セグメントを送受信するための技術オブジェクト、およびセキュリティ管理に使用される tcpConnTable テーブル オブジェクト。このテーブルのレコードを分析することで、リモート IP、ポート番号、ステータスなどの情報を取得し、リモート エンドからの不審なリンクを追跡します。
UDP グループ: このグループには、UDP パケットを送受信するためのカウント オブジェクト、エラー レポートのカウント オブジェクト、およびポートやポートなどの関連情報のパフォーマンスおよびアカウンティング管理に使用できるオブジェクトが含まれます。 IP アドレス。
EGP (Exterior Gateway Protocol) グループ: EGP は、自律システム (隣接システム) 間でルーティング情報を交換するために使用されるプロトコルです。このグループには、ユーザ障害管理のためのネイバー実行ステータス、ユーザ構成管理のためのローカル自律システムのドメイン番号、パフォーマンス管理のためのローカル エンティティに出入りする EGP メッセージの速度、およびエラーカウントオブジェクト。
伝送グループ: このグループの機能は、さまざまな伝送メディアに従って、対応する管理情報を提供することです。このグループは非常に特殊です。MIB-II では、このブランチの下に明確な管理オブジェクトは定義されていません。代わりに、特定の伝送メディアを管理する必要がある場合、対応するインターフェイス タイプが再編成に追加されます。
SNMP グループ: このグループは、SNMP に関連するオブジェクトを詳細に定義します。たとえば、障害管理に使用できるさまざまな種類のエラーの数に関する統計、トラップ認証の失敗によって構成管理に使用できるメッセージ オブジェクトが生成されるかどうか、送受信されるさまざまなメッセージの数に関する統計など、障害管理に使用できます。パフォーマンス管理。
SNMP では、すべての管理オブジェクトがツリー構造に編成され、管理オブジェクトはツリー内のノードとして具体化されます。このツリーは関連する国際標準化組織によって維持および管理されます。この構造化された階層構造により、オブジェクトの管理と拡張が非常に便利になります。この管理と拡張は、ノードの割り当てに反映されます。
企業、組織、または個人は、ツリー構造のブランチとなるノードを国際機関に申請する権利を有します。ノードの申請に成功したら、監視または管理のビジネス ニーズを満たすために、ブランチの下に他のノードを自由に割り当てることができます。
OID 番号。MIB 番号とも呼ばれます。 MIB は実際には OID で構成される ASN.1 モジュールであり、実際にはツリー構造で具体化されます。インターネット上には標準 MIB が数多く存在しており、SNMP では MIB-I、MIB-II などが定義されているほか、企業、組織、個人が定義した MIB も含まれています。以下に示すように。
OID ツリーでは、最上位のルート ノードのみが特定の番号を持たず仮想ノードとみなすことができ、他のノードは同じレベルで一意の番号を付けて区別します。
最上位の次レベルのノードは、CCITT (現在の ITU-T) によって管理される ccitt (0) と ISO によって管理される ISO (1) です。
インターネット ノードの下には多くのサブノードがあります。ディレクトリ (1) は予約されており、将来 OSI ディレクトリ サービスに使用される可能性があります。 mgmt(2) は IAB の責任であり、RFC で標準管理オブジェクト (実際には MIB-I および MIB-II) を定義するために使用されます。 Experimental(3) も IAB によって管理され、インターネットの実験的な性質の管理オブジェクトを定義するために使用されます。プライベートノード (4) とその下位ノードのエンタープライズノード (1) は IANA によって割り当てられ管理されており、エンタープライズノード (1) は主にさまざまな企業や組織への割り当てに使用されます。
OID ツリー構造を以下の図 13-2 に示します。
#SNMP タイプ |
説明 説明 |
Zabbix で推奨される監視項目オプション
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
##Text
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
## SNMP オブジェクト識別子、ドット付き 10 進数で表現 | #Character |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
##文字 | 値をそのまま保存 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#数値、符号なし、10 進数 |
ストア値: デルタ (1 秒あたりの速度) |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
数値符号なし、10 進数 |
値をそのまま保存します |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
値をそのまま保存します |
2 OID の検出Zabbix で SNMP 監視装置を使用する前に、監視項目に対応する OID 値とデータ型を決定する必要があります。標準の MIB と OID に加えて、機器メーカーに問い合わせる必要がありますが、メーカーが提供するドキュメントや MIB ライブラリ ファイルを通じて、監視する必要がある OID 値を迅速かつ正確に見つけることができます。 下の図 13-3 に示すように、MG-SOFT MIB ブラウザなどのいくつかのグラフィカル ツールを使用して MIB ファイルをインポートし、グラフィカル インターフェイスでデバイス情報をクエリできます。 図 13-3 グラフィカル ツールを使用すると、監視項目の OID タイプと値を迅速に参照、クエリ、決定することができます。 snmpwalk ツールを使用して、デバイスから直接クエリを実行することもできます。 snmpwalk を使用する前に、システムにソフトウェアがインストールされていることを確認してください。インストールされていない場合は、次のコマンドを使用してインストールできます。 # yum install net-snmp-utils snmpwalk を実行してデバイス情報を照会します。 # snmpwalk -v 2c -c public 10.60.0.19 1.3.6.1.2.1.1 SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS ソフトウェア、ME380x ソフトウェア(ME380x- UNIVERSALK9-M)、バージョン 15.4(3)S2、リリース ソフトウェア (fc1) テクニカル サポート: http://www.cisco.com/techsupport Copyright (c) 1986-2015 Cisco Systems, Inc.による。 Compiled Wed 28-Jan-15 11:43 by prod_rel_team SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1。 1252 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2030697335) 235 日、0:49:33.35 SNMPv2-MIB::sysContact.0 = STRING: SNMPv2-MIB::sysName.0 = STRING: SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00 デジタル パスを出力することもできますOID に対応: # snmpwalk -v 2c -On -c public 10.60.0.19 1.3.6.1.2.1.1 .1.3.6.1.2.1.1.1.0 = STRING: Cisco IOS ソフトウェア、ME380x ソフトウェア(ME380x-UNIVERSALK9-M)、バージョン 15.4(3)S2、リリース ソフトウェア (fc1) テクニカル サポート: http://www.cisco.com/techsupport Copyright (c) 1986-2015 by Cisco Systems, Inc. Compiled Wed 28-Jan-15 11:43 by prod_rel_team .1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.9.1.1252 .1.3.6.1.2.1.1.3.0 = タイムティック: (2030720756) 235 日、0:53:27.56 .1.3 .6.1.2.1.1.4.0 = 文字列: .1.3.6.1.2.1.1.5.0 = 文字列: XZX-3800 .1.3.6.1.2.1.1.6.0 =文字列: .1.3.6.1.2.1.1.7.0 = 整数: 6 .1.3.6.1.2.1.1.8.0 = タイムティック: (0) 0:00:00.00 異なるパラメータで snmpwalk コマンドを実行した場合、OID の表示方法も結果に異なります。どのように表現されるかに関係なく、結果は常に OID、データ型、戻り値の 3 つの部分で構成されます。たとえば、デバイス名は次のように表示されます: SNMPv2-MIB::sysName.0 = STRING: XZX-3800 .1.3.6.1.2.1.1.5.0= STRING: XZX-3800 sysName の戻り値である表示内容は同じですが、OID の表現が異なります Zabbix で項目を定義する際、SNMP OID 設定で最も一般的に使用される OID の一部パラメータでは OID 名を使用できます。Zabbix は、最も一般的に使用される SNMP OID の一部を数値に自動的に変換します。たとえば、SNMPv2-MIB::sysName.0 は 1.3.6.1.2.1.1.5.0 に変換されます。ただし、エンタープライズ プライベート MIB の OID は、オールデジタル パスのみを使用できます。 Zabbix で自動変換できる OID を以下の表 13-1 に示します。 #表 13-1 特別な OID##ifIndex1.3.6.1.2.1.2.2.1.1ポートインデックス1.3.6.1.2.1.2.2.1.21.3.6.1.2.1.2.2.1.3ポート番号の最大送信パケット バイト数#ifSpeed##1.3.6.1. 2.1.2.2.1.8ifInOctets##1.3.6.1.2.1。 2.2.1.10ポートで受信したバイト数1.3.6.1.2.1.2.2.1.11##1.3.6.1.2.1.2.2.1.15ポートによって受信された不明なプロトコル パケットの数ifOutOctets##ifOutUcastPktsifOutNUcastPkts1.3.6.1.2.1.2.2.1.20送信されたエラー パケットの数ポート別 1.3.6.1.2.1.2.2.1.213 SNMP の設定Zabbix で SNMP の設定を開始する前に、Zabbix サーバーで SNMP 監視機能がオンになっていることを確認してください。 Zabbix サーバーが起動すると、次のように Zabbixserver の機能リストがログ ファイルにリストされます: 911:20160218:103649.120 starting Zabbix Server. Zabbix 3.0.1 (revision58734). 911:20160218:103649.160 ******有効機能****** 911:20160218:103649.160 SNMPMONITRING:MI監視:はい#911:20160218:103649.160 SMTP認証:はい### ## 911:20160218:103649.160 Jabber 通知: はい はい 911:20160218:103649.160 Ez テキストメッセージ通知: はい 911 :20160218:103649.160 ODBC: ) 649.160 TLS サポート: はい 911:20160218:103649.160 * ***************************** 911:20160218 :103649.160 using 構成ファイル:/etc/zabbix/zabbix_server .conf SNMP 監視の有効化に関する情報が見つからない場合は、Zabbixserver をインストールする必要があります。ソース コードを使用してコンパイルおよびインストールする場合は、次のことを行う必要があります。コンパイル設定オプション --with-net-snmp を使用します。 Zabbix での SNMP 監視には UDP プロトコルのみが使用され、通常の SNMP アイテム、動的インデックス (動的インデックス) SNMP アイテム、または SNMP 低レベル検出ルールのいずれであっても、1 つのリクエストで複数の値をクエリできます。これにより、大量の SNMP を処理する際の効率が向上します。ホストの SNMP インターフェイスの [一括リクエストを使用する] オプションを設定して、一括クエリを有効または無効にします。以下の図 13-4 に示すように。 図 13-4単一インターフェイス内の同じパラメータを持つすべての SNMP 監視項目は、設定された時間間隔で同時にクエリされます。動的インデックス SNMPitems の場合、ポーラーは 128 の監視項目を同時に処理しますが、SNMP 低レベル検出ルールは個別に処理されます。クエリ中に完了する操作には、複数の指定されたオブジェクトの収集と OID ツリーの走査の 2 種類があります。コレクションとは、GetRequest-PDU を最大 128 個の変数にバインドできることを意味します。トラバーサルとは、SNMP v1 では GetNextRequest-PDU を使用し、SNMP v2 または SNMP v3 では最大繰り返しフィールドを指定して GetBulkRequest を使用することを意味し、最大 128 個の変数をバインドできます。変数。 したがって、SNMP 監視項目ごとにバッチ処理を行うと、次のようなメリットがあります。 SNMP 監視項目の定期収集データのパフォーマンスが向上します。 動的インデックス (動的インデックス) データの収集およびデータの走査を行う SNMP 監視項目のパフォーマンスが向上しました。データをトラバースする SNMP 低レベル検出ルールのパフォーマンスが向上しました。 しかし、技術的に言えば、すべてのデバイスが各リクエストに対して 128 個の値を返せるわけではなく、一部のデバイスは特定の応答値を返すことができ、一部のデバイスは大きすぎるエラー コード (1) を返すことがあります。まったく反応がありません。デバイスに最適なクエリ オブジェクトの数を決定するために、Zabbix はいくつかの戦略を使用します。最初はクエリ リクエストで 1 つの値のみをクエリし、成功した場合はクエリ リクエストで 2 つの値をクエリし、3 つの値をクエリします。成功した場合はクエリ リクエストに値を入力し、クエリするオブジェクトの数に 1.5 を乗算して同じクエリを継続します。これらのクエリ番号は昇順で、1、2、3、4、6、9、13、19、28、42、63、94、128 です。デバイスが正しい応答 (42 個の変数のクエリなど) を返すことを拒否した場合、Zabbix は次の 2 つのことを行うことがあります。 現在のバッチ クエリ項目は半分になります。つまり、21 個の変数がクエリされます。デバイスが通常の値を返す場合、28 個の変数のクエリには問題がなく、21 は 28 より大幅に小さいはずであることがわかっているため、ほとんどの場合問題はありません。項目を半分にしても正常な戻り値が得られない場合は、正常な戻り値が得られるまで問い合わせた変数の数を 1 つずつロールバックする必要があります。 Zabbix は、最後にクエリに成功した変数の数 (この例では 28) に基づいて後続のクエリでクエリを実行し、要求されたクエリ変数の数を増やし続けます (毎回 1 ずつ増加します)。上限に達しています。たとえば、最大応答が 32 変数であると仮定します。後続のリクエストは、29、30、31、32、および 33 に従ってクエリされます。できれば 1 つのリクエストは失敗し (33 変数)、Zabbix は 33 変数をバインドする別のリクエストを発行しません。 Zabbix の SNMP クエリは、このデバイス上で最大 32 個の変数をバインドできます。 Zabbix サーバーまたはプロキシ サーバーが不正な SNMP 応答を受信すると、次のような内容がログ ファイルに追加されます。 ホスト「ゲートウェイ」からの SNMP 応答には、次のような内容がすべて含まれていません。 requested variablebindings この情報は問題のある状況をすべてカバーしているわけではありませんが、少なくとも 1 つは、このホストの SNMP インターフェイスで [一括リクエストを使用する] オプションを無効にする必要があるということです。 4 定期的な SNMP 監視項目の設定SNMP を使用して装置を監視する場合、次の手順で定期的な SNMP 監視項目を設定できます。 ホストを作成して追加します。それへの SNMP インターフェイス。 Zabbix で提供されているテンプレート SNMP 汎用テンプレートを使用して、デバイスに関する基本情報を収集する監視項目を自動的に追加できます。 2. 監視対象の OID を決定します。 MIB ブラウザまたは snmpwalk を通じて監視する必要がある OID を見つけて決定します。たとえば、スイッチのギガビット ポートのトラフィックを監視する場合は、GigabitEthernet0/1 インターフェイスのインデックスがsnmpウォークは10101です。 # snmpwalk -v 2c -c public 10.60.0.19 IF-MIB::ifDescr GigabitEthernet0/1 は IF-MIB::ifDescr.10101# の文字列値として書き換えることができます #IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2GigabitEthernet0/3 は IF-MIB::ifDescr.10103 として識別されます。String "GigabitEthernet0 /4 " は、IF-MIBIF-MIB::ifDescr.10105 = STRING: GigabitEthernet0/5String"IF-MIB::ifDescr .10106 の "ifDescr.10104" の値です。 「」は「GigabitEthernet0/6」に対応しますIF-MIB::ifDescr.10107 = STRING: GigabitEthernet0/7…GigabitEthernet0/1 インターフェイス アウトレットの OID を取得しますトラフィックの割合は .1.3.6.1.2.1.2.2.1.16.10101 です。 # snmpwalk -v 2c -On -c qhdpublic 10.60.0.19IF-MIB::ifOutOctets.10101.1.3.6.1.2.1.2.2.1.16.10101 =Counter32: 36197385523. 監視項目を作成し、SNMPv2 エージェント監視モードを使用します。SNMP OID は .1.3.6.1.2.1.2.2.1.16.10101 です。 5 動的インデックスの SNMP 監視項目の設定デバイスの OID ツリーでは、ネットワーク インターフェイスなど、一部の管理オブジェクトの OID がインデックスを使用することがよくあります。ネットワーク インターフェイス。さまざまなオブジェクト上で使用されます。以下の snmpwalk の出力と同様です。 # snmpwalk -v 2c -c public 10.60.0.19 .1.3.6.1.2.1.2.2.1IF-MIB::ifIndex.1 = INTEGER: 1IF-MIB::ifIndex.5001 = 整数: 5001IF-MIB::ifIndex.5002 = 整数: 5002IF-MIB::ifIndex.5003 = 整数: 5003IF-MIB::ifIndex.10101 = 整数: 10101IF-MIB::ifIndex.10102 = 整数: 10102... IF-MIB::ifDescr.1 = 文字列: Vlan1IF-MIB::ifDescr.5001 = 文字列: ポートチャネル1IF-MIB::ifDescr.5002 = 文字列: ポート-channel2IF-MIB::ifDescr.5003 = STRING: Port-channel3GigabitEthernet0/1 は、IF-MIB::ifDescr.10101の文字列値として書き換えることができます IF-MIB::ifDescr.10102 = 文字列: GigabitEthernet0/2...IF-MIB::ifType.1 = INTEGER: propVirtual(53)IF-MIB::ifType.5001 = INTEGER: propVirtual(53)IF-MIB::ifType.5002 = INTEGER: propVirtual(53)IF-MIB: : ifType.5003 = INTEGER: propVirtual(53)IF-MIB::ifType.10101 = INTEGER: ethernetCsmacd(6)IF-MIB::ifType.10102 = INTEGER: ethernetCsmacd ( 6)...IF-MIB::ifMtu.1 = 整数: 1500IF-MIB::ifMtu.5001 = 整数: 1500 IF-MIB::ifMtu.5002 = 整数: 1500IF-MIB::ifMtu.5003 = 整数: 1500IF-MIB::ifMtu.10101 = 整数: 1500IF-MIB::ifMtu.10102 = 整数: 1500...IF-MIB::ifSpeed.1 = ゲージ 32: 1000000000 IF-MIB::ifSpeed.5001 = ゲージ 32: 2000000000IF-MIB::ifSpeed.5002 = ゲージ 32: 2000000000IF-MIB::ifSpeed.5003 = ゲージ 32: 1000000000 IF-MIB::ifSpeed.10101 = ゲージ 32: 1000000000IF-MIB::ifSpeed.10102 = ゲージ 32: 1000000000...IF-MIB::ifPhysAddress.1 = 文字列: b0:7d:47:be:ea:c0IF-MIB::ifPhysAddress.5001 = 文字列: b0:7d:47:be:ea : c2IF-MIB::ifPhysAddress.5002 = 文字列: b0:7d:47:be:ea:c3IF-MIB::ifPhysAddress.5003 = 文字列: b0:7d : 47:be:ea:c4IF-MIB::ifPhysAddress.10101 = 文字列: b0:7d:47:be:ea:c2IF-MIB::ifPhysAddress.10102 =文字列: b0:7d:47:be:ea:c3...IF-MIB::ifAdminStatus.1 = 整数: down(2) IF -MIB::ifAdminStatus.5001 = 整数: アップ(1)IF-MIB::ifAdminStatus.5002 = 整数: アップ(1)IF-MIB::ifAdminStatus.5003 =整数: アップ(1) IF-MIB::ifAdminStatus.10101 = 整数: アップ(1) IF-MIB::ifAdminStatus.10102 = 整数: アップ(1) ... 上記のデータから、各ネットワーク インターフェイスには多くの OID があることがわかります。各 OID は、インターフェイスの名前、タイプ、物理アドレスなど、ネットワーク インターフェイスのさまざまなインジケーターを表します。異なる OID が同じインデックスを通じて関連付けられていることがわかります。たとえば、最初のギガビット インターフェイスの名前は GigabitEthernet0/1、物理アドレスは b0:7d:47:be:ea:c2、ステータスはアップ (1)、インデックスは 10101 です。 同じネットワーク インターフェイスのさまざまなインジケータを監視するには、さまざまな監視項目を作成し、SNMP OID フィールドに完成した OID を入力します。この方法では問題ありませんが、実際の環境でインデックスを使用する場合、ソフトウェアやハードウェアのアップグレードによりインデックスが変更され、設定の不整合が発生する場合があります。この問題を解決するために、Zabbixではインデックス値が変化しても監視項目の監視に影響を与えない動的インデックス方式を提供しています。 動的インデックス SNMP OID を使用するための構文は次のとおりです: <データの OID>["インデックス","<インデックスのベース OID>"," ;"] 構文の各部分の意味は次のとおりです: たとえば、GigabitEthernet0/1 インターフェイスの ifInOctets を監視する場合は、構文に従って次のように定義できます。 ifInOctets["index ","ifDescr","GigabitEthernet0/1" ] は、ifDescr 内の GigabitEthernet0/1 インターフェイス、または ifDescr 内のインターフェイスのインデックス値を照合して検索し、収集されたインデックス値を ifInOctets に設定し、GigabitEthernet0/1 インターフェイスの ifInOctets 値を収集します。 動的インデックスを使用する場合、Zabbix はインデックス OID の SNMP テーブル全体を受信してキャッシュします。インデックス OID はキャッシュを通じてすぐに検出できます。将来、他の監視項目が同じインデックス OID をクエリすると、キャッシュから直接取得するため、監視ホストに問い合わせる必要はありません。 次に、監視項目のデータを受信したときに、インデックスが変更されたかどうかを確認します。インデックスが変更を送信しない場合、値のクエリは続行されます。インデックスが変更を送信した場合、Zabbix はインデックスを再構築します。キャッシュすると、各ポーラーは OID の SNMP テーブルのインデックスを再度走査します。 Zabbix では、各ポーラー プロセスに独自のキャッシュがあります。 6 SNMP 低レベル検出ルールの構成SNMP OID の検出ルールを作成する場合は、ファイル システムまたはネットワーク インターフェイスの検出ルールを定義する場合とは異なり、snmp.discovery キーを使用せず、SNMP を使用します。 agnet 監視メソッドで十分です。SNMPOID フィールドで検出する必要がある OID を定義します。形式は、discovery[{#MACRO1}, oid1, {#MACRO2}, oid2, …,] です。 {#MACRO1}、{#MACRO2}... はすべて有効なマクロ変数名で、oid1、oid2... はマクロ変数の値の生成に使用されます。検出では、システムはデフォルトで {#SNMPINDEX} という名前のマクロ変数を作成し、これを使用して検出 OID のインデックスを作成します。検出結果は {#SNMPINDEX} によってグループ化されます。 次の例は、理解を深めるのに役立ちます。まず snmpwalk を使用して、スイッチから関連データを収集します。 # snmpwalk -v 2c -OT -c public 10.60.0.19 IF-MIB::ifDescr IF-MIB::ifDescr.1 = 文字列: Vlan1 ギガビットイーサネット0 /1 は、IF-MIB::ifDescr.10101 IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2 GigabitEthernet0/3 の文字列値として書き換えることができます。 IF-MIB::ifDescr.10103. # snmpwalk -v 2c -OT -c public 10.60.0.19 IF-MIB::ifPhysAddress IF-MIB::ifPhysAddress.1 = STRING : b0:7d:47:be:ea:c0 IF-MIB::ifPhysAddress.10101 = 文字列: b0:7d:47:be:ea:c2 IF-MIB : :ifPhysAddress.10102 = 文字列: b0:7d:47:be:ea:c3 IF-MIB::ifPhysAddress.10103 = 文字列: b0:7d:47:be:ea:c4 次に、検出ルールを作成するときに SNMP OID フィールドに次のように入力します: discovery[{#IFDESCR}, ifDescr, {#IFPHYSADDRESS}, ifPhysAddress] 検出ルールを実行した後、次の結果を取得します: { "data": [ "{ "{#SNMPINDEX}":"1", "{#IFDESCR}": " Vlan1", "{#IFPHYSADDRESS}": " b0:7d:47:be:ea:c0" }, 「{#SNMPINDEX}」: "2", "{#IFPHYSADDRESS}": " b0:7d:47:be:ea:c2" }, "{ "{#SNMPINDEX} " :"3", "{#IFDESCR}": " GigabitEthernet0/2", "{#IFPHYSADDRESS}":" b0:7d:47:be:ea:c3 「 「 , "{#IFPHYSADDRESS}":" b0: 7d:47:be:ea:c4" #指定された OID が値を返さない場合、以下の例のように、検出結果では対応するマクロが無視されます。 想定されるデータは次のとおりです: ifDescr.1 "インターフェイス #1"ifDescr.2 "インターフェイス #2"ifDescr.4 "インターフェイス #4"ifAlias.1 "eth0"ifAlias.2 "eth2"ifAlias.3 "eth3"ifAlias.5 "eth5 "次に、検出ルールを作成するときに SNMP OID フィールドに次のように入力します: discovery[{#IFDESCR},ifDescr, {#IFALIAS}, ifAlias]検出ルールを実行します。最終的に、次の結果が得られます。 { "data": [ "{ "{#SNMPINDEX}" : 1、 # "{ #IFDESCR}": "インターフェース #2", "{#IFALIAS} ": "eth2"
"{ "{#SNMPINDEX}": 4, "{#IFDESCR}":"インターフェイス # 4" }, "{ "{#SNMPINDEX}": 5, "{#IFALIAS}": "eth5" } ] } 実際の例として、以下の図 13-5 に示すように、最初に検出ルールを作成します。 図 13-5下の図 13-6 に示すように、定義された検出ルールに基づいてアイテム プロトタイプを作成します。図 13-6 下の図 13-7 に示すように、複数の項目プロトタイプを作成できます。 図 13-7
|
以上がZabbix 3.0が監視するネットワークデバイスは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。