Documentation
Table of Contents
2 SNMPエージェント
概要
プリンター、ネットワークスイッチ、ルーター、UPSなど、一般にSNMPが使用でき、完全なオペレーティングシステムやZabbixエージェントのセットアップを行うことが実用的でないデバイスでは、SNMP監視を使用できます。
こうしたデバイスでSNMPエージェントが提供するデータを取得できるようにするには、ZabbixサーバがSNMPをサポートするように最初に設定する必要があります。
SNMPチェックは、UDPプロトコルだけで実施されます。
SNMPv3デバイスを監視する場合、絶対にmsgAuthoritativeEngineID（snmpEngineIDまたは「Engine ID」とも呼ばれる）を2つのデバイスで共用しないでください。各デバイスで固有でなければなりません。
SNMPv3認証やプライバシーのみのMD5やDESプロトコルがサポートされていた場合、Zabbix 2.2からは、SHA認証やAESプライバシープロトコルもサポートされています。
Zabbix 2.2から、Zabbixサーバおよびプロキシデーモンは、SNMPチェックを実施する際、タイムアウト設定パラメータを正しく使用します。さらに、デーモンは、SNMPリクエストが1つでも失敗すると（タイムアウト/不正証明）、リトライを実施しません。以前は、SNMPライブラリのデフォルトのタイムアウトおよびリトライの各値（それぞれ1秒およびリトライ5回）が、実際に使用されていました。
Zabbix2.2.3から、Zabbixサーバおよびプロキシデーモンは、SNMPデバイスに問い合わせを行い、1回のリクエストで複数の値を要求します。これは、全種類のSNMPアイテム（通常のSNMPアイテム、ダイナミックインデックスを持つSNMPアイテム、SNMPローレベルディスカバリ）も同様で、これにより、SNMPの処理はより効率的になります。内部の動作については、以下の技術的な詳細を参照してください。
SNMP監視の設定
SNMPによるデバイスの監視を開始するには、次のステップを実施する必要があります。
ステップ 1
SNMPインターフェースを備えるデバイスに対して、ホストを作成 します。
IPアドレスを入力します。ホストのステータスを「無効」に設定します。用意されているSNMPテンプレート（テンプレートSNMP Device など）のうち1つを使用できます。これは、自動的にアイテム一式を追加します。ただし、このテンプレートは、ホストに対して互換性がない場合があります。
SNMPチェックは、エージェントポートを利用せずにチェックをします。
ステップ 2
監視対象アイテムのSNMP文字列（またはOID）を検出します。
SNMP文字列のリストを取得するには、次のように、snmpwalkコマンド（net-snmpソフトウェアの一部で、Zabbixインストールの一部としてインストールされます）または同等のツールを使用します。
ここで、「2c」はSNMPのバージョンを表しています。「2c」を｢1」で置き換えて、そのデバイスにSNMPバージョン1を指定することもできます。
これにより、SNMP文字列とその最新の値のリストが得られます。得られない場合、SNMPコミュニティが標準の「public」とは異なっている可能性がありますので、コミュニティ名を確認してください。
続いて、リストから監視したい文字列を探します。例えば、3番ポートのスイッチに着信するバイト数を監視したい場合は、次の行からIF-MIB::ifInOctets.3の文字列を使用します。
ここで、次のようにsnmpgetコマンドを使用して、「IF-MIB::ifInOctets.3」に対する数値のOIDを調べることができます。
文字列の最後の数字が、監視しようとしているポート番号であることに注意してください。 ダイナミックインデックスも参照してください。
これにより、次のようなものが得られます。
ここでも、OIDの最後の数字がポート番号です。
3COMでは、1番ポートを101番ポート、3番ポートを103番ポートのように、100単位のポート番号を使用していますが、Ciscoでは、3番ポートを3のように、そのまま使用しています。
最も使用されているSNMP OIDには、Zabbixにより自動的に数値表現に変換 されるものがあります。
ステップ 3
監視対象アイテムを作成します。
ここで、Zabbixに戻ってアイテムをクリックし、前に作成したSNMPホストを選択します。ホスト作成時にテンプレートを使用したかどうかによって、ホストに関連するSNMPアイテムのリストが表示される場合と、新しいアイテムボックスが表示される場合があります。snmpwalkとsnmpgetを使用して収集したばかりの情報をもとに、自身でアイテムを作成する、という前提で、新しいアイテムボックスの[説明]フィールドに簡単な説明を英語で入力します。[ホスト]フィールドに自分のスイッチ/ルーターが入っていることを確認し、[タイプ]フィールドを「SNMPv* agent」に変更します。コミュニティ（通常は「public」）に値を入力し、前に収集した文字または数値のOIDを[SNMP OID]フィールドに入力します。例： .1.3.6.1.2.1.2.2.1.10.3
[SNMPポート]に161を入力し、[Key]に意味のあるもの、例えば「SNMP-InOctets-Bps」などを入力します。必要に応じて[乗数]を選択し、デフォルトから変更したい場合は、[更新間隔]や[ヒストリの保存]に入力します。[ステータス]を「有効」に、[データ型]を「数値（浮動小数）」に、[保存時の計算]を「差分」（このようにしないと、最新値ではなくSNMPデバイスから累積値を取得してしまうため、注意が必要です）に設定します。
ここで、アイテムを保存し、Zabbixのホスト領域に戻ります。ここから、SNMPデバイスのステータスを「有効」に変更し、自身のSNMPデータについて「最新データ」にチェックを入れます。
例 1
一般的な例：
| パラメータ 説明 | |
|---|---|
| コミュニティ publi | |
| OID | 1.2.3.45.6.7.8.0 (または .1.2.3.45.6.7.8.0) |
| キー & | t;トリガーが参照する固有の文字列> 例えば、「my_param」。 |
OIDは、数値と文字列どちらの書式でも指定できることに注意してください。ただし、場合によっては、文字列のOIDを数値表現に変換しなければならないことがあります。このために、ユーティリティsnmpgetを使用できます。
Zabbixソースの設定で--with-net-snmpフラグを指定していれば、SNMPパラメータを監視することができます。
例 2
アップタイムの監視：
| パラメータ 説明 | |
|---|---|
| コミュニティ publi | |
| Oid | MIB::sysUpTime.0 |
| キー r | uter.uptime |
| 値のタイプ 浮動小数 | |
| 単位 u | time |
| 乗数 0 | 01 |
一括処理の内部での動作
Zabbix2.2.3から、Zabbixサーバおよびプロキシは、SNMPデバイスに問い合わせ、1回のリクエストで複数の値を要求します。これは、SNMPアイテムのうち次のいくつかのタイプに同様に作用します。
- 通常のSNMPアイテム
- ダイナミックインデックスを持つSNMPアイテム
- SNMPローレベルディスカバリルール
単一のインターフェース上の全SNMPアイテムは、同時に問い合わせを受けるようにスケジュールされています。最初の2タイプのアイテムは、最大で128アイテムの一括処理の中でポーラーとして受け取られますが、ローレベルディスカバリルールは、これまでどおり個別に処理されます。
より低いレベルでは、値を問い合わせるために実施される2種類の操作があります。複数の指定オブジェクトの取得とOIDツリーの移動です。
「取得」については、最大128個のvariable bindingsフィールドを備えた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が続くアイテム一括処理のために行うことは、最後に成功した変数の個数（この例では28個）から開始して、限界に当たるまでリクエストのサイズを1つずつ増やし続けていくことです。例えば、最大の応答サイズを変数32個と仮定すると、それに続くリクエストのサイズは、29、30、31、32、33となります。失敗をもって最後のリクエストとし、Zabbixはサイズが33個のリクエストを再び発することはありません。このポイントから、Zabbixは、このデバイスに対しては必ず、変数32個の問い合わせを行うようになります。
本ページは2014/08/05時点の原文を基にしておりますので、内容は必ずしも最新のものとは限りません。
最新の情報は、英語版のZabbix2.2マニュアルを参照してください。