Этот элемент данных выполняет один обход SNMP-таблицы и возвращает все записи таблицы в одном запросе в формате, соответствующем выводу утилиты snmpwalk с параметрами форматирования -Oe -Ot -On.

Он вернет следующее многострочное текстовое значение:

.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 добавьте шаг предобработки с именем "SNMP walk to JSON" в выпадающем списке Name с 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"
    }
]

Каждый объект представляет один обнаруженный датчик и предоставляет такие макросы, как {#SNMPINDEX}, {#SENSORNAME}, {#SENSORTYPE} и {#SENSORVALUE}.

Они группируются по индексу SNMP, который является числовым суффиксом в конце каждого OID (например, .1, .2) — этот индекс уникально идентифицирует каждую строку в SNMP-таблице и автоматически извлекается как {#SNMPINDEX}.

4. Внутри правила обнаружения создайте один или несколько прототипов элементов данных (с правилом обнаружения в качестве master item).

Например, зависимый элемент данных значения датчика:

В поле Name введите "Sensor {#SNMPINDEX}: {#SENSORNAME}".
В поле Type выберите "Dependent item".
В поле Key введите "sensor.value[{#SNMPINDEX}]".
В поле Master item выберите "SNMP walk item".

На вкладке Preprocessing добавьте шаг предобработки с именем "SNMP walk value" и OID ".1.3.6.1.4.1.9999.1.1.1.1.3.{#SNMPINDEX}" в поле Parameter. 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 walk master-элемента данных с помощью предобработки, не выполняя собственных отдельных SNMP-запросов.

5. Ссылайтесь на прототипы зависимых элементов данных в прототипах триггеров, используя те же макросы из правила обнаружения. Пример:

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

Это создает триггер для каждого обнаруженного датчика (например, sensor.value[1], sensor.value[2]) и срабатывает, если последнее значение (температуры или влажности) превышает 75.

6. Включите зависимые элементы данных для каждой обнаруженной сущности. Пример ключа элемента графика:

sensor.value[{#SNMPINDEX}]

Для каждого {#SNMPINDEX} создается один график, отображающий температуру и влажность во времени.

Эта конфигурация выполняет только один запрос SNMP walk за цикл опроса, независимо от количества обнаруженных элементов данных. Все зависимые элементы данных извлекают свои значения из результата master SNMP walk с помощью предобработки, что значительно снижает SNMP-трафик и нагрузку.

Динамические индексы с walk[]

Динамические индексы (например, индексы интерфейсов) могут смещаться при изменении конфигурации оборудования. Чтобы учесть такое поведение, создается правило обнаружения master 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" с OID "1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}" в поле Parameter. Format: "Unchanged".

Во время выполнения создаются фактические элементы данных, такие как net.if.in[2] и net.if.in[3]. Если индекс заданного интерфейса изменяется (например, если индекс 2 заменяется на 5 в таблице SNMP), то при следующем выполнении правила обнаружения:

Старый зависимый элемент данных net.if.in[2] помечается как "lost" или удаляется, и новые данные для этого элемента данных больше не собираются.
Создается новый зависимый элемент данных 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-трафика — требуется только один SNMP walk за цикл опроса, а прототипы зависимых элементов данных извлекают необходимые значения.

Обнаруженные сущности

Когда сервер запущен, он создаст реальные зависимые элементы данных, триггеры и графики на основе значений, которые возвращает правило обнаружения SNMP.

What’s next?

5 Обнаружение OID SNMP (устаревшее)

Docs

4 Обнаружение SNMP OID-ов

Обзор

Пример конфигурации

Динамические индексы с walk[]

Обнаруженные сущности

What’s next?

Suggest edit

Suggest an example

Thank you!