Documentation
Table of Contents
2 SNMP agent
概要
SNMPモニタリングは、プリンター、ネットワークスイッチ、UPSなど、通常SNMPが有効なデバイスで使用することができます。
OSとZabbix agent のセットアップを行うことは現実的ではありません。
これらの機器のSNMPエージェントが提供するデータを取得することができます。
Zabbix server でinitially configuredを行い、SNMPをサポートする必要があります。
SNMPチェックはUDPプロトコルのみで行われます。
Zabbix server とproxy デーモンは、SNMPデバイスに1回のリクエストで複数の値を問い合わせます。
これは全ての種類のSNMP item(通常のSNMP item、動的インデックスを持つSNMP item、SNMP ローレベルディスカバリ)に影響し、
SNMP処理をより効率的に行えるようになります。
詳しくは、bulk processingセクションを参照してください。
バルクリクエストは、各インターフェイスの ”Use bulk requests" 設定を使用して、
適切に処理できないデバイスのために無効にすることもできます。
Zabbix server と proxy デーモンが不正なSNMPレスポンスを受信した場合、以下のようなログが記録されます。
このログは、すべての問題となるケースをカバーしているわけではありませんが、バルクリクエストを無効にすべき
個々のSNMPデバイスを特定するのに役立ちます。
Zabbix server / proxy は、SNMPライブラリの再試行メカニズム、または内部のbulk processingメカニズムにより、クエリに失敗した後、少なくとも1回再試行します。
SNMPv3デバイスを監視する場合、以下のことを確認してください。
msgAuthoritativeEngineID (snmpEngineID または "Engine ID" とも呼ばれる) が 2 つのデバイスで
共有されていないことを確認してください。RFC2571 (セクション 3.1.1.1)の規定により、
各デバイスで一意である必要があります。
RFC3414では、SNMPv3デバイスがengineBootsを永続化することを要求しています。
一部のデバイスはこれを行わず、その結果、再起動後にそのデバイスのSNMPメッセージは、再起動後に古いメッセージとして破棄されます。
このような場合、server / proxy で SNMP キャッシュを手動でクリアするか（[-R snmp_cache_reload(/manual/concepts/server#runtime_control))
またはサーバー/プロキシを再起動する必要があります。
SNMPモニタリングの設定
SNMPによるデバイスの監視を開始するには、次の手順を実行する必要があります。
Step1
監視する item のSNMPストリング(またはOID)を見つけます。
SNMPストリングのリストを取得するには、snmpwalkコマンドを使用します
net-snmp ソフトウェア(Zabbixの一部としてインストールされているはずです)を使用します。
または同等のツールを使用します。
2cはSNMPのバージョンを表し、次のように置き換えることもできます。
'1' に置き換えて、デバイスの SNMP バージョン 1 を表します。
これにより、SNMP文字列とその最後の値のリストが表示されるはずです。
もしSNMPの 'community' が標準の 'public' と異なっている可能性があり、その場合、それが何であるかを確認する必要があります。
例えば、ポート3のスイッチに入ってくるパケットを監視したい場合、次の行から IF-MIB::ifInOctets.3 という文字列を使用します。 この行にある
これで、snmpgetコマンドを使用して、「IF-MIB::ifInOctets.3」の数値OIDを確認することができます。
'IF-MIB::ifInOctets.3'の数値OIDを調べるために、snmpgetコマンドを使用します。
文字列の最後の数字が、監視対象のポート番号であることに注意してください。
こちらも参照してください。Dynamic indexes
これにより、以下のようなものが得られるはずです。
繰り返しますが、OIDの最後の数字がポート番号です。
3COM は3桁のポート番号を使うようです。
例えばポート1 =ポート101、ポート3＝ポート103のように3桁のポート番号を使うようですが、
Ciscoはポート3＝3のように普通の数字を使います。
最もよく使用されるSNMP OIDのいくつかは、Zabbix によって
translated automatically to a numeric representationで定義されています。
上記の例では、値のタイプは "Counter32" であり、これは内部的にはASN_COUNTERタイプに相当します。
サポートされるタイプの完全なリストは以下のとおりです。
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 and ASN_OBJECT_ID (バージョン 2.2.8, 2.4.3から)
これらのタイプは、おおよそsnmpget のアウトプットの
"Counter32" , "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks",
"Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER"に対応しますが、"STRING"、"Hex-STRING", "OID "などと
表示されることもあります。これらは表示ヒントの有無によって異なります。
Step 2
Create a host は、デバイスに対応します。
ホストのSNMPインタフェースを追加します:
- IPアドレス/DNS名とポート番号を入力します。
- ドロップダウンからSNMPバージョンを選択します。
- 選択したSNMPのバージョンに応じて、インターフェイスの認証情報を追加します。
- SNMPv1, v2 community のみが必要です(一般的には 'public')
- SNMPv3 より多くの情報が必要です (下記をご参照ください)
- SNMPv1, v2 community のみが必要です(一般的には 'public')
- SNMPリクエストのバルクリクエストを可能にするため、Use bulk requestsのチェックボックスをマークしたままにします。
| SNMPv3 パラメータ | 説明 |
|---|---|
| Context name | Enter context name to identify item on SNMP subnet. Context name is supported for SNMPv3 items since Zabbix 2.2. User macros are resolved in this field. |
| Security name | Enter security name. User macros are resolved in this field. |
| Security level | Select security level: noAuthNoPriv - no authentication nor privacy protocols are used AuthNoPriv - authentication protocol is used, privacy protocol is not AuthPriv - both authentication and privacy protocols are used |
| Authentication protocol | Select authentication protocol - MD5, SHA1, SHA224, SHA256, SHA384 or SHA512. |
| Authentication passphrase | Enter authentication passphrase. User macros are resolved in this field. |
| Privacy protocol | Select privacy protocol - DES, AES128, AES192, AES256, AES192C (Cisco) or AES256C (Cisco). |
| Privacy passphrase | Enter privacy passphrase. User macros are resolved in this field. |
SNMPv3の認証情報(security name , authentication protocol/passphrase , privacy protocol)が間違っている場合、
Zabbixはnet-snmpからERRORを受け取ります。
ただし、Privacy passphraseが間違っている場合、Zabbixはnet-snmpからTIMEOUTエラーを受信します。
Authentication protocol、Authentication passphrase、Privacy protocol、Privacy passphraseを変更します。
server / proxy 上のキャッシュが有効になった後、キャッシュが手動でクリアされた後（-R snmp_cache_reload)、server/proxyが再起動された場合、 または
Security name が変更された場合、すべてのパラメータが即座に更新されます。
提供されているSNMPテンプレート（Template SNMP Deviceなど）を使用すると、
一連の項目が自動的に追加されます。ただし、テンプレートはホストと互換性がない場合があります。
Addをクリックすると、ホストが保存されます。
Step 3
監視のためのアイテムを作成します。
Zabbixに戻り、先ほど作成したSNMPホストの item をクリックします。
ホストを作成する際にテンプレートを使用したかどうかによって、ホストに関連するSNMPアイテムのリストが表示されます。
または空のリストが表示されます。ここでは、snmpwalk と snmpget を使用して収集した情報を使用して、
自分でアイテムを作成することを前提に作業を進めますので、Create item をクリックします。
新しいアイテムのフォームで:
- item 名を入力します。
- 'Type'フィールドを 'SNMP agent' に変更します。
- 'Key' に何か意味のあるもの、例えば SNMP-InOctets-Bps を入力します。
- 'Host interface' フィールドにお使いのスイッチ/ルーターがあることを確認します。
- 'SNMP OID'フィールドに、先ほど取得したテキストまたは数値のOIDを入力します（例： .1.3.6.1.2.1.2.1.10.3）
- 'Type of information' をNumeric (float)に設定します。
- '更新間隔' と '履歴の保存期間' をデフォルトと異なる値にしたい場合は、入力します。
- Preprocessing* タブで、Change per second のステップを追加します。
(重要。さもないと、SNMPデバイスから最新の変更ではなく、累積値を取得することになります)
必要な場合は、カスタム乗数を選択します。
すべての必須入力フィールドには、赤いアスタリスクが表示されます。
アイテムを保存して、Monitoring → Latest data でSNMPのデータを確認します。
例1
一般的な例:
| パラメータ | 説明 |
|---|---|
| OID | 1.2.3.45.6.7.8.0 (or .1.2.3.45.6.7.8.0) |
| Key | <Unique string to be used as reference to triggers> For example, "my_param". |
OIDは、数値でも文字列でも指定できることに注意。ただし、文字列のOIDを数値表現に変換する必要がある場合がある。
このような場合には、snmpgetユーティリティを使用することができる。
Zabbixのソース設定時に--with-net-snmpフラグが指定されている場合、SNMPパラメータの監視が可能です。
例2
稼働率のモニタリング
| パラメータ | 説明 |
|---|---|
| OID | MIB::sysUpTime.0 |
| Key | router.uptime |
| Value type | Float |
| Units | uptime |
| Multiplier | 0.01 |
Native SNMP bulk requests
The walk[OID1,OID2,...] item allows to use native SNMP functionality for bulk requests (GetBulkRequest-PDUs), available in SNMP versions 2/3.
A GetBulk request in SNMP executes multiple GetNext requests and returns the result in a single response. This may be used for regular SNMP items as well as for SNMP discovery to minimize network roundtrips.
The SNMP walk[OID1,OID2,...] item may be used as the master item that collects data in one request with dependent ityems that parse the response as needed using preprocessing.
Note that using native SNMP bulk requests is not related to the option of combining SNMP requests, which is Zabbix own way of combining multiple SNMP requests (see next section).
バルクリクエストの内部動作
Zabbix 2.2.3以降 Zabbix server と proxy は、SNMP機器に対して1回のリクエストで複数の値を問い合わせることができます。
これはいくつかのタイプのSNMP item に影響します。
- 通常の SNMP items
- SNMP items with dynamic indexes
- SNMP low-level discovery rules
同一のパラメータを持つ単一インターフェース上のすべてのSNMPアイテムが
同時にクエリされるようにスケジュールされます。
最初の2種類のアイテムは、ポーラーによって最大128アイテムのバッチで取得されますが、
ローレベルディスカバリ発見ルールは、従来通り個別に処理されます。
下位レベルでは、以下の2種類のオペレーションが実行されます。
複数の指定されたオブジェクトを取得することと、OIDツリーを walk することです。
"get" については、最大128個の変数バインディングを持つGetRequest-PDUが使用されます。
walking では、SNMPv1ではGetNextRequest-PDUを、SNMPv2およびSNMPv3では、
最大128の "max-repetitions" フィールドを持つGetBulkRequestを使用します。
各SNMP item タイプにおけるバルクリクエストのメリットを示します。
- 通常のSNMPアイテムの場合、"get" の改善によるメリットがあります。
- 動的インデックスを持つSNMPアイテムの場合、"get"と "walk" の両方の改善効果があります。
"get"はインデックスの検証に、"walk" はキャッシュの構築に使用されます。 - SNMPのローレベルディスカバリールールは、"walk"の改善により恩恵を受けます。
ただし、すべてのデバイスがリクエストごとに128の値を返せるわけではないという技術的な問題があります。
あるものは常に適切なレスポンスを返します。しかし、他のデバイスは、"tooBig(1) "エラーで応答するか、
または、潜在的な応答が "tooBig" を超えると、まったく応答しないというエラーになったり、
ある限界値を超えると全く反応しなくなったりします。
特定のデバイスに対して問合せを実行する最適なオブジェクト数を見つけるために、
Zabbixは次のような戦略をとっています。慎重に開始し1つのリクエストで1つの値を問合せます。
それが成功した場合、リクエストで2つの値を問合せます。再び成功した場合、リクエストで3つの値を問合せます。
というように、問い合わせるオブジェクトの数を1.5倍にしていきます。その結果、リクエストの大きさは次のようになります。
1,2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128
しかし、デバイスが適切なレスポンスを拒否した場合(例えば、42変数の場合)、Zabbixは2つのことを実行します。
まず、現在の item バッチでは、1回のリクエストでオブジェクトの数を半分にし、21個の変数を問合せます。
デバイスが生きている場合、28変数が動作することが知られており、21はそれよりもかなり少ないからです。
しかし、それでも失敗した場合、Zabbixは値を1つずつクエリすることに戻ります。
この時点でまだ失敗する場合、デバイスは確実に応答しておらず、リクエストサイズは問題ではありません。
Zabbixが2つ目に行うことは、後続のアイテムバッチに対して、最後に成功した変数のサイズ(この例では28)から開始し
限界に達するまで、リクエストサイズを1ずつ増やし続けます。
例えば、最大のレスポンスサイズが32変数であると仮定すると、後続のリクエストはサイズ29,29,29となります。
それ以降のリクエストは29、30、31、32、33のサイズになります。
最後のリクエストは失敗し、Zabbixはサイズ33のリクエストを発行することはありません。
この時点から、Zabbixはこのデバイスに対して最大32個の変数を問い合わせることになります。
この変数のサイズで大きな問合せが失敗する場合、次の2つの意味があります。
デバイスが応答サイズを制限するために使用する正確な基準を知ることはできませんが、
私たちは変数のサイズを使用してそれを近似しようとします。
つまり、第1の可能性は、この変数のサイズが一般的な場合、デバイスの実際のレスポンスサイズ制限の範囲ギリギリであること。
2つ目の可能性は、どちらかの方向のUDPパケットが単に紛失した可能性です。
これらの理由から、Zabbixは失敗したクエリを取得した場合、デバイスの快適な範囲に深く入ろうとするため、変数の最大数を減らします。
ただし、最大2回までです。(Zabbix 2.2.8から)
上記の例では、32個の変数を持つクエリがたまたま失敗した場合、Zabbixはカウントを31に減らします。
そのクエリも失敗した場合、Zabbixはカウントを30に減らします。
しかし、Zabbixはカウントを30以下に減らすことはありません。
なぜなら、それ以上の障害はUDPパケットの損失によるものと判断されるからです。
しかし、デバイスが他の理由でバルクリクエストを適切に処理できない場合、
Zabbix 2.4以降では、各インターフェースに "Use bulk requests" 設定があり、そのインターフェースで
そのデバイスのバルクリクエストを無効化することができます。