これらのデバイス上の 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 を使用）か、サーバー/プロキシを再起動する必要があります。

SNMP監視の設定

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

ステップ 1

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

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

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

ここで 2c は SNMP バージョンを表すため、デバイス上の SNMP Version 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

文字列の最後の数字は、監視対象のポート番号であることに注意してください。あわせて参照: Dynamic indexes。

これにより、次のような結果が得られます。

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

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

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

SNMPv3

SNMPv3 には次のパラメータが必要です。

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 ホストの アイテム をクリックします。ホストの作成時にテンプレートを使用したかどうかによって、ホストに関連付けられた 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-PDU）を非同期で使用します。このアイテムのタイムアウト設定は、アイテムの設定フォームで設定できます。デバイスに到達できない場合に長時間待機しないよう、低いタイムアウト値を設定することを検討してください。先行する試行がタイムアウトまたは失敗した場合、最大 5 回再試行されます（たとえば、3 秒のタイムアウトでは 15 秒待機する可能性があります）。このアイテムをマスターアイテムとして使用し、前処理によってマスターアイテムからデータを抽出する依存アイテムを設定できます。 1 回の SNMP walk で複数の OID を指定できます。たとえば `walk[OID1,OID2,...]` のように指定すると、各 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 インターフェースで、GetNext は SNMPv1 インターフェースで使用されます。バルクリクエストの最大繰り返し回数は、インターフェースレベルで設定します。最大繰り返し回数パラメータは、1 回のバルクレスポンスで返される OID の最大数を決定することで、バルクリクエストに影響します。値を大きくするとバルクレスポンスが大きくなり、必要な送信回数が減少します。ただし、非常に大きな値をサポートしていないデバイスもあり、問題が発生する可能性があります。このアイテムは、-Oe -Ot -On パラメータを指定した snmpwalk ユーティリティの出力を返します。このアイテムは、SNMP ディスカバリのマスターアイテムとして使用できます。 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 パラメータで定義します。いずれかの方法で返されるネットワークトラフィック統計については、前処理タブで 1 秒あたりの変化量のステップを追加する必要があります。追加しない場合、最新の変化量ではなく、SNMP デバイスからの累積値が取得されます。

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

ここでアイテムを保存し、SNMP データを確認するために監視 > 最新データ に移動します。

例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アイテムのバッチ単位で処理されます。一方、ローレベルディスカバリルールは、これまでどおり個別に処理されます。

より低いレベルでは、値の問い合わせに使用される操作は、「指定した複数のオブジェクトの取得」と「OIDツリーのウォーク」の2種類です。

「取得」には、最大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つずつ問い合わせる処理にフォールバックします。この時点でも失敗する場合、デバイスが応答していないことは明らかであり、リクエストサイズは問題ではありません。

次に、後続のアイテムバッチに対しては、最後に成功した変数の数（この例では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パケットの損失によるものと判断するためです。

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

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

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

次は何ですか？

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

Docs

3 SNMP エージェント

概要