Как организовать правильный триггер?

[gdgsoft]

Вопрос собственно вот в чем…

Есть оборудование, которое может отдавать аварии по SNMP через snmpwalk. На оборудовании в MIB дереве отображаются аварии по:
1) Полке;
2) По состоянию модулей в слотах;
3) По портам.

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

Вопрос в том, как ПРАВИЛЬНО обрабатывать аварии с такого оборудования для последующего их отображения во всех менюшках?

1. Дело в том, что если для каждого аварийного сообщения создать свой ITEM и TREGGER, то эти аварии нормально можно обрабатывать в самом ZABBIX-е. Например, через внешний скрипт прохожусь snmpwalk-ом. Смотрю, какие аварии присутствуют и соответственно в те ITEM-ы кидаю считанные данные (или для красоты 1). В остальные ITEM-ы кидаю 0. Таким образом взвожу и гашу триггеры. Такие аварии нормально отображаются в Monitoring -> Triggers и Monitoring -> Events. В Monitoring -> Latest Data уже есть некоторые неудобства, т.к. если мне нужно посмотреть историю состояния порта, а у меня на нем может быть порядка 100 ошибок, то мне нужно посмотреть весь список ITEM-ов, все 100 строк (статус каждой аварий). А для просмотра в графическом виде нужно просмотреть 100 графиков (Прим.: т.к. для каждого порта у меня создано 100 ITEM-ов (по количеству аварий) и на каждом элементе весит 1 TRIGGER). Суммарно по портам получается (100 ITEM + 100 TRIGGER)* Количество Портов, а их может быть 60. Получается очень громосткая конфигурация, по которой еще неудобно в Latest Data ковыряться(просмотр периодичности возникновения аварии в графическом виде).
2. Оптимальным вариантом является на каждый порт: 1 ITEM + 100 TRIGGER, а при использовании Value Mapped, наверное, вообще можно обойтись схемой: 1 ITEM + 1 TRIGGER. Но вот вопрос, какой вид должна иметь данная конфигурация как для элемента, так и для триггера(-ов)?
Проблем с ITEM нет, он как был «классическим» таким и остается.
Вопрос скорее по триггеру(-ам). Мои рассуждения таковы:
а) Устройство может иметь несколько активных аварий на каждом уровне (пункты «1)», «2)», «3)»). В зависимости от количества аварий в ветке MIB будет такое же количество записей. Я прохожу по ним скриптом и собираю все, что мне нужно. В результате получаю несколько значений, которые мне нужно передать конкретному элементу. Передаю…
б) Для взведения триггер настроен как обычно. Получил нужное значение – взвелся. Пришло, например, 3 значения -> сработало 3 триггера -> засветилось 3 аварийных сообщения. Все замечательно!
в) В какой-то момент времени одна авария из трех уходит и, как следствие, записи о ней в MIB дереве оборудования исчезают. Как погасить такой триггер? Ведь он висит на том же элементе что и два других, и, запихнув в этот элемент НУЛЬ (например), я погашу и два других. Как вариант, выход в том, чтобы в условии триггера еще делать проверку «nodata». Если данные не поступают, то триггер выключается по истечении какого-то времени. Это проверено и работает. Казалось бы, идеальный случай Но вопрос вот в чем.

При такой конфигурации в меню Monitoring -> Triggers и Monitoring -> Events происходит нормальное отображение аварийного сообщения. В Monitoring -> Latest Data (режим Value) будут данные только о том, в какие моменты аварии возникали, но ни слова о том, когда ушла(т.к. элемент получает данные только во время возникновения аварии). А график будет в виде сплошной линии по той же причине.

Поэтому и возник вопрос о том, как сделать правильный триггер, да и вообще конфигурацию для описанного выше случая, что бы и овцы целы и волки сыты. Я имею ввиду нормальное отображение аварий, в моем случае, во всех менюшках Monitoring -> Triggers, Monitoring -> Events, Monitoring -> Latest Data (как в виде текста, так и графика). Умом понимаю, что режим Latest Data предназначен как раз для просмотра последних значений, но все же, можно ли сделать то что мне нужно.

Спасибо. Надеюсь написал не запутанно.

[dima_dm]

Я бы решил проблему так:
1) Расположил аварии по иерархическому дереву, возможно, что потребуется несколько деревьев. Т.е. если вылетел слот, то очевидно, что не работают и все порты на этой плате и т.д. И информация о нерабочих портах лишена практического смысла.
2) Создал Value Mapped с описанием этих аварий
3) Создать текстовые поля
OK – все хорошо
port1 port10 – список через разделитель аварийных элементов, я обычно использую пробел. Так наглядней поле в рассылках выглядит. И хорошей идеей будет сортировка элементов. Т.е. чтобы не было
port1 port10
port10 port1
Т.е. авария не изменилась, а строка при сравнении изменилась.

[gdgsoft]

Я бы решил проблему так:
1) Расположил аварии по иерархическому дереву, возможно, что потребуется несколько деревьев. Т.е. если вылетел слот, то очевидно, что не работают и все порты на этой плате и т.д. И информация о нерабочих портах лишена практического смысла.
2) Создал Value Mapped с описанием этих аварий

Имеется ввиду указать зависимости триггеров? Мне кажется это немного не то.
Меня больше интересует вариант, что бы можно было посмотреть историю аварий в графическом виде на порту (режим LatestValue), что бы было видно время ее возникновения и ухода. Так легче глазами искать моменты, когда были проблемы. В то время, когда в ITEM приходят данные только о возникновении аварии, и нет ни одного сообщения о ее "уходе" (потому что нет данных на самом оборудовании).

[dima_dm]

Имеется ввиду указать зависимости триггеров? Мне кажется это немного не то.
Меня больше интересует вариант, что бы можно было посмотреть историю аварий в графическом виде на порту (режим LatestValue), что бы было видно время ее возникновения и ухода. Так легче глазами искать моменты, когда были проблемы. В то время, когда в ITEM приходят данные только о возникновении аварии, и нет ни одного сообщения о ее "уходе" (потому что нет данных на самом оборудовании).

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

Авария
{Template_prebilling:gpCollect.txt[junipers,GET_SNMP].count(3600,"OK","eq")}=0
Изменение списка аварийных элементов
{Template_prebilling:gpCollect.txt[junipers,GET_SNMP].count(3600,"OK","eq")}=0 & {Template_prebilling:gpCollect.txt[junipers,GET_SNMP].diff()}=1

График, к сожаленью, по таким элементам не построишь, но всю историю хорошо видно.

[zalex_ua]

Как вариант, выход в том, чтобы в условии триггера еще делать проверку «nodata». Если данные не поступают, то триггер выключается по истечении какого-то времени. Это проверено и работает. Казалось бы, идеальный случай Но вопрос вот в чем.

У меня особое отношение к «nodata» сложилось и мое скромное мнение таково, что эту функцию стоит использовать только там где вы периодически получаете цифровое значение и вам нужно отловить момент если они перестали поступать. По отношению к "историческим" данным (разработчики используют это понятие например говоря о логах - а у вас "похожая" ситуация) я не рекомендовал бы увлекаться этой функцией. Можно кое что пропустить важное и т.д.
Не забывайте что каждый триггер, который содержит «nodata» пересчитывается заббикс сервером каждых 30 секунд (по дефолту) и может возникнуть вопрос производительности. Кстати то же самое по функциям ('nodata','date','dayofweek','time','now') - они тоже высчитываются каждых 30 сек и об этом нигде в доке не сказано, а стоило бы упомянуть.