автообнаружение портов микротика и действия с ними

[Fatym]

Добрый день
Установил новый Zabbix 3.4.8. Воспользовался встроенным шаблоном для мониторинга микротиков. В этом шаблоне есть автообнаружение интерфейсов и сбор информации по ним. Но мне не надо собирать инфу по интерфейсам Operstatus которых down, поэтому в обнаружении внес изменения в строку SNMP OID

discovery[{#SNMPVALUE},1.3.6.1.2.1.2.2.1.8,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFNAME},1.3.6.1.2.1.31.1.1.1.1,{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFTYPE},1.3.6.1.2.1.2.2.1.3,[B]{#IFOPERSTATUS},1.3.6.1.2.1.2.2.1.8][/B]

Теперь порты со статусом down исключаются из обнаружения. Триггер только что "упавшего" интерфейса светится в дашборде, но светится он минуту, а потом висит со статусом "Решено".
Как сделать чтоб триггер "упавшего" интерфейса висел до решения проблемы?

[Kos]

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

[Fatym]

С другой стороны Вы правы, подумаю что я хочу)

[Fatym]

Спасибо за ответ))
При добавлении устройства и подключении шаблона к нему, начинает отрабатывать обнаружение интерфейсов. Допустим микротик имеет два ethernet порта в состоянии UP а 8 в состоянии Down. В дальнейшем к физическим портам ничего подключаться не будет, следовательно мне по ним информация не нужна, но так же есть 10 впн подключений, которые находятся в состоянии UP, в случае "падения" одного из них, хотелось бы видеть триггер в дашборде, что проблема существует.
Если это не получится сделать, то буду думать что то другое, просто хотел поинтересоваться, может кто сталкивался с таким "странным" желанием)))

[Kos]

1) На самом деле, не вполне понятно, что именно у Вас там происходит.
Вы пишете, что триггер уже через минуту переходит в состояние "решено". Вряд ли это результат работы правил обнаружения, т.к. правила обнаружения влияют только на само наличие триггера как такового, а не на его состояние; да и вряд ли триггер удалялся бы сразу же (если только для правила обнаружения параметр "Keep lost resources period (in days)" не выставлен в ноль).
Скорее всего, проблема в Вашем триггере. Покажите, пожалуйста, как выглядит его формула - станет понятнее.

2) С другой стороны, не очень понятно, зачем Вам для Ваших задач именно {#IFOPERSTATUS}. Вроде же, есть штатная вещь - {#IFADMINSTATUS}, который у за-disable-енных портов отличается. Принудительно сделали disable неиспользуемым портам - они и не мониторятся. Или я чего-то не понимаю? В конце концов, можно в фильтр правила автообнаружения прописать регулярное выражение, в котором явно описать набор портов для мониторинга по имени или описанию ({#IFNAME}/{#IFALIAS}) раз уж они у Вас в правиле LLD присутствуют.

3) Непонятно, зачем в правило LLD один и тот же OID 1.3.6.1.2.1.2.2.1.8 добавлять дважды под разными макросами (сначала как {#SNMPVALUE}, а потом - как {#IFOPERSTATUS}).

[Fatym]

все оказалось проще)))
надо было заставить мозг работать хоть чуть-чуть))
Решение "из коробки" переводит состояние триггера через минуту, убрал все что мне не надо было и получил такое выражение

{$IFCONTROL:"{#IFNAME}"}=1 and ({gw.omikron.pro:net.if.status[ifOperStatus.{#SNMPINDEX}].last()}=2)

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