Хитрое создание триггеров

[blah.blah]

Всем привет.

Ситуация такая - есть некоторое количество (20+) роутеров, которые терминируют l2-каналы, и сервер в центре, к которому они подключены этими самыми каналами. На сервере каждый канал - отдельный vlan. На роутерах они в отдельных портах.
Интерфейсы на роутерах дискаверятся по SNMP перловым скриптом, на них навешаны метрики вида ifInOctets.["{#IFINDEX}"], и т.п. Интерфейсы на сервере дискаверятся через net.if.discovery, на них навешаны метрики вида net.if.in[{#IFNAME},bytes], и т.п.

Хочется иметь триггеры, сверяющие показания соответствующих интерфейсов, например, вот так:

(({router:ifOutUcastPkts.["8"].sum(60)}/{server:net.if.in[vlan1134,packets].sum(60)}-1)*100)>10

Создавать все вручную, естессно, не хочется, т.к. роутеров много, и будет еще больше.
Представляется разумным дополнить автообнаружение интерфейсов на роутерах соответствующими триггерами, но возникает два основных затыка:
1. На роутерах по 5 активных интерфейсов, а триггеры нужны только на 2 из них.
2. Как поставить в соответствие конкретный интерфейс роутера конкретному влану на сервере.

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

Буду благодарен за любые идеи.

[yukra]

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

КМК создать прототип триггера без прототипа айтема (в том же дискавери) нельзя, но это нужно проверить.

[blah.blah]

Только что попробовал - в одном шаблоне два дискавери с одинаковым ключом не создаются.
Там такой ключ:

lld.pl["{HOST.CONN}","{$SNMP_PORT}","{$COMMUNITY}"]

Можно, конечно, сделать ll2.pl, но это совсем как-то неправильно.

[sadman]

lld.pl["{HOST.CONN}","{$SNMP_PORT}","{$COMMUNITY}","abcdef"]

А в скрипте на 4-й парамер внимания не обращать.

[blah.blah]

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

[nucleusv]

Как у вас вычисляются соответствия порт на свитче - интерфейс на сервере?

Это статическое человеческое - то есть можно занести в какой то массив таблицу или есть правило?

Я обычно в таких задачах делаю, беру скрипт который что дискаверит потом подгружает массив из файла на выходе общий ЛЛД из которого можно создавать несколько протипов в одном правиле и они будут доступны в прототипах триггера

[Rusya]

Всем привет.

Ситуация такая - есть некоторое количество (20+) роутеров, которые терминируют l2-каналы, и сервер в центре, к которому они подключены этими самыми каналами. На сервере каждый канал - отдельный vlan. На роутерах они в отдельных портах.
Интерфейсы на роутерах дискаверятся по SNMP перловым скриптом, на них навешаны метрики вида ifInOctets.["{#IFINDEX}"], и т.п. Интерфейсы на сервере дискаверятся через net.if.discovery, на них навешаны метрики вида net.if.in[{#IFNAME},bytes], и т.п.

Хочется иметь триггеры, сверяющие показания соответствующих интерфейсов, например, вот так:

(({router:ifOutUcastPkts.["8"].sum(60)}/{server:net.if.in[vlan1134,packets].sum(60)}-1)*100)>10

Создавать все вручную, естессно, не хочется, т.к. роутеров много, и будет еще больше.
Представляется разумным дополнить автообнаружение интерфейсов на роутерах соответствующими триггерами, но возникает два основных затыка:
1. На роутерах по 5 активных интерфейсов, а триггеры нужны только на 2 из них.
2. Как поставить в соответствие конкретный интерфейс роутера конкретному влану на сервере.

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

Буду благодарен за любые идеи.

По первому вопросу, на нужных портах сделать descriptions "Link или UpLink", потом в discovery добавить прототипы ниже.

1. Создаем discovery Uplinks с ключом dIfAlias oid IF-MIB::ifAlias в фильтре указываем макрос {#SNMPVALUE} и матчим @UpLink and Link
2. В Item prototypes создаем прототипы
имя ifInUplink.{#SNMPINDEX} key ifInUplink.["{#SNMPINDEX}"] oid ifInOctets.{#SNMPINDEX}
имя ifOperStatus.{#SNMPINDEX} key ifOperStatus.["{#SNMPINDEX}"] oid ifOperStatus.["{#SNMPINDEX}"]
имя ifOutUplink.{#SNMPINDEX} key ifOutUplink.["{#SNMPINDEX}"] oid ifOutOctets.{#SNMPINDEX}
3. Создаем в Trigger prototypes триггер с именем Link is down ({#SNMPINDEX}) с выражением {Cisco_t:ifOperStatus.["{#SNMPINDEX}"].last(0)}<>1

А по второму вопросу чуть сложнее но тоже думаю решаемо, думаю даже схоже с решением первого вопроса.

[blah.blah]

Как у вас вычисляются соответствия порт на свитче - интерфейс на сервере?

Никак не вычислются. Как оно наросло исторически. Порты на свичах плюс-минус везде одинаковые, интерфейсы на сервере - вланы, как их провайдер отдавал, так они и заведены.

Это статическое человеческое - то есть можно занести в какой то массив таблицу или есть правило?

Правил нет, а вот табличка - неплохая идея.

Я обычно в таких задачах делаю, беру скрипт который что дискаверит потом подгружает массив из файла на выходе общий ЛЛД из которого можно создавать несколько протипов в одном правиле и они будут доступны в прототипах триггера

Да, это идея, подумаю в этом направлении.

По первому вопросу, на нужных портах сделать descriptions "link или uplink", потом в discovery добавить прототипы ниже.

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

[blah.blah]

Значит, прогресс сейчас таков.
Есть два дискавери - один обнаруживает интерфейсы, которым нужны триггеры, другой - те, которым не нужны. Со вторыми все понятно, нас интересуют первые.
Для них корректно создались триггеры на ап/даун интерфейсов, но то, что хотелось сделать изначально - не получается.
Сейчас дискавери возвражает вот такую структуру:

      {
         "{#IFALIAS}":"[MTS][vlan1234]",
         "{#IFDESCR}":"ether2",
         "{#IFINDEX}":"3",
         "{#IFTAGS}":"Type:6,AdminStatus:up,FLAG,",
         "{#IFVLAN}":"vlan1234"
      }

Я пытаюсь создать вот такой прототип триггера:

(({Router_SNMP_LLD:ifOutUcastPkts2.["{#IFINDEX}"].sum(60)}/{server:net.if.in[{#IFVLAN},packets].sum(60)}-1)*100)>10

Я рассчитывал, что заббикс вместо {#IFVLAN} подставит конкретное значение, но он этого не делает на этапе создания прототипа. И поэтому не дает сохранить прототип триггера с ошибкой:

Не удалось раскрыть выражение "(({Router_SNMP_LLD:ifOutUcastPkts2.["{#IFINDEX}"].sum(60)}/{server:net.if.in[{#IFVLAN},packets].sum(60)}-1)*100)>10". В выражении триггера "server" указан некорректный ключ элемента данных "net.if.in[{#IFVLAN},packets]".

Как это обскакать?

Но дальше - больше. Я заменил {#IFVLAN} на реальное значение, и получил следующую ошибку:

Trigger prototype contains item prototypes from multiple discovery rules.

Дело в том, что этот net.if.in - тоже результат дискаверинга интерфейсов.
Как тут быть?

[blah.blah]

Коллеги, у меня скоро закончаться моральные силы.

Попробую еще раз описать ситуацию.
Есть роутер и сервер. Между роутером и сервером есть два L2-канала. Каналы объединены в LACP (broadcast). В каналах нет адресации, адреса есть только на LACP-интерфейсах.
Необходимо мониторить состояние L2-каналов. Т.к. адресации в них нет, то пинг там не погоняешь.
Сейчас мониторится число входящих пакетов на интерфейсах. Если avg(120)=0 - значит что-то не так. В принципе, обнаруживать проблемы такой подход позволяет. Если один из L2-каналов глючит - всплываю два триггера - по одному от роутера и от сервера. Если же проблема серьезнее, то всплывают сразу 7 триггеров - по три с каждой стороны (два L2-канала и один LACP) и плюс еще один на отсутствие пинга до роутера. Если это просуммировать с невозможностью автоматически именовать отдискаверенные устройства - это мрак.
Возможно я куда-то не туда смотрю, или вообще не тем путем пошел...
Вопросы, ответов на которые я для себя пока не нашел:
1. Именование устройств, обнаруженных через сетевое обнаружение. Да, я знаю про PTR, но оно почему-то не работает. На страничке "Состояние обнаружения" напротив каждого устройства в скобочках указано его имя из PTR-записи, но в триггерах, например, оно не отображается.
2. Зависимости между прототипами триггеров - как это сделать? Как сделать, чтоб если порт в дауне не появлялся триггер об отсутствии данных на порту?
3. Высший пилотаж - как сделать прототип триггера, включающий в себя прототипы элементов данных из разных правил обнаружения?
4. Как дать осмысленные имена интерфейсам, обнаруженным через net.if.discovery. Их около 100.