[dev.icinga.com #868] use the signal-colour red more economically in tac.css stylesheet

[icinga-migration]

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

Created by b@fh on 2010-10-09 19:11:21 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2010-11-04 16:50:16 +00:00)
Target Version: 1.3
Last Update: 2014-12-08 09:34:22 +00:00 (in Redmine)

---

In a lot of enviroments the Monitoring System is open on a general view monitor, together with other informational tools. Users look at it from a couple of meters away. The text on the Monitor is unreadable then, but it is possible to identify the colours.

A signal colour of red usually means : There is a problemn noone has taken care of yet. Please check into it.

Nagios and also the Icinga core seperate Problems in "important problems" and "unimportant problems". For example, if a problem has been acknowledged it gets marked as "unimportant problem". The same applies for hosts/services in a sheduled downtime.

Unimportant Problems should be displayed in a different colour. Red should only be used for unhandled (important) problems.

Below is an example - Implementation for the tactical overview stylesheet (tac.css) :

.hostImportantProblem { text-align: center; background-color: #ff3300; color: #fff; }
.hostUnimportantProblem { text-align: center; background-color: #f5a9a9; color: #000000; }
.hostImportantProblem a { color: #fff; }
.hostUnimportantProblem a { color: #585858; }
.hostImportantProblem a:hover, .hostUnimportantProblem a:hover { color: #000; }

.serviceImportantProblem { text-align: center; background-color: #ff3300; color: #fff; }
.serviceUnimportantProblem { text-align: center; background-color: #f5a9a9; color: #000000; }
.serviceImportantProblem a { color: #fff; }
.serviceUnimportantProblem a { color: #585858; }

Changesets

2010-11-04 16:44:43 +00:00 by mfriedrich 99a3055

classic ui: use the signal-colour red more economically in tac.css stylesheet (Joachim Raber) #868

this looks nice indeed, although changed letter color
slightly to make it more readable (a and a.hover).

also fixed some typos and therefore not applied styles.

kudos to Joachim Raber for the patch.

fixes #868

[icinga-migration]

Updated by Meier on 2010-10-10 10:56:56 +00:00

• Priority changed from High to Normal

I don't share your opinion. Important vs unimportant can not be determined by the acknowledgement state. Also the classic UI has a view which hides acknowledged problems. In icinga-web you can even define custom views to achieve the desired behaviour.

What might be a good option is the possibility override the state coming from the check with a fixed state for the lifetime of an acknowledgement.

[icinga-migration]

Updated by mfriedrich on 2010-10-10 11:45:32 +00:00

• Status changed from New to Feedback

that highly depends if you want to see acknowledged problems too. therefore, i've added back the "unhanded problems" view for hosts and services, directly accessible via menu. so you are able to determine all of those, without seeing "unimportant" acknowledgement problems.

in our environment, even acknowledged problems need our attention since for example - one of the major nameservers for .at remains critical, it was acknowledged, but still it needs everyones attention in particular cases. and it has to be "red", otherwise no-one will recognize. another colour would be very hard to explain in there, regarding the fact that an "acknowledged problem" is not a "solved problem".

i'd recommend keeping you own stylesheet, and making this optional by css include/overwrite, or sth else.

[icinga-migration]

Updated by b@fh on 2010-10-10 16:04:14 +00:00

Guess this issue depends a bit on personal view and usecase, however I would like to point out that the above mentioned colour code is the standard behaviour from the nagios-core. Have a look to e.g. cgi/tac.c .

Changing the css is not a problem and easily adjustable, but please do leave the code routines in this case untouched. I can live with the small fix with implementing our own stylesheets here. The Host- And Service View is not an option, tough - would mean to have permanently open two browser - windows.

In the example of the important .at - nameserver i would simply just deactivate the notifications.

[icinga-migration]

Updated by mfriedrich on 2010-10-10 17:57:54 +00:00

sure, it's based on use cases and how people recognize and handle problems. and by changing colors problems might get less attention than they really preserve.
the classic ui should give a basic view for everyone, also adjustable by everyone. your proposal on not sending notificiations is a bit strange in regard of a color discussion, leaving everything else intact.

[icinga-migration]

Updated by b@fh on 2010-10-10 19:42:43 +00:00

As already mentioned I am happy with the change of my css there. As long as the cgi-routines remain the same the problem is solved for me personally.

Well, guess we are getting out of topic here, but to clear things up regarding my oneliner about your nameserver-example since you asked:

You wanted to acknowledge the DNS in this example. When issuing an ACK the following things occur (correct me if i am wrong there) :

• All notifications get disabled until the next state change
• (optionally configurable) An information message goes out that person x did an ack.
• Within Nagios the state changes from warning/critical/unknown to acknowledged.

Since you want to have the Server still classified as important in the GUI, I assume that the thing that annoys you are the notifications coming in. Therefor I suggested to just deactivate them for a while. Guess we could continue this discussion based on switching between warning/critical/unknown states, and also talk about the delay service notification option. But then we are gpong completely off-topic.

BTW: I am totally with you regarding the danger that problems get forgotten if acknowledged or scheduled. In my experience you can not run a large monitoring system properly without someone who watches the whole picture.

In our Nagios-Based Infrastructure we have armound 1700 Host and 7000 Service Objects (it is a new setup, therefor relationwise only that few Service Checks. 2011 the Numbers will at least double). They are administered by quite a few different teams. As you can imagine there are every day a few alerts (mostly due to maintenance work). Setting ACKnowledges and downtimes works quite well at our place, but that is also because a few colleages and myself keep an eye on it. I usually scan the monitor for reddisch signs every time I take a smoking break, and 1-2 times a day I browse through the acks and schedules. Seeing every type of Alert in red would block my work a lot.

[icinga-migration]

Updated by mfriedrich on 2010-11-03 16:00:07 +00:00

• Status changed from Feedback to Assigned
• Assigned to set to mfriedrich
• Target Version set to 1.3

ran into some problems on typos on outages and unreadable output on tac, tried the proposals on a test install, looks good so far, but changing the color to black instead of grey on not dark colored background makes more sense though.

[icinga-migration]

Updated by mfriedrich on 2010-11-04 16:43:11 +00:00

• Subject changed from stylesheets: use the signal-colour red more economically to use the signal-colour red more economically in tac.css stylesheet

[icinga-migration]

Updated by mfriedrich on 2010-11-04 16:50:16 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

Applied in changeset commit:"99a3055d2896c1a28f795c936ad4f99e4fb71df9".

[icinga-migration]

Updated by mfriedrich on 2014-12-08 09:34:22 +00:00

• Project changed from 19 to Core, Classic UI, IDOUtils
• Category set to Classic UI