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

Обзор

В этом разделе мы будем выполнять SNMP обнаружение на коммутаторе.

Этот метод обнаружения SNMP OID'ов поддерживается, начиная с Zabbix сервера/прокси версии 6.4.

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

1. Создайте элемент данных агента SNMP с ключом, например:

walk[.1.3.6.1.4.1.9999.1.1.1.1]

Этот элемент данных выполняет один обход таблицы 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, с тремя параметрами:

  • 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. В рамках правила обнаружения создайте один или несколько прототипов элементов данных (с правилом обнаружения в качестве мастер-элемента данных).

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

  • В поле 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 мастер-элемента данных с помощью предварительной обработки, не выполняя отдельные запросы SNMP.

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

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

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

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

sensor.value[{#SNMPINDEX}]

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

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

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

Динамические индексы (например, индексы интерфейсов) могут сдвигаться при изменениях конфигурации оборудования. Чтобы приспособиться к такому поведению, основное правило обнаружения SNMP walk создаётся с ключом таким как:

walk[1.3.6.1.2.1.2.2.1.10]

После предобработки SNMP walk в JSON результат может быть наподобие:

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

Прототип зависимого элемента данных использует макрос {#SNMPINDEX}, чтобы сконструировать свой ключ:

net.if.in[{#SNMPINDEX}]

Предобработка для этого прототипа включает шаг «Значение SNMP walk (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 заменяется в таблице SNMP на 5), то при следующем срабатывании правила обнаружения:

  • Старый зависимый элемент данных 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 на цикл опроса, с прототипами зависимых элементов данных, извлекающих необходимые значения.

Обнаруженные объекты

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