[dev.icinga.com #875] Create a tactical Overview that seperates between important and unimportant Problems #200

icinga-migration opened this Issue Oct 10, 2010 · 6 comments


None yet
1 participant

icinga-migration commented Oct 10, 2010

This issue has been migrated from Redmine: https://dev.icinga.com/issues/875

Created by b@fh on 2010-10-10 06:29:51 +00:00

Assignee: (none)
Status: Closed (closed on 2011-09-26 15:33:32 +00:00)
Target Version: (none)
Last Update: 2011-09-26 15:33:32 +00:00 (in Redmine)

A general Showstopper in many enviroments is that the icinga Web-Interface does not seperate between important and unimportant problems in the overviews. At least one general overview should be available that accomplish this.

Definition :

  • Important Problems are Problems noone has taken care of yet (e.g. no acknowledges set, no downtimes set)
  • Unimportant Problems are Problems someone has taken care of yet (e.g. acknowledges set, downtimes set)

The Nagios and also the icinga core both already have the logic to implement such a classification in Web-GUIs. In productive enviroments this is a widely used feature. See cgi/tac.c as a reference so see how it is implemented in the classic UI (The css-sets in the classic UI currently does not display this correctly, but that is another issue, see #868 for reference). Also, the Register Card "Open Problems" seems to use this logic already.

Ideally an overview would look like the generic "To Hostgroup", however "critical" hosts and services are seperated into important and unimportant criticals. Also warnings should be included seperately in this view.

Just as an example have a look at the nagios-core (http://nagioscore.demos.nagios.com/nagios/cgi-bin/status.cgi?hostgroup=all&style=summary, credentials nagiosadmin/nagiosadmin). The colours used in the core are i.m.O. not the best choice. However this view should give you a general impression on what kind of display is needed.

I am marking this feature request as urgent.

Reason :
In many enviroments where more then one lonely sysadmin is working such a tactical overview is needed. Often responsibilities are seperated by Hostgroups, but some team members also act as a "backup".

Example :
Lets say "admin a" is responsible for "hostgroup a", "admin b" for "hostgroup b". The two are Backup for each other, so they need a general overview about the other Hostgroup as well.

When "admin a" looks at "hostgroup b" he knows he only needs to react if a problem there persists for a longer period of time. If "admin b" is already working on the issue, he acknowledges the problem (or sets a downtime). By doing this "admin a" automatically gets informed that no action is required from his side.



icinga-migration commented Oct 10, 2010

Updated by b@fh on 2010-10-10 06:58:03 +00:00

  • File added hostgroups.jpg

Update :

Just noticed that the nagios Demo site is not static and it is possible to edit states in there. So i attached a small screenshot.

As previously mentioned the colours used in this nagios-theme are not the best.

To sum it up :
Everything "unhandled" should catch eye attention immediately.


icinga-migration commented Oct 14, 2010

Updated by mfriedrich on 2010-10-14 07:43:53 +00:00

  • Priority changed from Urgent to Normal

icinga-migration commented Jan 13, 2011

Updated by mfriedrich on 2011-01-13 16:46:18 +00:00

  • Status changed from New to Feedback
  • Target Version set to 1.4

would need a where clause on the selects on set downtime/acknowledgement then. please evaluate for 1.4


icinga-migration commented Apr 30, 2011

Updated by jmosshammer on 2011-04-30 10:21:40 +00:00

  • Target Version changed from 1.4 to 1.5

Will have to wait till 1.5


icinga-migration commented May 17, 2011

Updated by mhein on 2011-05-17 12:53:26 +00:00

  • Target Version deleted 1.5

icinga-migration commented Sep 26, 2011

Updated by jmosshammer on 2011-09-26 15:33:32 +00:00

  • Status changed from Feedback to Closed

See #1952

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment