Исправление DRVTiny, (текущая версия) :
Алексей, а есть уже понимание того, что делать с SNMP-трапами?
Хотелось бы видеть список событий на хосте. Метрики и триггеры в данном случае немного совсем не ложатся на логику SNMP-трапов.
Почему? Да очень просто! Я не обязан знать все возможные события на оборудовании и матчить их регекспами - каждое в свою метрику, чтобы всё-таки алармы были тоже индивидуальны. Почему не обязан? А потому что в любом приличном MIB'е этих трапов может быть под несколько сотен штук.
Хотелось бы так: в разделе «SNMP»-проверок хоста задаёшь одно регулярное выражение для матчинга «возникновения проблемы», а другое - для матчинга «завершения проблемы». При этом, например, группировка $1 в регулярном выражении должна совпасть в тексте события-проблемы и события-клиринга, чтобы «проблема» очистилась с хоста.
Тогда на фронтенде может быть список: Monitoring->SNMP->Traps, где будут появляться и очищаться проблемы.
Можно это всё сделать и по аналогии с веб-проверками - тогда просто будут автоматом генерироваться метрики и триггеры к ним.
Вопрос только в том, зачем в принципе трапы матчить на метрики: складывать куски текста из трапов в базу - очень странное занятие, ведь по сути это просто мусор (zabbix - не спланк всё же).
Триггерное решение, предлагаемое сейчас разработчиками в офдокументации - это просто несерьёзно (особенно использование nodata для опускания триггера). По сути это просто намёк на то, что всё нужно делать самому через zabbix-trap'ы и встраивание своего Perl-скрипта в snmptrapd или snmptt - тогда можно будет создавать метрики динамически по мере поступления трапов нового типа.
Исходная версия DRVTiny, :
Алексей, а есть уже понимание того, что делать с SNMP-трапами?
Хотелось бы видеть список событий на хосте. Метрики и триггеры в данном случае немного совсем не ложатся на логику SNMP-трапов.
Почему? Да очень просто! Я не обязан знать все возможные события на оборудовании и матчить их регекспами - каждое в свою метрику, чтобы всё-таки алармы были тоже индивидуальны. Почему не обязан? А потому что в любом приличном MIB'е этих трапов может быть под несколько сотен штук.
Хотелось бы так: в разделе «SNMP»-проверок хоста задаёшь одно регулярное выражение для матчинга «возникновения проблемы», а другое - для матчинга «завершения проблемы». При этом, например, группировка $1 в регулярном выражении должна совпасть в тексте события-проблемы и события-клиринга, чтобы «проблема» очистилась с хоста.
Тогда на фронтенде может быть список: Monitoring->SNMP->Traps, где будут появляться и очищаться проблемы.
Можно это всё сделать и по аналогии с веб-проверками - тогда просто будут автоматом генерироваться метрики и триггеры к ним.
Вопрос только в том, зачем в принципе трапы матчить на метрики: складывать куски текста из трапов в базу: довольно странное занятие, ведь по сути это просто мусор (zabbix - не спланк всё же).
Триггерное решение, предлагаемое сейчас разработчиками в офдокументации - это просто несерьёзно (особенно использование nodata для опускания триггера). По сути это просто намёк на то, что всё нужно делать самому через zabbix-trap'ы и встраивание своего Perl-скрипта в snmptrapd или snmptt - тогда можно будет создавать метрики динамически по мере поступления трапов нового типа.