Service/Host state (handled or not) hard to differenciate

[episodeiv]

Describe the bug

We are displaying an Icingaweb2 dashboard on a large screen TV. After switching to the icingadb-web view, it has become hard to distinguish whether a check has been acknowledged (or handled in another way) or not.

For comparison, here's a view of the "old" icingaweb2:

And this is what is looks like now:

Sorry for the difference in the screenshots, but I hope you get my point. I really like the new, clean look but whether a circle is muted or not is pretty hard to tell.

I have tried changing the opacity of the CSS class .handled to .2 but this is a pretty difficult balancing act, I guess.

Your Environment

Include as many relevant details about the environment you experienced the problem in.

• Icinga DB Web version (System - About): 1.0.2
• Icinga Web 2 version (System - About): 2.11.4
• Web browser: Firefox Nightly 119
• Icinga 2 version (icinga2 --version): 2.14.0-1
• Icinga DB version (icingadb --version): 1.1.1
• PHP version used (php --version): 7.4.33
• Server operating system and version: Debian 11

[gbin2265]

We have also just taken the step to migrating everything to icingadb (based on the latest snapshot).

The operators in the operating room experiencing the same problem on the large large TV screens.

If you look at the tactical view you see almost no difference between handled or not. To have a quick solution we add in then CSS class .handled the option

text-decoration: underline;

This way we are sure what is handled (underlined) and what is not handled.

Next step is to create a new theme.

• to be able to make more difference in colors
• background darker like dark-theme (https://github.com/lazaroblanc/icingaweb2-dark-theme)

[gbin2265]

I quickly made a css file (with search and paste) for our operators' 82 inch TV screens to adjust the colors a little bit.

If you are interested you can download it here

https://github.com/gbin2265/icingadb-dark-colors-theme

[flourish86]

I tried some different variants on the state visuals

Here are the variants for the state orbs.

This is how they look in context

First the common list view (size-xl as main visual size-m for inline state)

The minimal list view with smaller icons (size-l for main visuals)

[flourish86]

Accordingly the state badges.

[gbin2265]

Hello,

I think this will be much more visible on large screens.

May I make a proposal to also make the OK (green) not transparent but full color like the current.

All statuses on which you have not taken any action are full color. Then you quickly know from a distance (for large screens) ,and/or on a black background, what is OK and what is not.

Isn't it interesting to also underline the number for handled actions? This is more visible for people with color problems.

regards, Geert

[flourish86]

If I may ask, just out of pure interest. What would be the benefit of having an ok object marked as "not acted upon" in your opinion?

The concept is and was since the legacy monitoring module to highlight (in this case full background vs outline) objects, that need attention/action. There would be no need to take care of an object, that is already ok.

[gbin2265]

for us is the OK/ERROR/WARNING/UNKNOWN/SOFT-STATE all on the same level when we look to the screen (these are unhandled). And I thought it was always like this.

I explain to the users that everything that is transparent that this is because the status has been set and is handled (such as downtime/acknowledge). It would then be strange that you would have to tell the user that an OK (unhandled) is now an exception that it is viewed as a handled (even if you haven't taken any action on it).

It is unfortunate that the SQL queries (tactical query host/services) do not have the fields hosts_up_handle/hosts_up_unhandled/services_ok_handle/services_ok_unhandled/hosts_pending_handle/hosts_pending_unhandled/services_pending_handle/services_pending_unhandled.

If you now look at the tactical view you will see 6000 host OK, but what you do not see is that 100 of these are in downtime. Same for the services in the host detail, you cannot say how many services are OK for that host, but they are in downtime.

That is why we are more in favor of the principle that everything that is unhandled is a full color, and those that are handled are a transparency with a symbol in it.

That is why we think that in the picture 'State Ball Alternate' the green should be the same as red in terms of transparency. And for the picture 'State Badges' that the OK is viewed as unhandled (full color).

Also that the list of hosts/services that the OK is full color, and the OK handled with icon is transparent.

[gbin2265]

Hello,

to have more control over the state downtime in the CSS file, and this for the state-UP (host) and state-OK (service), I made the following modifications

In the files:

./library/Icingadb/Widget/ItemList/HostDetailHeader.php
./library/Icingadb/Widget/ItemList/ServiceDetailHeader.php
./library/Icingadb/Widget/ItemList/StateListItem.php

from :

$stateChange->setHandled($this->state->is_handled || ! $this->state->is_reachable);

to : $stateChange->setHandled($this->state->is_handled || ! $this->state->is_reachable || $this->state->in_downtime);

With this adjustment I can make a distinction in the host/service list for the state-UP&OK (full color), and make the downtime transparent in detail with its symbol.

All the 'State Ball Alternate' are the same for the OK,ERROR,WARNING,... , just the color are different.

Maybe this is something to consider ?

regards, Geert