Zabbix trapper и триггеры

[OKyHb]

Приветствую.

Зашёл в тупик с настройкой триггеров для айтемов типа "Zabbix trapper", необходима помощь сообщества.

На текущий момент принимаем snmp трапы "link up/down" с коммутаторов через snmptrapd и snmptt. В zabbix-server их отравляет snmptt в таком виде:

EVENT linkUp .1.3.6.1.6.3.1.1.5.4 "Physics" Normal
EXEC /usr/bin/zabbix_sender -z 127.0.0.1 -p 10051 -s $r -k link_trap -o "Port $1 - UP"

EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Physics" Normal
EXEC /usr/bin/zabbix_sender -z 127.0.0.1 -p 10051 -s $r -k link_trap -o "Port $1 - DOWN"

В zabbix-server для каждого коммутатора создан один айтем "link_trap" (тип Zabbix trapper). И триггер такого типа:

{Template_Juniper_EX:link_trap.nodata(120)}=0

И незамысловатым названием "{ITEM.LASTVALUE}"

Падает один порт - всё ок. Приходит snmp трап, загорается триггер, приходит уведомление в jabber. Через 2 минуты триггер гаснет. Всё просто.
Но если падается/поднимается сразу несколько портов за короткий интервал - получаю только один горящий триггер и одно уведомление в джаббер. Что плохо.

Как бы переделать схему, чтобы на каждый порт получать отдельный триггер? Или хотя бы отдельное уведомление в джаббер. Пока в голову приходит только создавать по отдельному айтему на каждый порт - но это реально геморно. Особенно если учесть, что есть ещё логические интерфейсы - которые то создаются, то удаляются.

[Jimson]

Я не понял что там за логические интерфейсы у коммутатора, знаю только SVI и им подобные, но они сами собой не "то создаются, то удаляются".
Но задачу нормально можно сделать только отдельным элементом данных на каждый интерфейс. Тут есть несколько моментов, на которые стоит обратить внимание
1) крайне полезно и удобно пользоваться LLD при мониторинге сетевых устройств
2) отсылка трапа на несуществующий итем никакого вреда не наносит, так что если вы отошлете трап относящийся к интерфейсу "vlan" или "Gi 0/3.456", то пофик, забикс просто проигнорирует эти данные
3) итем сможете передать в числовой, сможете график активности смотреть, по трендам, правда, чушь получится, но всяко лучше чем текстовые данные да еще и по всем портам в одном итеме. А еще числовые данные занимают гораздо меньше место и с ними быстрее работать.
4) как следствие (3) вы, возможно, сможете избавится от ресурсоемкой nodata()
5) вы сможете добавить еще один итем данные по которому будут собираться по SNMP, тот же linkup/down, в качестве подстраховки от пропаданий трапов

[OKyHb]

Логические интерфейсы - да, SVI. Просто у того же Juniper они чаще называются IFL.
Хотя, наверно, пока мониторить их не надо.

Действительно, без создания отдельного айтема на каждый интерфейс не обойтись Вначале ещё надеялся, что получится через какой-то хитрый триггер с "nodata + diff". Но как только триггер загорается, на остальное ему пофиг.

[yukra]

Логические интерфейсы - да, SVI. Просто у того же Juniper они чаще называются IFL.
Хотя, наверно, пока мониторить их не надо.

Действительно, без создания отдельного айтема на каждый интерфейс не обойтись Вначале ещё надеялся, что получится через какой-то хитрый триггер с "nodata + diff". Но как только триггер загорается, на остальное ему пофиг.

Не пофиг, ибо есть как минимум гистерезис и его можно принудительно выключить, а потом в том же триггере через OR снова поднять есть он выключен, а последнее и предпоследнее значение отличаются, а статус выключен (во всяком случае на первый взгляд кажется что такое может сработать), но нужно проверят что оно действительно сработает, нужно будет городить какую то здоровую формулу.

В общем как сказал Jimson смотрите в сторону lld, делайте 5 прототипов айтемов: скорость (входящая + исходящая), pps (так же 2 шт), и статус порта (может быть еще админ-статус), привязывайте шаблон к нужным железкам, через фильтр отсекайте лишние интерфейсы, и радуйтесь красивым графикам и понятным триггерам.