これらのデバイス上のSNMPエージェントが提供するデータを取得できるようにするには、Zabbixサーバーを --with-net-snmp フラグを指定してSNMPサポート付きで事前に設定しておく必要があります。また、アイテムの値が正しい形式で表示されるように、MIBファイルをインストールすることも推奨されます。 MIBファイルがない場合、UTF-8ではなくHEXで値が表示される、またはその逆になるなどの書式上の問題が発生することがあります。

SNMPチェックは、UDPプロトコル上でのみ実行されます。

Zabbixサーバーおよびプロキシデーモンは、不正なSNMP応答を受信した場合、次のようなログ行を出力します。

SNMP response from host "gateway" does not contain all of the requested variable bindings

これらは問題のあるすべてのケースを網羅しているわけではありませんが、結合リクエストを無効にすべき個々のSNMPデバイスを特定するのに役立ちます。

Zabbixサーバー/プロキシは、SNMP walk および get アイテムに対して最大5回まで再試行します（Zabbix 7.0.14以降）。この再試行メカニズムは、DNS名前解決の失敗には適用されません。

従来のSNMPチェック（単一のOID番号または文字列）では、Zabbixサーバー/プロキシは、問い合わせに失敗した後、少なくとも1回再試行します。これは、SNMPライブラリの再試行メカニズム、または内部の結合処理メカニズムのいずれかによって行われます。

SNMPv3デバイスを監視する場合は、msgAuthoritativeEngineID（snmpEngineID または "Engine ID" とも呼ばれます）が2つのデバイス間で決して共有されないようにしてください。 RFC 2571 のセクション3.1.1.1によると、これは各デバイスで一意でなければなりません。

RFC3414では、SNMPv3デバイスが engineBoots を永続化することを要求しています。一部のデバイスではこれが行われておらず、その結果、再起動後にそれらのSNMPメッセージが古いものとして破棄されます。このような場合、サーバー/プロキシ上でSNMPキャッシュを手動でクリアする（-R snmp_cache_reload を使用）か、サーバー/プロキシを再起動する必要があります。

SNMP監視の設定

SNMPを介してデバイスの監視を開始するには、次の手順を実行する必要があります:

ステップ1

監視したいアイテムのSNMP文字列（またはOID）を確認します。

SNMP文字列の一覧を取得するには、snmpwalk コマンド（net-snmp ソフトウェアの一部で、Zabbixのインストール時にあわせてインストールされているはずです）または同等のツールを使用します。

snmpwalk -v 2c -c public <host IP> .

ここでの '2c' はSNMPバージョンを表しているため、デバイスでSNMPバージョン1を示す場合は '1' に置き換えることもできます。

これにより、SNMP文字列とその最新の値の一覧が表示されるはずです。
表示されない場合は、SNMPの 'community' が標準の 'public' と異なっている可能性があり、その場合は実際の値を確認する必要があります。

その後、一覧を確認して監視したい文字列を探します。例えば、スイッチのポート3への受信バイト数を監視したい場合は、次の行にある IF-MIB::ifHCInOctets.3 文字列を使用します。

IF-MIB::ifHCInOctets.3 = Counter64: 3409739121

次に、snmpget コマンドを使用して 'IF-MIB::ifHCInOctets.3' の数値OIDを確認できます。

snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3

文字列の最後の数字は、監視対象のポート番号であることに注意してください。
あわせて参照: 動的インデックス。

これにより、次のような結果が得られるはずです。

.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941

ここでも、OIDの最後の数字がポート番号です。

よく使用されるSNMP OIDの一部は、Zabbixによって自動的に数値表現へ変換されます。

上記の最後の例では、値の型は "Counter64" で、内部的には ASN_COUNTER64 型に対応します。
サポートされている型の完全な一覧は、ASN_COUNTER、ASN_COUNTER64、ASN_UINTEGER、ASN_UNSIGNED64、ASN_INTEGER、ASN_INTEGER64、ASN_FLOAT、ASN_DOUBLE、ASN_TIMETICKS、ASN_GAUGE、ASN_IPADDRESS、ASN_OCTET_STR、ASN_OBJECT_ID です。
これらの型は、snmpget の出力ではおおむね "Counter32"、"Counter64"、"UInteger32"、"INTEGER"、"Float"、"Double"、"Timeticks"、"Gauge32"、"IpAddress"、"OCTET STRING"、"OBJECT IDENTIFIER" に対応しますが、表示ヒントの有無によっては "STRING"、"Hex-STRING"、"OID" など、別の形式で表示されることもあります。

ステップ2

デバイスに対応するホストを作成します。

ホストにSNMPインターフェースを追加します。

IPアドレス/DNS名とポート番号を入力します。
ドロップダウンからSNMP versionを選択します。
選択したSNMPバージョンに応じてインターフェース認証情報を追加します。
- SNMPv1、v2ではコミュニティのみが必要です（通常は 'public'）。
- SNMPv3では、より詳細なオプションが必要です（以下を参照）。
ネイティブSNMPバルクリクエスト（GetBulkRequest-PDUs）の最大繰り返し値（デフォルト: 10）を指定します。これはSNMPv2およびv3のdiscovery[]およびwalk[]アイテムでのみ使用されます。
この値を高く設定しすぎると、SNMPエージェントのチェックがタイムアウトする可能性があることに注意してください。
Use combined requestsチェックボックスをオンにすると、SNMPリクエストの結合処理が有効になります（ネイティブSNMPバルクリクエストの "walk" および "get" とは無関係です）。

SNMPv3 parameter	説明
Context name	SNMPサブネット上のアイテムを識別するためのコンテキスト名を入力します。このフィールドではユーザーマクロが展開されます。
Security name	セキュリティ名を入力します。このフィールドではユーザーマクロが展開されます。
Security level	セキュリティレベルを選択します。 noAuthNoPriv - 認証プロトコルもプライバシープロトコルも使用しません AuthNoPriv - 認証プロトコルは使用し、プライバシープロトコルは使用しません AuthPriv - 認証プロトコルとプライバシープロトコルの両方を使用します
Authentication protocol	認証プロトコルを選択します - MD5、SHA1、net-snmp 5.8以降では SHA224、SHA256、SHA384 または SHA512。
Authentication passphrase	認証パスフレーズを入力します。このフィールドではユーザーマクロが展開されます。
Privacy protocol	プライバシープロトコルを選択します - DES、AES128、AES192、AES256、AES192C (Cisco) または AES256C (Cisco)。プライバシープロトコルのサポートに関する注記を参照してください。
Privacy passphrase	プライバシーパスフレーズを入力します。このフィールドではユーザーマクロが展開されます。

SNMPv3認証情報（セキュリティ名、認証プロトコル/パスフレーズ、プライバシープロトコル）が誤っている場合:

Privacy passphrase が誤っている場合を除き、Zabbixはnet-snmpからERRORを受信します。Privacy passphrase が誤っている場合、Zabbixはnet-snmpからTIMEOUTエラーを受信します。
SNMPインターフェースの可用性は赤色（利用不可）に切り替わります。

Security name を変更せずに Authentication protocol、Authentication passphrase、Privacy protocol、または Privacy passphrase を変更した場合、通常は対応するSNMPv3インターフェースがZabbixで更新されると自動的に適用されます。
Security name も変更された場合は、すべてのパラメータが即座に更新されます。

提供されているSNMPテンプレートのいずれかを使用すると、一連のアイテムが自動的に追加されます。テンプレートを使用する前に、それがホストと互換性があることを確認してください。

Add をクリックしてホストを保存します。

プライバシープロトコルのサポート

使用しているオペレーティングシステムおよび net-snmp の設定によっては、一部のプライバシープロトコルが利用できない場合があります。

一部の新しいオペレーティングシステム（例: RHEL9）では、net-snmp パッケージで DES のサポートが廃止されています。
RHEL 8、CentOS 8、Oracle Linux 8、Debian 12、Ubuntu LTS 22.04、openSUSE Leap 15.5 より古いオペレーティングシステムでは、暗号化プロトコル AES192 以上は標準ではサポートされていません。

net-snmp ライブラリが AES192+ をサポートしているか確認するには、次のいずれかの方法を使用します。

net-snmp-config:

net-snmp-config --configure-options

出力に --enable-blumenthal-aes が含まれている場合、AES192+ はサポートされています。

net-snmp-config は SNMP の開発パッケージの一部（Debian/Ubuntu では libsnmp-dev、CentOS/RHEL/OL/SUSE では net-snmp-devel）であり、デフォルトではインストールされていない場合があることに注意してください。

snmpget:

snmpget -v 3 -x AES-256

出力に Invalid privacy protocol specified after -3x flag: AES-256 が含まれている場合、AES192+ はサポートされていません。
出力に No hostname specified. が含まれている場合、AES192+ はサポートされています。

使用している net-snmp ライブラリが AES192 以上のプロトコルをサポートしていない場合は、--enable-blumenthal-aes オプションを指定して net-snmp を再コンパイルし、その後 --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config オプションを指定して Zabbix server を再コンパイルしてください。

ステップ3

監視用のアイテムを作成します。

それでは、Zabbix に戻り、先ほど作成した SNMP ホストの アイテム をクリックしてください。ホスト作成時にテンプレートを使用したかどうかによって、ホストに関連付けられた SNMP アイテムの一覧が表示されるか、単に空の一覧が表示されます。ここでは、snmpwalk と snmpget を使って今収集した情報をもとに、自分でアイテムを作成する前提で進めますので、アイテムの作成 をクリックしてください。

新しいアイテムのフォームで、必要なパラメータを入力します。

パラメータ	説明
名前	アイテム名を入力します。
タイプ	ここでは SNMPエージェントを選択します。
キー	意味の分かるキーを入力します。
ホストインターフェース	スイッチ/ルーターなどの SNMP インターフェースが選択されていることを確認します。
SNMP OID	サポートされているいずれかの形式で OID 値を入力します。 walk[OID1,OID2,...] - 値のサブツリーを取得します。例: `walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3]`。このオプションでは、ネイティブ SNMP バルクリクエスト (GetBulkRequest-PDUs) を非同期で使用します。このアイテムのタイムアウト設定は、アイテム設定フォームで指定できます。デバイスに到達できない場合の長い遅延を避けるため、低いタイムアウト値を設定することを検討してください。以前の試行がタイムアウトまたは失敗した場合、最大 5 回の再試行 (Zabbix 7.0.14 以降) が行われるためです（例: 3 秒のタイムアウトでは 15 秒の待機時間になる可能性があります）。このアイテムはマスターアイテムとして使用でき、前処理を使ってマスターからデータを抽出する依存アイテムを設定できます。 `walk[OID1,OID2,...]` のように、1 回の snmp walk で複数の OID を指定し、1 つずつ非同期に処理することも可能です。バルクリクエストで結果が返されない場合は、バルクリクエストを使わずに単一レコードの取得が試行されます。 MIB 名もパラメータとしてサポートされているため、`walk[1.3.6.1.2.1.2.2.1.2]` と `walk[ifDescr]` は同じ出力を返します。複数の OID/MIB、たとえば `walk[ifDescr,ifType,ifPhysAddress]` を指定した場合、出力は連結された一覧になります。 GetBulk リクエストは SNMPv2 および v3 のインターフェースで使用され、SNMPv1 のインターフェースでは GetNext が使用されます。バルクリクエストの max repetitions はインターフェースレベルで設定します。 max repetitions パラメータは、1 回のバルク応答で返される OID の最大数を決定することで、バルクリクエストに影響します。値を大きくするとバルク応答も大きくなり、必要な送信回数を減らせます。ただし、すべてのデバイスが非常に大きな値をサポートしているとは限らず、問題が発生する可能性があります。このアイテムは、snmpwalk ユーティリティに -Oe -Ot -On パラメータを付けて実行した場合の出力を返します。このアイテムは、SNMPディスカバリでマスターアイテムとして使用できます。 get[OID] - 単一の値を非同期で取得します。例: `get[1.3.6.1.2.1.31.1.1.1.6.3]` このアイテムのタイムアウト設定は、アイテム設定フォームで指定できます。デバイスに到達できない場合の長い遅延を避けるため、低いタイムアウト値を設定することを検討してください。以前の試行がタイムアウトまたは失敗した場合、最大 5 回の再試行 (Zabbix 7.0.14 以降) が行われるためです（例: 3 秒のタイムアウトでは 15 秒の待機時間になる可能性があります）。 OID - （レガシー）単一のテキストまたは数値の OID を入力して、単一の値を同期的に取得します。必要に応じて他の値と組み合わせることもできます。例: `1.3.6.1.2.1.31.1.1.1.6.3`。このオプションでは、アイテムチェックのタイムアウトはサーバーの設定ファイルで設定された値と同じになります。より高いパフォーマンスのために、`walk[OID]` および `get[OID]` アイテムの使用を推奨します。すべての `walk[OID]` および `get[OID]` アイテムは非同期で実行されます。つまり、他のチェックを開始する前に、あるリクエストへの応答を受信する必要はありません。DNS の名前解決も同様に非同期です。非同期チェックの最大同時実行数は 1000 です（MaxConcurrentChecksPerPoller で定義）。非同期 SNMP ポーラーの数は、StartSNMPPollers パラメータで定義されます。どの方法で取得した場合でも、ネットワークトラフィック統計については、前処理タブで 1秒あたりの変化量ステップを追加する必要がある点に注意してください。そうしないと、SNMP デバイスから最新の変化量ではなく累積値を取得することになります。

必須入力フィールドには、赤いアスタリスクが付いています。

次に、アイテムを保存し、SNMP データについて監視 > 最新データ に移動してください。

例 1

一般的な例:

Parameter	Description
OID	1.2.3.45.6.7.8.0（または .1.2.3.45.6.7.8.0）
Key	<トリガーの参照として使用する一意の文字列> 例えば、"my_param"。

OID は数値形式または文字列形式のいずれでも指定できることに注意してください。ただし、場合によっては文字列 OID を数値表現に変換する必要があります。この目的には、snmpget ユーティリティを使用できます。

snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0

例 2

稼働時間の監視:

パラメータ	説明
OID	MIB::sysUpTime.0
キー	router.uptime
値の型	浮動小数点数
単位	uptime
前処理ステップ: カスタム乗数	0.01

ネイティブSNMPバルクリクエスト

walk[OID1,OID2,...] アイテムでは、SNMPバージョン2/3で利用可能な、バルクリクエスト（GetBulkRequest-PDUs）向けのネイティブSNMP機能を使用できます。

SNMPのGetBulkリクエストは、複数のGetNextリクエストを実行し、その結果を単一のレスポンスで返します。これは、通常のSNMPアイテムだけでなく、ネットワーク往復回数を最小限に抑えるためのSNMPディスカバリにも使用できます。

SNMP walk[OID1,OID2,...] アイテムは、1回のリクエストでデータを収集するマスターアイテムとして使用でき、レスポンスは必要に応じて依存アイテムが前処理を使用して解析します。

ネイティブSNMPバルクリクエストの使用は、SNMPリクエストを結合するオプションとは無関係であることに注意してください。これは、複数のSNMPリクエストを結合するZabbix独自の方法です（次のセクションを参照）。

SNMPバルクアイテムでは、1つのパケットが失われた場合の失敗を回避するため、最大5回の再試行（Zabbix 7.0.14以降）が行われます。 get および walk を使用するSNMPアイテムのタイムアウト（アイテム設定フォームで設定）は、セッション全体に対して設定されます。タイムアウトは、データが完全に取得されたかどうかにかかわらず適用されます。データが部分的にしか受信されなかった場合（たとえば、複数のOIDのうち1つについてのみ正常にデータが収集された場合）、そのアイテムは「Only partial data received」というメッセージとともに未サポートになります。タイムアウトに達すると再試行が行われ、タイムアウトはリセットされ、最後のリクエストが再送されます。これにより、1つのパケットが失われた場合や到着が遅すぎた場合でも、最後のリクエストからセッションを継続できます。デバイスに到達できない場合の長い遅延を避けるため、タイムアウト値は低めに設定することを検討してください。以前の試行がタイムアウトまたは失敗した場合、最大5回の再試行が行われるためです（例: タイムアウトが3秒の場合、待機時間が15秒になる可能性があります）。

組み合わせ処理の内部動作

Zabbixサーバーおよびプロキシは、1回のリクエストで複数の値をSNMPデバイスに問い合わせることがあります。これは、いくつかの種類のSNMPアイテムに影響します。

通常のSNMPアイテム
動的インデックス付きSNMPアイテム
SNMPのローレベルディスカバリルール

同一インターフェース上にあり、同一のパラメータを持つすべてのSNMPアイテムは、同時に問い合わせるようスケジュールされます。最初の2種類のアイテムは、最大128アイテムのバッチ単位でポーラーによって処理されます。一方、ローレベルディスカバリルールは、従来どおり個別に処理されます。

より低いレベルでは、値を問い合わせるために実行される操作には2種類あります。複数の指定オブジェクトを取得する方法と、OIDツリーをwalkする方法です。

「取得」では、最大128個の変数バインディングを持つGetRequest-PDUが使用されます。「walk」では、SNMPv1にはGetNextRequest-PDUが使用され、SNMPv2およびSNMPv3には「max-repetitions」フィールドが最大128のGetBulkRequestが使用されます。

したがって、各SNMPアイテムタイプにおける組み合わせ処理の利点は、以下のとおりです。

通常のSNMPアイテムは、「取得」の改善による恩恵を受けます。
動的インデックス付きSNMPアイテムは、「取得」と「walk」の両方の改善による恩恵を受けます。「取得」はインデックスの検証に使用され、「walk」はキャッシュの構築に使用されます。
SNMPローレベルディスカバリルールは、「walk」の改善による恩恵を受けます。

ただし、技術的な問題として、すべてのデバイスが1回のリクエストで128個の値を返せるわけではありません。常に適切な応答を返すものもありますが、一定の上限を超える可能性のある応答に対しては、"tooBig(1)" エラーを返すか、まったく応答しないデバイスもあります。

特定のデバイスに対して問い合わせるオブジェクト数の最適値を見つけるために、Zabbixは次の戦略を使用します。まず慎重に、1回のリクエストで1つの値を問い合わせることから開始します。それが成功すると、1回のリクエストで2つの値を問い合わせます。それも成功すると、1回のリクエストで3つの値を問い合わせ、以降も同様に、問い合わせるオブジェクト数を1.5倍しながら進めます。その結果、リクエストサイズは次のような系列になります: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128。

ただし、デバイスが適切な応答を返さなくなった場合（たとえば42個の変数に対して）、Zabbixは2つのことを行います。

まず、現在のアイテムバッチについては、1回のリクエスト内のオブジェクト数を半分にし、21個の変数を問い合わせます。デバイスが稼働していれば、28個の変数では動作することが確認されており、21個はそれよりかなり少ないため、大半のケースでこの問い合わせは成功するはずです。それでも失敗する場合、Zabbixは値を1つずつ問い合わせる方式にフォールバックします。この時点でも失敗する場合は、デバイスが確実に応答しておらず、リクエストサイズは問題ではないことになります。

次に、後続のアイテムバッチに対しては、最後に成功した変数数（この例では28）から開始し、上限に達するまでリクエストサイズを1ずつ増やしていきます。たとえば、最大応答サイズが32変数であるとすると、後続のリクエストサイズは29、30、31、32、33となります。最後のリクエストは失敗し、Zabbixは以後サイズ33のリクエストを発行しなくなります。その時点以降、Zabbixはこのデバイスに対して最大32個の変数までしか問い合わせません。

この変数数で大きな問い合わせが失敗する場合、考えられる理由は2つあります。デバイスが応答サイズを制限する際の正確な基準は不明ですが、ここでは変数数を使ってそれを近似しようとしています。 1つ目の可能性は、この変数数が一般的なケースにおけるデバイスの実際の応答サイズ上限付近にあることです。つまり、応答が上限未満になることもあれば、上限を超えることもあります。 2つ目の可能性は、いずれかの方向のUDPパケットが単純に失われたことです。これらの理由から、Zabbixは問い合わせ失敗時に、デバイスがより余裕を持って処理できる範囲に入るよう最大変数数を減らしますが、それは最大2回までです。

上記の例で、32個の変数を含む問い合わせがたまたま失敗した場合、Zabbixはその数を31に減らします。それもたまたま失敗した場合、Zabbixはその数を30に減らします。ただし、Zabbixは30未満には減らしません。以降の失敗は、デバイスの上限ではなくUDPパケットの損失によるものとみなすためです。

ただし、デバイスが別の理由で組み合わせリクエストを適切に処理できず、上記のヒューリスティックが機能しない場合は、各インターフェースにある「Use combined requests」設定を使用して、そのデバイスに対する組み合わせリクエストを無効にできます。

組み合わせリクエストによって部分的または不正な形式の応答が発生し、その結果、1秒あたり（delta）の計算が不正確になる場合（たとえば、インターフェースカウンターに見かけ上のスパイクが発生する場合）は、影響を受けるインターフェースで Use combined requests を無効にして、アイテムごとの個別問い合わせを強制してください。これにより、誤ったスパイクを防げることがよくあります。または、非同期の get[] または walk[] アイテムの使用を検討してください。これらは非同期に実行され、インターフェースごとの Use combined requests のバッチ処理の対象になりません。そのため、従来の同期OIDチェックの代わりに使用して、組み合わせリクエストに関連する問題を回避できます。影響を受けるデバイスを特定するには、概要セクションに示されているものと同様のサーバー/プロキシログエントリを確認してください。

さらに、インターフェースが頻繁に利用不可になる場合は、リクエスト頻度を下げるために、Zabbix server または Zabbix proxy の設定ファイルで UnavailableDelay パラメータを増やす必要がある場合があります。ディスカバリまたはOID walk中に部分的なデータを受信すると、アイテムが未サポートになることがあります。

What’s next?

1 ダイナミックインデックス

Docs

2 SNMPエージェント

概要