2 SNMPエージェント

概要

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レスポンスを受信した場合、以下のようなログが記録されます。

ホスト "gateway" からのSNMPレスポンスには、要求されたすべての変数バインディングが含まれていません。

このログは、すべての問題となるケースをカバーしているわけではありませんが、バルクリクエストを無効にすべき
個々のSNMPデバイスを特定するのに役立ちます。

Zabbix server / proxy は、SNMPライブラリの再試行メカニズム、または内部のbulk processingメカニズムにより、クエリに失敗した後、少なくとも1回再試行します。

SNMPモニタリングの設定

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

Step1

監視する item のSNMPストリング(またはOID)を見つけます。

SNMPストリングのリストを取得するには、snmpwalkコマンドを使用します
net-snmp ソフトウェア(Zabbixの一部としてインストールされているはずです)を使用します。
または同等のツールを使用します。

shell> snmpwalk -v 2c -c public <ホストIP>

2cはSNMPのバージョンを表し、次のように置き換えることもできます。
'1' に置き換えて、デバイスの SNMP バージョン 1 を表します。

これにより、SNMP文字列とその最後の値のリストが表示されるはずです。
もしSNMPの 'community' が標準の 'public' と異なっている可能性があり、その場合、それが何であるかを確認する必要があります。

例えば、ポート3のスイッチに入ってくるパケットを監視したい場合、次の行から IF-MIB::ifInOctets.3 という文字列を使用します。 この行にある

IF-MIB::ifInOctets.3 = Counter32: 3409739121

これで、snmpgetコマンドを使用して、「IF-MIB::ifInOctets.3」の数値OIDを確認することができます。
'IF-MIB::ifInOctets.3'の数値OIDを調べるために、snmpgetコマンドを使用します。

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

これにより、以下のようなものが得られるはずです。

.1.3.6.1.2.1.2.1.10.3 = Counter32: 3472126941

繰り返しますが、OIDの最後の数字がポート番号です。

上記の例では、値のタイプは "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 より多くの情報が必要です (下記をご参照ください)
    
• SNMPリクエストのバルクリクエストを可能にするため、Use bulk requestsのチェックボックスをマークしたままにします。
  

SNMPv3の認証情報(security name , authentication protocol/passphrase , privacy protocol)が間違っている場合、
Zabbixはnet-snmpからERRORを受け取ります。
ただし、Privacy passphraseが間違っている場合、Zabbixはnet-snmpからTIMEOUTエラーを受信します。

提供されている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は数値または文字列形式で指定できることに注意してください。 ただし、文字列OIDを数値表現に変換する必要があることがあり、そのような場合はsnmpgetユーティリティが使用できます。

shell> snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0

例2

稼働時間の監視 :

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" 設定があり、そのインターフェースで
そのデバイスのバルクリクエストを無効化することができます。