Использование snmpindex в зависимости от snmpvalue

[fractal90]

Использую шаблон мониторинга оптических трансиверов (сигнал RX/TX)

в дисковери у меня:

discovery[{#SNMPVALUE},1.3.6.1.2.1.47.1.1.1.1.2] с фильтром {#SNMPVALUE}=Tx|Rx Power Sensor

snmpwalk отдает их так

SNMPv2-SMI::mib-2.47.1.1.1.1.2.1374 = STRING: "subslot 0/1 transceiver 3 Tx Power Sensor"
SNMPv2-SMI::mib-2.47.1.1.1.1.2.1375 = STRING: "subslot 0/1 transceiver 3 Rx Power Sensor"​

я хотел бы сделать свой прототип, отдельно для TX / RX в одном правиле обнаружения, чтобы в тригер восстановления добавить правило, если RX=-40 и TX=-40 то тригер должен уйти, можно ли как то сделать элемент зависящий от своего SNMVALUE

допустим правило

discovery[{#SNMPVALUE},1.3.6.1.2.1.47.1.1.1.1.2] с фильтрами:
{#SNMPVALUE_TX}=Tx Power Sensor
{#SNMPVALUE_RX}=Rx Power Sensor

и для них элементы данных?

на данный момент у меня создан элемент данных с snmp OID 1.3.6.1.4.1.9.9.91.1.1.1.1.4.{#SNMPINDEX}

[Kos]

Честно говоря, не совсем понятно, что именно вы хотите сделать.
Но если предположить, что для одного правила обнаружения нужно создать несколько отличающиеся объекты (разные элементы данных или разные триггеры), то это нынче делается с помощью замещений (LLD overrides, ссылка).

[Fractal1990]

Мне надо чтобы при отключении порта триггер восстанавливался, я могу это провернуть когда элемент на tx получит значение -40, но snmpindex для элементов rx/tx разные на разном железе.
Логика у меня сейчас такая, я нашёл элементы с snmpvalue RX/TX, и создал прототип элемента данных который согласно snmpindex создает два элемента, один для rx, второй для tx, когда на sfp модуле в коммутаторе не подключён оптический патчкорд я получаю значение "-40", ну и меня авария выходит, что правильно, так как это может быть обрыв, неисправность, tx значение я получаю допустим "3.5dbm" ,далее я отключаю порт на оборудование, tx становится "-40" ,вот в этом случае я бы хотел иметь триггер который проверяет, rx = "-40" и tx = "-40" значит можно аварию убрать, но вот как это провернуть когда у меня один прототип элемента данных для rx/tx не ясно

[Kos]

Fractal1990, отвечайте, пожалуйста, отдельным сообщением, а не комментарием к чужому сообщению.

Я всё равно не очень понимаю, что именно Вы хотите сделать.

Вы дали пример вывода snmpwalk для OID-а 1.3.6.1.2.1.47.1.1.1.1.2:

SNMPv2-SMI::mib-2.47.1.1.1.1.2.1374 = STRING: "subslot 0/1 transceiver 3 Tx Power Sensor"
SNMPv2-SMI::mib-2.47.1.1.1.1.2.1375 = STRING: "subslot 0/1 transceiver 3 Rx Power Sensor"​​

OK, в данном случае правило обнаружения "discovery[{#SNMPVALUE},1.3.6.1.2.1.47.1.1.1.1.2]" найдёт объекты, для которых индекс (макрос {#SNMPINDEX}) будет равен 1374 (для Tx Power Sensor) и 1375 (для Rx Power Sensor).

Далее пишете, что создаёте "элемент данных с snmp OID 1.3.6.1.4.1.9.9.91.1.1.1.1.4.{#SNMPINDEX}".
На самом деле это только прототип элемента данных, на его базе должны будут созданы два элемента данных - с OID-ами:

• 1.3.6.1.4.1.9.9.91.1.1.1.1.4.1374
• 1.3.6.1.4.1.9.9.91.1.1.1.1.4.1375

Это то, что вам нужно? Если нет, то что нужно-то? Распишите поподробнее, пожалуйста.

[fractal90]

Fractal1990, отвечайте, пожалуйста, отдельным сообщением, а не комментарием к чужому сообщению.

Я всё равно не очень понимаю, что именно Вы хотите сделать.

Вы дали пример вывода snmpwalk для OID-а 1.3.6.1.2.1.47.1.1.1.1.2:

SNMPv2-SMI::mib-2.47.1.1.1.1.2.1374 = STRING: "subslot 0/1 transceiver 3 Tx Power Sensor"
SNMPv2-SMI::mib-2.47.1.1.1.1.2.1375 = STRING: "subslot 0/1 transceiver 3 Rx Power Sensor"​​

OK, в данном случае правило обнаружения "discovery[{#SNMPVALUE},1.3.6.1.2.1.47.1.1.1.1.2]" найдёт объекты, для которых индекс (макрос {#SNMPINDEX}) будет равен 1374 (для Tx Power Sensor) и 1375 (для Rx Power Sensor).

Далее пишете, что создаёте "элемент данных с snmp OID 1.3.6.1.4.1.9.9.91.1.1.1.1.4.{#SNMPINDEX}".
На самом деле это только прототип элемента данных, на его базе должны будут созданы два элемента данных - с OID-ами:

• 1.3.6.1.4.1.9.9.91.1.1.1.1.4.1374
• 1.3.6.1.4.1.9.9.91.1.1.1.1.4.1375

Это то, что вам нужно? Если нет, то что нужно-то? Распишите поподробнее, пожалуйста.

Так я же так и написал, у меня сейчас прототип который создает два разных элемента которые отличаются только по snmpindex (на разных портах snmpindex разный) и проблема именно с тригером, так как создаются два элемента на основе одного прототипа я не могу сделать тригер с операцией восстановления вида 1.3.6.1.4.1.9.9.91.1.1.1.1.4.1374 = -40 and 1.3.6.1.4.1.9.9.91.1.1.1.1.4.1375 = -40

Вот и думаю а можно ли это как то победить

[fractal90]

Fractal1990, отвечайте, пожалуйста, отдельным сообщением, а не комментарием к чужому сообщению.

Я всё равно не очень понимаю, что именно Вы хотите сделать.

Вы дали пример вывода snmpwalk для OID-а 1.3.6.1.2.1.47.1.1.1.1.2:

SNMPv2-SMI::mib-2.47.1.1.1.1.2.1374 = STRING: "subslot 0/1 transceiver 3 Tx Power Sensor"
SNMPv2-SMI::mib-2.47.1.1.1.1.2.1375 = STRING: "subslot 0/1 transceiver 3 Rx Power Sensor"​​

OK, в данном случае правило обнаружения "discovery[{#SNMPVALUE},1.3.6.1.2.1.47.1.1.1.1.2]" найдёт объекты, для которых индекс (макрос {#SNMPINDEX}) будет равен 1374 (для Tx Power Sensor) и 1375 (для Rx Power Sensor).

Далее пишете, что создаёте "элемент данных с snmp OID 1.3.6.1.4.1.9.9.91.1.1.1.1.4.{#SNMPINDEX}".
На самом деле это только прототип элемента данных, на его базе должны будут созданы два элемента данных - с OID-ами:

• 1.3.6.1.4.1.9.9.91.1.1.1.1.4.1374
• 1.3.6.1.4.1.9.9.91.1.1.1.1.4.1375

Это то, что вам нужно? Если нет, то что нужно-то? Распишите поподробнее, пожалуйста.

сейчас мое правило lld такого вида

[Kos]

Так я же так и написал, у меня сейчас прототип который создает два разных элемента которые отличаются только по snmpindex (на разных портах snmpindex разный) и проблема именно с тригером, так как создаются два элемента на основе одного прототипа я не могу сделать тригер с операцией восстановления вида 1.3.6.1.4.1.9.9.91.1.1.1.1.4.1374 = -40 and 1.3.6.1.4.1.9.9.91.1.1.1.1.4.1375 = -40

Вот и думаю а можно ли это как то победить

То есть, элементы данных из прототипа создаются нужные, проблема только в триггере?

В любом случае, если триггер должен учитывать состояние нескольких созданных обнаружением однотипных элементов данных, то его уже правилом обнаружения не создать. Нужно искать другой подход, например - использовать вычисляемый элемент данных, использующий с функцию агрегации.
В вашем примере на устройстве создаются два (интересующих вас) элемента данных, но в общем случае - правилом LLD их может быть создано сколько угодно. Или их всегда будет именно два?

[Fractal1990]

То есть, элементы данных из прототипа создаются нужные, проблема только в триггере?

В любом случае, если триггер должен учитывать состояние нескольких созданных обнаружением однотипных элементов данных, то его уже правилом обнаружения не создать. Нужно искать другой подход, например - использовать вычисляемый элемент данных, использующий с функцию агрегации.
В вашем примере на устройстве создаются два (интересующих вас) элемента данных, но в общем случае - правилом LLD их может быть создано сколько угодно. Или их всегда будет именно два?

Да, Вы правы, элементы создаются верные,и да правилом lld будет создано по 2 элемента данных для каждого оптического трансивера установленного в сетевое железо. Вот если бы можно было бы элементы разделить, то есть сделать в одном правиле discovery два прототипа элементов данных каждый для своего snmpindex, что то вида, если в snmpvalue обнаружен TX то создаём элемент с snmpindex от TX, если в snmpvallue обнаружен RX то создаём элемент с snmpindex от RX

[MasterHome]

Да, Вы правы, элементы создаются верные,и да правилом lld будет создано по 2 элемента данных для каждого оптического трансивера установленного в сетевое железо. Вот если бы можно было бы элементы разделить, то есть сделать в одном правиле discovery два прототипа элементов данных каждый для своего snmpindex, что то вида, если в snmpvalue обнаружен TX то создаём элемент с snmpindex от TX, если в snmpvallue обнаружен RX то создаём элемент с snmpindex от RX

Фильтры помогут? В value искать регулярным выражением нужное совпадение.

[Kos]

Да, Вы правы, элементы создаются верные,и да правилом lld будет создано по 2 элемента данных для каждого оптического трансивера установленного в сетевое железо.

То есть, их может быть и больше двух, но всегда парами?

Вот если бы можно было бы элементы разделить, то есть сделать в одном правиле discovery два прототипа элементов данных каждый для своего snmpindex, что то вида, если в snmpvalue обнаружен TX то создаём элемент с snmpindex от TX, если в snmpvallue обнаружен RX то создаём элемент с snmpindex от RX

А вот эта задача, как раз, решается с помощью LLD overrides (замещений), о которых я упоминал в своём первом комментарии.

[fractal90]

То есть, их может быть и больше двух, но всегда парами?
.

Да, всегда парами

А вот эта задача, как раз, решается с помощью LLD overrides (замещений), о которых я упоминал в своём первом комментарии.
.

Буду пробовать после апдейта на версию 6 тогда

[fractal90]

Фильтры помогут? В value искать регулярным выражением нужное совпадение.

а что это даст? индекс то разный

[Kos]

Да, всегда парами

В таком случае, всё же, триггеры тоже нужно будет создавать правилом обнаружения - по триггеру на каждую пару.
Или, как вариант, ссылаться в триггере на дополнительный вычисляемый элемент данных, который создавать на каждую пару свой, использующий функцию агрегации (минимум/максимум или среднее - как вам лучше) для этой пары, выбирая значения по тегам. А тегами помечать каждую пару, например, по её интерфейсу ("subslot 0/1 transceiver 3"). А чтобы такой элемент данных создавать только для одного элемента данных из пары, то как раз с помощью замещения указать, что создавать его нужно только, например, если {#SNMPVALUE} содержит подстроку "Tx Power Sensor".

[fractal90]

В таком случае, всё же, триггеры тоже нужно будет создавать правилом обнаружения - по триггеру на каждую пару.

сейчас так и сделано, тригеры работают, но пока нет возможности сделать чтобы восстановление было в том случае когда оба элемента отдают значение -40

вот так наверное понятнее будет

обнаружились элементы 1 и 3 по правилу LLD, далее тригер смотрит, параметр 1 >= 2 - выходит авария, возможно неисправность SFP трансивера или обрыв ВОЛС, Восстановление по 1 < 2, то же самое и когда 3 >= 4 выдает аварию, и 3 < 4 восстановление. А теперь я решил что все нормально, я просто отключаю линки от трансиверов, при этом параметр 2 становится равным -40 dBm, вот тут мне надо чтобы тригер проверял 1= -40 + 3 = -40 значит все нормально, можно восстановить

[Kos]

сейчас так и сделано, тригеры работают, но пока нет возможности сделать чтобы восстановление было в том случае когда оба элемента отдают значение -40

Тут проблема в том, что в прототипе такого триггера в формуле восстановления нужно написать выражение, которое ссылается не только на прототип текущего элемента данных (для которого создаётся этот триггер и на который можно сослаться при помощи макроса {#SNMPINDEX}), но также и на прототип "соседнего" элемента данных (индекс которого нам недоступен).

То есть, для вашего примера, где

sensor.sfp.power.rx.tx[1374] = subslot 0/1 transceiver 3 Tx Power Sensor
sensor.sfp.power.rx.tx[1375] = subslot 0/1 transceiver 3 Rx Power Sensor

нужно в триггере для Rx в формуле восстановления получить формулу:

last(sensor.sfp.power.rx.tx[1374]) = -40 and last(sensor.sfp.power.rx.tx[1375]) = -40

Но при работе правила обнаружения для Rx в прототипе триггера макрос {#SNMPINDEX} будет раскрываться в значение "1375"; а макроса, который бы при этом раскрывался в значение "1374", нет. Тогда остаётся вариант - его создать самостоятельно.
Это можно сделать двумя способами.

Способ 1: "ручной привод". Используем пользовательские макросы с контекстом, значения которых для каждого хоста и каждой пары интерфейсов прописываем вручную.
Скажем, для вышеприведённого примера создаём макрос {$TXINDEX:"1375"} и назначаем ему значение "1374", тогда в формуле прототипа триггера можно указать:

last(sensor.sfp.power.rx.tx[{#SNMPINDEX}]) = -40 and last(sensor.sfp.power.rx.tx[{$TXINDEX:"{#SNMPINDEX}"}]) = -40

Понятно, что это неудобно и чревато ошибками, но при небольшом количестве устройств и портов может оказаться вполне рабочим вариантом.

Способ 2: модификация исходного JSON-а, используемого правилом LLD, чтобы добавить в него нужные LLD-макросы.
Добавляем в правило LLD шаг предобработки с типом "JavaScript" (причём, добавляем его не для отдельных прототипов, а именно для самого правила).
На входе ему будет передаваться строка с JSON-ом, содержащим для каждого датчика LLD-макросы {#SNMPINDEX} и {#SNMPVALUE}.
Задача этого JavaScript-а - к строкам для датчиков Rx (которые можно опознать по {#SNMPVALUE}) добавить ещё третий макрос - скажем, {#SNMPINDEX_TX}, который бы содержал {#SNMPINDEX} соответствующего Tx-датчика.
Для этого нужны некоторые навыки программирования на JavaScript, но это не очень сложно. И нужна версия Zabbix, поддерживающая такую предобработку (начиная с версии 6.0 - точно можно, более ранние - надо уточнять).

(добавлено)
А какая у вас версия Zabbix?
Посмотрел на приаттаченный экпорт-файл - судя по формату триггерных формул, явно меньше, чем 5.4; но какая именно?

[fractal90]

А какая у вас версия Zabbix?
Посмотрел на приаттаченный экпорт-файл - судя по формату триггерных формул, явно меньше, чем 5.4; но какая именно?

старая еще, 4.0.6, понемногу переезжаем на 6 LTS, до конца февраля сетевую часть мониторинга перенесем. Способ 2 мне видится более приемлемым, так как минимально на одной железке могут быть от 2 до 48 трансиверов, к каждому по 2 элемента. с Javascript для меня точно сложнее но есть команды которые в нем разбираются, помогут