SNMP OID の検出

概要

このセクションでは、SNMPデバイスでローレベルディスカバリを実行します。

SNMP OIDのこのディスカバリ方法は、Zabbixサーバー/プロキシ6.4からサポートされています。

サンプル設定

1. 次のようなキーを使用して、SNMP エージェントアイテムを作成します。

walk[.1.3.6.1.4.1.9999.1.1.1.1]

このアイテムは、1 回の SNMP テーブルウォークを実行し、1 つのリクエストですべてのテーブルエントリを返します。形式は、-Oe -Ot -On オプションを指定した snmpwalk ユーティリティの出力に対応します。

次の複数行のテキスト値を返します。

.1.3.6.1.4.1.9999.1.1.1.1.1.1 = STRING: "Temperature Sensor"
.1.3.6.1.4.1.9999.1.1.1.1.2.1 = STRING: "temp"
.1.3.6.1.4.1.9999.1.1.1.1.3.1 = 100
.1.3.6.1.4.1.9999.1.1.1.1.1.2 = STRING: "Humidity Sensor"
.1.3.6.1.4.1.9999.1.1.1.1.2.2 = STRING: "humidity"
.1.3.6.1.4.1.9999.1.1.1.1.3.2 = 200

2. ディスカバリルールを作成します。

  • Name フィールドに、説明的なディスカバリルール名(例: "センサーを検出")を入力します。
  • Type フィールドで、"Dependent item" を選択します。
  • Key フィールドに、説明的なキー(例: "net.if.discovery")を入力します。
  • Master item フィールドで、"SNMP walk item" を選択します。

3. Preprocessing タブで、Name ドロップダウンから "SNMP walk to JSON" を選択し、3 つのパラメータを持つ前処理ステップを追加します。

  • Field name: "{#SENSORNAME}"; OID prefix: ".1.3.6.1.4.1.9999.1.1.1.1.1": Format: "Unchanged"。
  • Field name: "{#SENSORTYPE}"; OID prefix: ".1.3.6.1.4.1.9999.1.1.1.1.2": Format: "Unchanged"。
  • Field name: "{#SENSORVALUE}"; OID prefix: ".1.3.6.1.4.1.9999.1.1.1.1.3": Format: "Unchanged"。

前処理後、ディスカバリルールはマクロセットの JSON 配列を返します。

例:

[
    {
        "{#SNMPINDEX}": "1",
        "{#SENSORNAME}": "Temperature Sensor",
        "{#SENSORTYPE}": "temp",
        "{#SENSORVALUE}": "100"
    },
    {
        "{#SNMPINDEX}": "2",
        "{#SENSORNAME}": "Humidity Sensor",
        "{#SENSORTYPE}": "humidity",
        "{#SENSORVALUE}": "200"
    }
]

各オブジェクトは検出された 1 つのセンサーを表し、{#SNMPINDEX}、{#SENSORNAME}、{#SENSORTYPE}、{#SENSORVALUE} などのマクロを提供します。

これらは SNMP インデックスによってグループ化されます。SNMP インデックスは各 OID の末尾にある数値のサフィックス(例: .1、.2)です。このインデックスは SNMP テーブル内の各行を一意に識別し、{#SNMPINDEX} として自動的に抽出されます。

4. ディスカバリルールの下に、1 つ以上のアイテムプロトタイプ(ディスカバリルールをマスターアイテムとして使用)を作成します。

例: センサー値の依存アイテム:

  • Name フィールドに、"Sensor {#SNMPINDEX}: {#SENSORNAME}" と入力します。
  • Type フィールドで、"Dependent item" を選択します。
  • Key フィールドに、"sensor.value[{#SNMPINDEX}]" と入力します。
  • Master item フィールドで、"SNMP walk item" を選択します。

Preprocessing タブで、Parameter フィールドに ".1.3.6.1.4.1.9999.1.1.1.1.3.{#SNMPINDEX}" OID を指定し、"SNMP walk value" という名前の前処理ステップを追加します。
Format: "Unchanged"。

次のアイテムが検出されます。

Name Key OID from which value is extracted Item value
Sensor 1: Temperature Sensor sensor.value[1] .1.3.6.1.4.1.9999.1.1.1.1.3.1 100
Sensor 2: Humidity Sensor sensor.value[2] .1.3.6.1.4.1.9999.1.1.1.1.3.2 200

ディスカバリルールが実行されると、sensor.value[1]、sensor.value[2] などのアイテムが作成されます。

各依存アイテムは、それ自体で個別の SNMP リクエストを実行せず、前処理を使用してマスターアイテムの SNMP ウォーク結果から値を抽出します。

5. ディスカバリルールと同じマクロを使用して、トリガープロトタイプで依存アイテムプロトタイプを参照します。
例:

{Template_Sensor:sensor.value[{#SNMPINDEX}].last()} > 75

これにより、検出された各センサー(例: sensor.value[1]、sensor.value[2])に対してトリガーが作成され、最新の値(温度または湿度)が 75 を超えると発火します。

6. 検出された各エンティティの依存アイテムを含めます。
グラフアイテムキーの例:

sensor.value[{#SNMPINDEX}]

{#SNMPINDEX} ごとに 1 つのグラフが作成され、温度と湿度の推移が表示されます。

この設定では、検出されたアイテムの数に関係なく、ポーリングサイクルごとに実行される SNMP ウォークリクエストは 1 回だけです。
すべての依存アイテムは、前処理を使用してマスター SNMP ウォーク結果から値を抽出するため、SNMP トラフィックと負荷を大幅に削減できます。

walk[]による動的インデックス

動的インデックス(たとえば、インターフェースインデックス)は、ハードウェアの再構成時に変更されることがあります。 この動作に対応するために、次のようなキーを持つマスターSNMP walkディスカバリールールが作成されます。

walk[1.3.6.1.2.1.2.2.1.10]

SNMP walk to JSONのプリプロセス後、結果は次のようになります。

[
    {
        "{#SNMPINDEX}": "2",
        "{#VALUE}": "123456"
    },
    {
        "{#SNMPINDEX}": "3",
        "{#VALUE}": "654321"
    }
]

従属アイテムプロトタイプは、{#SNMPINDEX}マクロを使用してキーを構築します。

net.if.in[{#SNMPINDEX}]

このプロトタイプのプリプロセスには、「SNMP walk value」名と「1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}」OIDをパラメータフィールドに指定します。 フォーマット:「変更しない」。

実行時には、net.if.in[2]やnet.if.in[3]などの実際のアイテムが作成されます。 特定のインターフェースインデックスが変更された場合(たとえば、SNMPテーブル内のインデックス2が5に置き換えられた場合)、次回のディスカバリールール実行時に以下の動作となります。

  • 古い従属アイテムnet.if.in[2]は「失われた」とマークされるか削除され、そのアイテムの新しいデータは収集されません。
  • 新しい従属アイテムnet.if.in[5]が作成され、履歴は空の状態から開始されます。
  • net.if.in[2]の履歴データは自動的にnet.if.in[5]に移動されません。

トリガープロトタイプの例:

{Template_Interface:net.if.in[{#SNMPINDEX}].last()} > 1000000000

グラフプロトタイプの例(アイテムを含む):

net.if.in[{#SNMPINDEX}]
net.if.out[{#SNMPINDEX}]

この構成により、動的インデックスを持つテーブルの信頼性の高い監視が保証され、SNMPトラフィックも最小限に抑えられます。ポーリングサイクルごとに1回のSNMP walkだけが必要で、従属アイテムプロトタイプが必要な値を抽出します。

検出されたエンティティ

サーバーが実行されると、SNMPディスカバリルールが返す値に基づいて、実際の従属アイテム、トリガー、グラフが作成されます。