これらのデバイス上の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回まで再試行します。この再試行メカニズムは、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 を使用）か、サーバー/プロキシを再起動する必要があります。

ZabbixはSNMPv3の EngineID → IP の対応をキャッシュし、毎回プローブを送信する代わりに、後続のチェックではキャッシュされたEngineIDを再利用することで、ネットワークトラフィックを削減します。 EngineIDを再利用できない場合は、新しいEngineIDを検出するために、プローブ付きで再試行が実行されます。

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 bulkリクエスト（GetBulkRequest-PDU）に対する最大繰り返し値（既定値: 10）を指定します。これはSNMPv2およびv3の discovery[] と walk[] アイテムにのみ適用されます。この値を高く設定しすぎると、SNMPエージェントチェックのタイムアウトが発生する場合があります。
Use combined requests チェックボックスをオンにすると、SNMPリクエストのcombined processing を有効にできます（ネイティブSNMP bulkリクエストの "walk" および "get" とは関係ありません）。

SNMPv3 parameter	Description
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の認証情報（security name、authentication protocol/passphrase、privacy protocol）が正しくない場合:

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のサポートが削除されています。
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 つずつ非同期で処理することも可能です。 bulk request が結果を返さない場合は、bulk request を使わずに単一レコードの取得が試行されます。 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 request の最大繰り返し回数はインターフェースレベルで設定されます。 max repetitions パラメータは、1 回の bulk 応答で返される OID の最大数を決定することで、bulk request に影響します。値を大きくすると bulk 応答も大きくなり、必要な送信回数を減らせます。ただし、すべてのデバイスが非常に大きな値をサポートしているとは限らず、問題が発生する可能性があります。このアイテムは、-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 - (legacy) 単一のテキストまたは数値の 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 poller の数は 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 サーバーおよびプロキシは、SNMP デバイスに対して 1 回のリクエストで複数の値を問い合わせることができます。
これは、次の種類の SNMP アイテムに影響します。

通常の SNMP アイテム
動的インデックスを持つ SNMP アイテム
SNMP 低レベルディスカバリルール

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

より低いレベルでは、値の問い合わせに対して 2 種類の操作が行われます。1 つは複数の指定オブジェクトを取得する操作、もう 1 つは OID ツリーをウォークする操作です。

「取得」では、最大 128 個の variable binding を持つ GetRequest-PDU が使用されます。
「ウォーク」では、SNMPv1 では GetNextRequest-PDU が使用され、SNMPv2 および SNMPv3 では最大 128 の "max-repetitions" フィールドを持つ 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 つあります。
デバイスが応答サイズを制限する際の正確な基準は分かりませんが、Zabbix は変数数を使ってそれを近似しようとします。
そのため、1 つ目の可能性は、この変数数が一般的なケースにおけるデバイスの実際の応答サイズ上限付近にあることです。つまり、応答が上限未満になることもあれば、それを超えることもあります。
2 つ目の可能性は、どちらかの方向の UDP パケットが単純に失われたことです。
このため、Zabbix が問い合わせ失敗を受け取った場合、デバイスの許容範囲のより深いところまで到達できるように、試行する最大変数数を減らしますが、その回数は最大 2 回までです。

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

ただし、別の理由でデバイスが結合リクエストを正しく処理できず、上記のヒューリスティックが機能しない場合は、各インターフェースに対して "Use combined requests" 設定があり、そのデバイスで結合リクエストを無効にできます。

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

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

What’s next?

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

Docs

3 SNMP エージェント

概要