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