Привязка snmp-трапов к шаблонам.

[megahertz0]

Добрый день! Почитав форум, вроде бы научил заббикс обрабатывать snmp-трапы. Но проблема в том, они просто валятся в одну кучу на узел snmptrapper и необходимо на каждый трап каждого хоста писать отдельный триггер. Можно ли как-то привязать трапы к шаблонам наблюдаемых хостов?

[inform11]

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

[gdgsoft]

inform11,
а Вас или вашу дежурную смену не смущает, что когда валится линк к железке и потом востанавливается, вы получаете кучу сообщений на несколько страниц?

В общем это конечно субъективный момент, что лучше, но на мой взгляд обработка трапов это более правильных подход, нежели грузить железку по SNMP.
А что касается потери пакетов, так ведь можно написать скрипт-синхронизатор, который будет синхронизировать состояние портов (например) и пихать в Заббикс только данные по тем портам, состояние которых изменилось. Тогда и в "Latest data" будет более красивая картина. Можно будет сразу увидеть, когда какой порт поменял состояние, а не наблюдать по всем портам время последнего обновления и в случае необходимости ковыряться в "истории" данных.
Дополнительно на скрипт можно возложить любой другой функционал позволяющий улучшить логику работы с оборудованием, например, перед тем как полезть на железку, можно дернуть нагрузку на её процессор и если она достаточно высокая, то состояние портов, или еще что то, не снимать и т.д.

Понятно, что часть из этих вещей можно возложить на сам Заббикс, но это все нюансы ...

[inform11]

валится линк к железке и потом востанавливается, вы получаете кучу сообщений на несколько страниц?

ни чего подобного не происходит, т.к. если заббих не может получить данные из за чего либо, то триггер переходит в состояние НЕИЗВЕСТНО, а это не тоже самое что ПРОБЛЕМА, и сообщения на эту сработку не приходят.
Встречный вопрос: а вас не смущает что трап к вам не прилетит, и сломаный канал (железка) так и не останется НЕЗАМЕЧЕННЫМ заббихом?
по моему это намного бОльшая проблема, ибо система мониторинга, которая не надежно отлавливает события, к которой нужно прикручивать всякие скрипты-синхронизаторы и еще всякую дребедень - не есть хорошо и надежно. но выбор только за Вами.
Конечно здесь еще не маловажный вопрос что мониторится и на скольно важно к примеру включение-выключение порта (канала, интерфейса)
Если порт выключился - значит чел. ушел домой - это одно
А если порт выключился и пол страны ушли домой - это совсем другое )

[gdgsoft]

А если порт выключился и пол страны ушли домой - это совсем другое

Не спорю

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

Вы знаете, такого еще не было (вылезла другая проблема, но мне кажется это трабл Заббикса. Пока собираю информацию) Если трап где то и не доходил, то синхронизатор быстро подхватывал это дело. Обычно я ставлю синхроизатор на 5 и 15 минут для коровского и пользовательского оборудования, этого хватает, плюс пингалка.

Мне кажется, что такой вариант меньше грузит сам zabbix_server (так как итемы "zabbix_trapper" и следовательно меньше очереди), БД(в нее меньше пишется данных, правда читается больше).

В общем, вопрос субъективный

а это не тоже самое что ПРОБЛЕМА, и сообщения на эту сработку не приходят.

хм... основное окно, которое я использую для мониторинга: "Monitoring"->"Triggers". вчера отвалился идин УПС на пару минут. С него снимается 17 параметров и настроено 28 триггеров. Так вот когда доступ восстановился я получил на экране порядка 28 триггеров со статусом "OK", естественно триггеров "PROBLEM" не было.

Если в подобных ситуациях у вас иная реакция Заббикса, подскажите как Вам удалось это сделать, т.к. настройки элементов для работы по SNMP я делал почти 2 года назад, то может что то уже поменялось в этом направлении, а я проспал

Спасибо.

[dima_dm]

хм... основное окно, которое я использую для мониторинга: "Monitoring"->"Triggers". вчера отвалился идин УПС на пару минут. С него снимается 17 параметров и настроено 28 триггеров. Так вот когда доступ восстановился я получил на экране порядка 28 триггеров со статусом "OK", естественно триггеров "PROBLEM" не было.

Судя по подписи, у вас Zabbix 1.8.8.
"Monitoring"->"Triggers"
Проверил, все показывает. Проблемы сгруппированы по триггерам, если нажать +, то раскрывается вся история перехода триггера в разные состояния.

[gdgsoft]

Судя по подписи, у вас Zabbix 1.8.8.
"Monitoring"->"Triggers"
Проверил, все показывает. Проблемы сгруппированы по триггерам, если нажать +, то раскрывается вся история перехода триггера в разные состояния.

Вы наверное имели ввиду, что в фильтре, в поле "Events" выбрано что ли бо кроме "Hide all", и тогда слева, напротив каждой записи стоит знак "+", которые разворачивает все события? Это я знаю.

При разговоре с inform11 я имел ввиду то, что когда отваливаются хосты, то проверки по SNMP продолжают работать и когда до них доходит очередь, то из-за отсутствия доступа к железу они падают в состояние "UNKNOWN" (inform11 тоже это наверное имел ввиду). Потом доступ к железу восстанавливается, элементы по SNMP получают значения, триггера переходят в статус "OK"/"PROBLEM" и на экран в результате вываливаются все триггера, которые сконфигурированы для данного хоста.
Если в луче, который отвалился (пусть на минуту) стоит 5 железок по 24 порта, то в результате активного опроса оборудования (я имею ввиду проверки SNMP) мы получим 5*24*2=240 аварийных сообщения (я снимаю операционное и административное состояние порта, поэтому умножаю на 2), а это 5 страниц с алармами.

Для удобства у себя использую фильтр для триггеров:
Trigger status: PROBLEM
Acknowledge status: With unacknowledged events
Event: Hide all
Min severity: All

Это чуть ли не основной момент, почему я отказался от SNMP проверок в конфигурации Zabbix, а потом уже "расширил" подход при мониторинге состояний портов на оборудовании.
Да, мониторинг состояния портов (да и всего остального) через трапы имеет свои недостатки, но на мой взгляд, он предпочтительнее SNMP-проверок в Zabbix, без которых, кстати, тяжело обойтись при мониторинге "небольших" устройств.

Все вышесказанное суровое и бескомпромисное ИМХО.

[megahertz0]

И все таки, может быть кто-нибудь расскажет про привязку трапов к шаблонам?:d

[gdgsoft]

отвлеклись

Да вроде можно. На форуме есть скрипт, который подключается к демону snmptrapd.
Когда ловится трап, демон лезет в БД и смотрит по IP имя хоста в Zabbix-е и послылает элементу, описанному в шаблоне (вроде snmptraps), все трапы от этого хоста. Шаблон вешается на все хосты. Вот и все. Нюанс в том, что все трапы от одной железки валятся в один элемент.

Что бы было красиво, можете переделать скрипт таким образом, чтобы он разбирал полученный трап, выделял в нем данные, в соответствии с которыми у вас созданы элементы в Zabbix и посылал в них то, что вас интересует. Потом этот шаблон (если оборудование разнотипное то шаблоны) цепляются на соответствующие хосты.

Вот и все

[zalex_ua]

Добрый день! Почитав форум, вроде бы научил заббикс обрабатывать snmp-трапы. Но проблема в том, они просто валятся в одну кучу на узел snmptrapper и необходимо на каждый трап каждого хоста писать отдельный триггер. Можно ли как-то привязать трапы к шаблонам наблюдаемых хостов?

И все таки, может быть кто-нибудь расскажет про привязку трапов к шаблонам?:d

Читаем:
http://www.zabbix.com/documentation/...types/snmptrap

Наслаждаемся и ждем выхода релиза 2.0