How to collapse the “party” of triggers on the main “20 events” panel in Zabbix?

Question

Monitoring

I need to remove a large batch of triggers that pop up on the main zabbix panel, where the "last 20 events" are displayed. We would like to see an optimal, complete picture of what is happening, but triggers such as "running out of disk space" take up half the screen.
The question is how to consolidate such multiple triggers that have a common essence, but refer to different devices? Ideally, suppose you would like to see the big picture of the problems and, for example, see one big trigger like " Some servers are running out of space " and by clicking on it, go to a more detailed view, where you could already get acquainted with what specific pieces of iron it ends on place.
PS An example with "disk space", just an example, there are various events that are similar in essence but related to different devices. I would like to see the essence on the main panel, and not the events for each piece of iron, how best to implement this.
Zabbix version 3.2.1 , Thank you!

Answer 1

No need to look at the trigger as a list. It is necessary to look at the trigger and other events on the service resource model (SRM).
There are usually rules. In which it is written in what period it is necessary to eliminate the incident (Created automatically after the trigger is triggered). If you have triggers on which no one is going to do anything, then disable this trigger on those systems on which it is not relevant. Well, in extreme cases, let the triggers have a level of criticality as informational.
The most optimal and difficult approach:
1) Define services.
2) Develop triggers and define events for each service component.
What configuration element, thresholds, whom to notify, notification texts, criticality, etc.
3) Develop CPM
4) Develop correlation if necessary. Develop rules for how the status of higher elements of the CPM changes.
5) Document
6) Test
7) ​​Implement
Admins see their incidents on the service desk. In the incident there is a link to the CPM, which shows those areas for which the admin is not responsible, but affect his area of ​​responsibility.
And there are also regulations - how to put services on monitoring, who is responsible for what, who controls the execution of processes, how to set SLAs, how to decommission, etc. There are naming standards - for example, to name triggers so that it can be seen which service it belongs to.