Как в Zabbix свернуть «партянку» триггеров на основной панели «20 событий»?

Question

[Thomas Andersen]

Мне необходимо убрать большую партянку из триггеров, высыпающих на основную панель заббикса, где отображаются "последние 20 событий". Нам бы хотелось видеть оптимальную, полную картину происходящего, но половину экрана занимают триггеры такие как "заканчивающееся место на диске".
Вопрос, как произвести консолидацию таких множественных триггеров, имеющих общую суть, но относящихся к разным устройствам? В иделале предположим хотелось бы видеть общую картину по проблемам и к примеру видеть один большой триггер типа "На некоторых серверах заканчивается место" и уже ткнув на него, перейти в более подробный вид , где можно было бы уже ознакомиться с тем на каких конкретно железках заканчивается место.
P.S. Пример с "местом на диске", лишь пример, имеются различные события схожие по сути но имеющие отношение к разным устройствам. Хочется на главное панели видеть суть, а не события по каждой железке, как это лучше всего реализовать.

Версия Zabbix 3.2.1 , Спасибо!

Answer 1

[Александр]

Не надо смотреть на триггера в виде списка. Надо смотреть триггера и другие события на сервисно-ресурсной модели(СРМ).
Обычно есть регламент. В котором прописано в какой срок необходимо устранить инцидент(Созданный автоматически после срабатывания триггера). Если у вас срабатывают триггеры по которым никто ничего не собирается делать, то отключайте этот триггер на тех системах, на которых он не актуален. Ну в крайнем случае пусть триггеры имеют уровень критичности как информационные.
Наиболее оптимальный и сложный поход:
1) Определить сервисы.
2) Разработать триггеры и определить события для каждого компонента сервиса.
Какой конфигурационный элемент, пороги, кого уведомлять, тексты уведомлений, критичность и др.
3) Разработать СРМ
4) Разработать корреляцию при необходимости. Разработать правила как меняется статус вышестоящих элементов СРМ.
5) Задокументировать
6) Протестировать
7) Внедрить

Админы видят свои инциденты на сервис деск. В инциденте есть ссылка на СРМ, на которой видны те области за которые админ не отвечает, но влияют на его область ответственности.
А еще есть регламенты - как ставить на мониторинг сервисы, кто за что отвечает, кто контролирует исполнение процессов, как устанавливать SLA, как выводить из эксплуатации и т.п. Есть стандарты наименований- например именовать триггеры, что бы было видно к какому сервису он относится.