Zabbix traps и многократные трапы

[Batonius]

Статья про трапы в документации по версии 2.0 какая-то обрезанная, поэтому, возможно, я что-то недопонял.

Я настроил трап snmptrap[link(Up|Down)] и триггер на него. Предположим, что на коммутаторе отключилось два порта, триггер сработал на linkDown. Но теперь если заработал только один из этих портов, то триггер становится в положение ОК? А как же другой?

И можно ли использовать трапы в низкоуровневом обнаружении? Например, чтобы на каждый порт создался свой трап. У меня не получилось.

[bga83]

все зависит от структуры страпа и того как происходит обработка. Если мне память не изменяет, то при отправке трапа в большинстве случаев указывается и номер порта по которому произошло событие. Соответсвенно можно настроить их как различные трапы и по каждому иметь отдельный триггер.

Или же триггер можно иметь один, но выражение написать таким образом, что он в состояние ОК перейдет только когда все порты будут не в дауне.

[Batonius]

Если мне память не изменяет, то при отправке трапа в большинстве случаев указывается и номер порта по которому произошло событие. Соответсвенно можно настроить их как различные трапы и по каждому иметь отдельный триггер.

Да, до идеи создать различные трапы для каждого порта я тоже додумался. Но мне это кажется не очень красивым. Тем более для шаблонов с автообнаружением. И у оборудования разных производителей порты называются по-разному. Поэтому я и спрашивал ещё и про автообнаружение. Пытался создать трап типа snmptrap[link(Up|Down).*ifIndex.{#SNMPINDEX}], но никаких движений не происходит.

Или же триггер можно иметь один, но выражение написать таким образом, что он в состояние ОК перейдет только когда все порты будут не в дауне.

Спасибо за наводку. Попробую.

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

[Batonius]

Пожалуй, нашёл решение.
Я подправил zabbix_trap_receiver.pl таким образом, чтобы все данные трапа он вываливал в одну строку (для упрощения регэкспа).
В нужном шаблоне в правилах обнаружения создаем прототип элемента данных:
Имя: Trap linkStatus {#SNMPVALUE}
Ключ: snmptrap[link(Up|Down)\.*ifIndex.{#SNMPINDEX}]

Таким образом, при получении трапа создаются новые данные вида Trap linkStatus Ethernet1/1 или Trap linkStatus RMON Port 1.

Ну а дальше уже дело техники. Создаем прототип триггера c выражением: {Template SNMP Network:snmptrap[link(Up|Down)\.*ifIndex.{#SNMPINDEX}].regexp(linkDown)}#0

И вуаля!

[crash]

А можно пример строки которую выдает perl скрипт.

У меня в голове не укладывается следующее: для автообнаружения требуется json строка, а для захвата trap'a нужен свой формат. Как их совместить не понятно

[Batonius]

А можно пример строки которую выдает perl скрипт.

У меня в голове не укладывается следующее: для автообнаружения требуется json строка, а для захвата trap'a нужен свой формат. Как их совместить не понятно

Типа того:

15:17:16 2013/04/19 - ZBXTRAP 192.168.2.80 DISMAN-EVENT-MIB::sysUpTimeInstance=Timeticks: (12297) 0:02:02.97 SNMPv2-MIB::snmpTrapOID.0=OID: IF-MIB::linkUp IF-MIB::ifIndex.9=INTEGER: 9 SNMP-COMMUNITY-MIB::snmpTrapAddress.0=IpAddress: 192.168.2.80 SNMP-COMMUNITY-MIB::snmpTrapCommunity.0=STRING: "public" SNMPv2-MIB::snmpTrapEnterprise.0=OID: SNMPv2-SMI::enterprises.311.1.1.3.1.1

Нас интересуют linkUp и ifIndex.9, т.к. именно на них срабатывает регэксп в ключе триггера.

[crash]

Я пытался отправлять подобную строку, но zabbix ругается на подобный формат. Я не совсем понимаю что именно нужно прописывать в ключе правила обнаружения

[Batonius]

Я пытался отправлять подобную строку, но zabbix ругается на подобный формат. Я не совсем понимаю что именно нужно прописывать в ключе правила обнаружения

Затрудняюсь сказать, в чём дело.
А где ты создаешь этот элемент? Ключ snmptrap[] требует регулярное выражения, т.е. банальный поиск по тексту. Для начала убедись, что zabbix-server принимает и жалуется на неизвестные трапы.