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

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

Zabbix サーバーおよびプロキシのデーモンは、誤った SNMP 応答を受信した場合、次のような行をログに記録します。

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

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

Zabbix サーバー/プロキシは、SNMP walk および get アイテムに対して最大 5 回再試行します。この再試行メカニズムは、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の「コミュニティ」が標準の「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インターフェースの可用性は赤色（利用不可）に切り替わります。

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

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

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

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

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

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

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サーバーを再コンパイルしてください。

ステップ 3

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

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

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

Parameter	Description
Name	アイテム名を入力します。
Type	ここでは SNMP agent を選択します。
Key	意味の分かるキーを入力します。
Host interface	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]`。このオプションは、native SNMP bulk requests（GetBulkRequest-PDU）を非同期で使用します。このアイテムのタイムアウト設定は、アイテム設定フォームで指定できます。デバイスに到達できない場合に長時間待たされるのを避けるため、短めのタイムアウト値を設定することを検討してください。前の試行がタイムアウトまたは失敗した場合、最大 5 回の再試行が行われるためです（たとえば、3 秒のタイムアウトでは 15 秒待つことになります）。これをマスターアイテムとして使用し、前処理でマスターからデータを抽出する依存アイテムを設定できます。 `walk[OID1,OID2,...]` のように 1 回の snmp walk で複数の OID を指定し、1 つの OID を順番に非同期処理することができます。 bulk 要求で結果が返らない場合は、bulk 要求なしで単一レコードの取得が試行されます。 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 が使用されます。bulk 要求の最大繰り返し回数はインターフェースレベルで設定されます。 max repetitions パラメータは、1 回の bulk 応答で返される OID の最大数を決定することで、bulk 要求に影響します。値を大きくすると 1 回あたりの応答が大きくなり、必要な送信回数を減らせます。ただし、すべてのデバイスが非常に大きな値をサポートしているとは限らず、問題の原因になることがあります。このアイテムは、-Oe -Ot -On パラメータ付きの snmpwalk ユーティリティの出力を返します。 SNMP discovery でマスターアイテムとして使用できます。 get[OID] - 単一の値を非同期で取得します。例: `get[1.3.6.1.2.1.31.1.1.1.6.3]` このアイテムのタイムアウト設定は、アイテム設定フォームで指定できます。デバイスに到達できない場合に長時間待たされるのを避けるため、短めのタイムアウト値を設定することを検討してください。前の試行がタイムアウトまたは失敗した場合、最大 5 回の再試行が行われるためです（たとえば、3 秒のタイムアウトでは 15 秒待つことになります）。 OID - （旧方式）単一のテキストまたは数値の OID を入力して、単一の値を同期的に取得します。必要に応じて他の値と組み合わせることもできます。例: `1.3.6.1.2.1.31.1.1.1.6.3`。このオプションでは、アイテムチェックのタイムアウトはサーバーの設定ファイルで設定された値と同じになります。より高いパフォーマンスのため、`walk[OID]` および `get[OID]` アイテムの使用が推奨されます。すべての `walk[OID]` および `get[OID]` アイテムは非同期で実行されます。1 つの要求の応答を受け取るまで他のチェックを開始できない、ということはありません。DNS 解決も非同期です。非同期チェックの最大同時実行数は 1000 です（MaxConcurrentChecksPerPoller で定義）。非同期 SNMP ポーラーの数は StartSNMPPollers パラメータで定義されます。どの方法で返されたネットワークトラフィック統計についても、Preprocessing タブに Change per second ステップを追加する必要があります。追加しない場合、最新の変化量ではなく SNMP デバイスからの累積値が取得されます。

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

アイテムを保存したら、SNMP データの Monitoring > Latest data に移動します。

例1

一般的な例:

パラメータ	説明
OID	1.2.3.45.6.7.8.0 (または .1.2.3.45.6.7.8.0)
キー	<トリガーの参照として使用する一意の文字列> 例: "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リクエストを実行し、その結果を1つのレスポンスで返します。これにより、通常のSNMPアイテムやSNMPディスカバリでネットワークの往復回数を最小限に抑えることができます。

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

ネイティブSNMPバルクリクエストの使用は、SNMPリクエストの結合オプションとは関係ありません。これは、複数のSNMPリクエストを結合するZabbix独自の方法です（次のセクションを参照）。

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

複合処理の内部動作

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

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

下位レベルでは、値を問い合わせるために2種類の操作が行われます: 複数の指定オブジェクトの取得とOIDツリーのウォークです。

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

したがって、各SNMPアイテムタイプに対する複合処理の利点は以下の通りです:

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

ただし、すべてのデバイスが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つずつ問い合わせる方法に戻ります。この時点でも失敗する場合は、デバイスが確実に応答していないため、リクエストサイズが問題ではありません。

Zabbixが次のアイテムバッチに対して行う2つ目のことは、最後に成功した変数数(この例では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パケットの損失によるものと見なすからです。

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

複合リクエストが部分的または不正な応答を引き起こし、その結果、1秒あたり(デルタ)の計算が不正確になる場合(例えば、インターフェースカウンタの見かけ上のスパイクなど)、該当するインターフェースの複合リクエストを使用を無効にして、アイテムごとに個別のクエリを強制してください。これにより、偽のスパイクが防止されることがよくあります。あるいは、非同期で実行され、インターフェースごとの複合リクエストを使用のバッチ処理の対象外となる非同期get[]またはwalk[]アイテムの使用を検討してください。これらは、複合リクエスト関連の問題を回避するために従来の同期OIDチェックの代わりに使用できます。影響を受けるデバイスを特定するには、概要セクションに示されているものと同様のサーバー/プロキシのログエントリを探してください。

さらに、インターフェースが頻繁に利用不可になる場合は、リクエストの頻度を減らすためにZabbixサーバーまたはZabbixプロキシの設定ファイルでUnavailableDelayパラメータを増やす必要があるかもしれません。ディスカバリやOIDウォーク中に部分的なデータが受信された場合、アイテムがサポート対象外になることがあります。

What’s next?

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

Docs

3 SNMP エージェント

概要