[ZBXNEXT-1703] Triggers with multiple severity levels (CLONE - REOPENED) Created: 2013 Apr 10  Updated: 2022 Mar 03

Status: Open
Project: ZABBIX FEATURE REQUESTS
Component/s: Frontend (F), Server (S)
Affects Version/s: None
Fix Version/s: None

Type: Change Request Priority: Minor
Reporter: Roman Assignee: Unassigned
Resolution: Unresolved Votes: 18
Labels: triggerseverities
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


Issue Links:
Duplicate
duplicates ZBXNEXT-637 Tiggers with multiple severity levels Closed
is duplicated by ZBX-20705 Defining multiple severity levels in ... Closed

 Description   

There are several cases where we have to define 3, 4,..,n Triggers for exactly the same situation,
only different Thresholds.
Triggers creation would get faster, cleaner and easier (and the Triggers view of an host would get less cumbersome)
if it was allowed to set these multiple severity levels in the same Trigger.

Maybe the Trigger expression builder could be revamped to further ease the configuration.

Use cases explained in both,
http://www.zabbix.com/forum/showthread.php?t=12003
http://www.zabbix.com/forum/showthread.php?p=79248



 Comments   
Comment by Roman [ 2013 Apr 10 ]

Sorry for actually cloning the ticket, I didn't find another way to reopen it. Please see my comment:
https://support.zabbix.com/browse/ZBXNEXT-637?focusedCommentId=78622&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-78622
"I would say that this idea could be implemented in a different way: have separate triggers, have a chance to combine them to a single box in an "overview". The idea is to save some space on this screen. When you have lots of hosts and lots of triggers you do your best to get them all on one screen, and having 3+ similar triggers isn't a good approach." ©

Comment by Pavel [ 2013 Sep 09 ]

For me the main wish is that I do not want to receive recovery message when situation become worse ("More than 90% used: OK (now 98% used)"). But I want to receive recovery notification when problem gone away (solved).
Then, alert comments should be preserved if problem changed severity.
And then, it will be good to have the same trigger-id for threading mail about changing status of the problem.

I think this can be implemented by some kind of grouping (linking) triggers. Additional option for dependency: inherit alert comments (and acknowledgement?) and do not send recovery message until any of these linked triggers is in alarm state.

Comment by Janne Korkkula [ 2013 Dec 19 ]

As a large installation, we need to be able to activate different kinds of alerts to different groups of people depending on severity, which depends on value ranges.

Say a server rack is a bit too warm - a warning displayed on the dashboard is enough at first. Should the temperature rise more, DC people need to be emailed (average), then an SMS should be sent (high). Disaster measures follow. Etc, etc, etc.

Trying to get by with multiple/dependent triggers, there will be stacking alerts and/or those false OK's for things getting worse, impossibly complicated trigger expressions, an insane amount of triggers and so on.

Comment by Victor-Philipp Busch [ 2016 Aug 05 ]

One easy example for this ticket: You get an alarm for >5% free disk, but no emergency alert for =0%!
Its very confusing with triggers for every severity, but a grouping function could be helpful.

Comment by Charaf ZEMOURI [ 2018 Mar 28 ]

One workaround is to create several triggers withe the same name like this :

Name : Free disk space on volume

{#FSNAME}, Severity: Disaster, Expression : {Your Template :vfs.fs.size[{#FSNAME}

,pfree].last(0)}<5

Name : Free disk space on volume

{#FSNAME}, Severity: High, Expression : {Your Template :vfs.fs.size[{#FSNAME}

,pfree].last(0)}<20 and {Your Template :vfs.fs.size[

{#FSNAME}

,pfree].last()}>10
...
And on trigger overview for example show only Problems or Recent problems.

Generated at Tue Apr 16 16:17:01 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.