Table of Contents
2 SNMPエージェント
概要
プリンター、ネットワークスイッチ、ルーター、UPSなど、通常SNMP対応であり、完全なオペレーティングシステムやZabbixエージェントのセットアップが非現実的なデバイスでSNMP監視を使用したい場合があります。
これらのデバイス上のSNMPエージェントが提供するデータを取得できるようにするには、ZabbixサーバーをSNMPサポート付きで初期設定し、--with-net-snmpフラグを指定する必要があります。 アイテム値が正しい形式で表示されるように、MIBファイルのインストールも推奨されます。 MIBファイルがない場合、値がUTF-8の代わりにHEXで表示される、またはその逆など、フォーマットの問題が発生する可能性があります。
SNMPチェックはUDPプロトコルのみで実行されます。
Zabbixサーバーおよびプロキシデーモンは、不正なSNMP応答を受信した場合、次のようなログ行を記録します。
これらはすべての問題ケースを網羅しているわけではありませんが、複合リクエストを無効にすべき個々の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インストール時にインストールされているはずです）または同等のツールを使用します。
ここで'2c'はSNMPバージョンを表しているため、デバイスのSNMPバージョン1を指定する場合は'1'に置き換えることもできます。
これにより、SNMP文字列とその最新値のリストが表示されます。 表示されない場合は、SNMPの「コミュニティ」が標準の「public」と異なる可能性があるため、何であるかを調べる必要があります。
その後、リストを確認して監視したい文字列を見つけます。例えば、 スイッチのポート3に入ってくるバイト数を監視したい場合は、次の行のIF-MIB::ifHCInOctets.3文字列を使用します。
次に、snmpgetコマンドを使用して「IF-MIB::ifHCInOctets.3」の数値OIDを調べます。
文字列の最後の数字が監視対象のポート番号であることに注意してください。 参考: 動的インデックス。
これにより、次のような出力が得られます。
ここでも、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バージョンを選択します。
- 選択したSNMPバージョンに応じてインターフェースの認証情報を追加します:
- SNMPv1、v2ではコミュニティ(通常は'public')のみが必要です。
- SNMPv3では、より詳細なオプションが必要です(下記参照)。
- ネイティブSNMPバルクリクエスト(GetBulkRequest-PDUs)の最大繰り返し値(デフォルト:10)を指定します。これはSNMPv2およびv3の
discovery[]およびwalk[]アイテムにのみ適用されます。 この値を高く設定しすぎると、SNMPエージェントのチェックタイムアウトが発生する場合がありますのでご注意ください。 - Use combined requestsチェックボックスをマークすると、SNMPリクエストの複合処理が許可されます(ネイティブSNMPバルクリクエスト"walk"および"get"とは無関係です)。
| 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の認証情報(セキュリティ名、認証プロトコル/パスフレーズ、プライバシープロトコル)が間違っている場合:
- Privacy passphraseが間違っている場合を除き、Zabbixはnet-snmpからERRORを受信します。Privacy passphraseが間違っている場合、Zabbixはnet-snmpからTIMEOUTエラーを受信します。
- SNMPインターフェースの可用性は赤(利用不可)に切り替わります。
Authentication protocol、Authentication passphrase、Privacy protocolまたはPrivacy passphraseをSecurity nameを変更せずに変更した場合、対応するSNMPv3インターフェースがZabbixで更新されると通常自動的に適用されます。 Security nameも変更した場合は、すべてのパラメータが即座に更新されます。
自動的に一連のアイテムを追加する提供済みのSNMPテンプレートのいずれかを使用できます。テンプレートを使用する前に、ホストと互換性があることを確認してください。
追加をクリックしてホストを保存します。
プライバシープロトコルのサポート
オペレーティングシステムや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:
出力に--enable-blumenthal-aesが含まれていれば、AES192+がサポートされています。
なお、net-snmp-configはSNMPの開発パッケージ（Debian/Ubuntuではlibsnmp-dev、CentOS/RHEL/OL/SUSEではnet-snmp-devel）の一部であり、デフォルトではインストールされていない場合があります。
snmpget:
出力に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-PDUs）を非同期で使用します。 このアイテムのタイムアウト設定は、アイテム設定フォームで設定できます。デバイスに到達できない場合に長い遅延を避けるため、低いタイムアウト値を設定することを検討してください。タイムアウトや失敗が発生した場合、最大5回までリトライされます（例：3秒のタイムアウトの場合、最大15秒待機することになります）。 このアイテムをマスターアイテムとして使用し、依存アイテムで前処理を使ってデータを抽出することができます。 1回のsnmpwalkで複数のOIDを指定することが可能です。例えば walk[OID1,OID2,...]のように指定すると、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が使用されます。バルクリクエストの最大繰り返し数はインターフェースレベルで設定します。 最大繰り返し数パラメータは、1回のバルク応答で返されるOIDの最大数を決定します。 値が大きいほどバルク応答が大きくなり、必要な通信回数が減ります。ただし、すべてのデバイスが非常に大きな値をサポートしているわけではなく、問題が発生する可能性があります。 このアイテムは、snmpwalkユーティリティの-Oe -Ot -Onパラメータ付きの出力を返します。 このアイテムをSNMPディスカバリのマスターアイテムとして使用できます。 get[OID] - 単一の値を非同期で取得します。 例: get[1.3.6.1.2.1.31.1.1.1.6.3]このアイテムのタイムアウト設定は、アイテム設定フォームで設定できます。デバイスに到達できない場合に長い遅延を避けるため、低いタイムアウト値を設定することを検討してください。タイムアウトや失敗が発生した場合、最大5回までリトライされます（例：3秒のタイムアウトの場合、最大15秒待機することになります）。 OID - （レガシー）単一のテキストまたは数値OIDを入力して、1つの値を同期的に取得します。他の値と組み合わせることも可能です。 例: 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ユーティリティを使用できます:
例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アイテム
- 動的インデックスを持つ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ウォーク中に部分的なデータが受信された場合、アイテムがサポート対象外になることがあります。