Feature #2156

change coloring of services on host down

Added by cyildiri over 2 years ago. Updated about 2 years ago.

Status:RejectedStart date:12/06/2011
Priority:NormalDue date:
Assignee:mjbrooks% Done:

0%

Category:Other
Target version:-

Description

Hello,

i wish an opportunity to set dependencies between hosts and their related services. Especially the further status "Unreachable" for services like in hosts would be a nice thing. So if a host goes down and his status changes to "Unreachable" due to a network problem for example, i would like to see which services are also unreachable by defining dependencies.

State_Unreachable.pdf (43.9 KB) cyildiri, 12/07/2011 09:37 am


Related issues

Related to Classic UI - Feature #992: maintenance-mode for servers Resolved 11/11/2010

History

#1 Updated by berk over 2 years ago

  • Target version changed from 1.6 to 1.7

#2 Updated by dnsmichi over 2 years ago

  • Status changed from New to Feedback
  • Target version deleted (1.7)

can you elaborate that by example, to get a better insight on your idea?

and explain a bit more

  • what would be an "unreachable" service - would that be a new state, or is unknown the better state?
  • would that require a new config option, and if any, how to resolve that within the config verification checks
  • would such addins affect the default behaviour of the core and change that in a way, addons like gui or transportation could be affected in a way which is not compatible.

#3 Updated by cyildiri over 2 years ago

Hello,

i tried to explain as effectively as possible.
See Attachment !

#4 Updated by dnsmichi over 2 years ago

ah. gui layer and colorings. yes, that makes sense.

see #992 for an example of coloring when in a scheduled downtime.

maybe this could be adapted somehow, checking withing the status.cgi if $host->state==DOWN, and then coloring the services differently.

#5 Updated by dnsmichi over 2 years ago

  • Project changed from Core to Classic UI
  • Category changed from Other to Other

moved to classic ui section, makes more sense in here.

#6 Updated by dnsmichi over 2 years ago

  • Subject changed from Host_and_Service_Dependecies to change coloring of services on host down

#7 Updated by dnsmichi over 2 years ago

  • Assignee set to mjbrooks

@mjbrooks_dev

please elaborate.

#8 Updated by mjbrooks over 2 years ago

Thanks @cyildiri. Always good to have ideas rolling in.

@dnsmichi What is being requested is an additional state for services where if $host->state==DOWN, then have the services for that host be marked UNREACHABLE instead of having it be marked as CRITICAL.

This would definately break compatability in both the Classic UI and other parts of the Core (notifications and configuration files). Also, calling it UNREACHABLE would be very improper not to mention confusing, but I'll get to that in a minute.

The reason for the request is that cyildiri would like to see which services are being affected by a particular outage.

Not a bad idea, but the requested way of implementing it is lacking especially since having another state still wouldn't narrow it down a particular outage anyway. A more appropriate approach would be through using filters.

So +1 for the idea, but -1 for doing it with a change of state... or rather -2 since the state name UNREACHABLE is already reserved for hosts.

As far as the coloring is concerned, the current coloring of a service is based on its determined state. If a host is down, then service checks will obviously also fail and thus will end up marked as CRITICAL. CRITICAL is colored red according to standard.

Coloring it to the reserved color of a completely different state than it actually is (i.e. It's CRITICAL but colored pink) would cause undue confusion and would be contrary to our recent efforts at getting everything to properly follow the standard coloring.

Changing the resulting state to something other than CRITICAL would also be incorrect and confusing. First, because contacts registered to receive critical service events for the service need to know that something bad is going on. Not all contacts for services are also contacts for their hosts after all. And secondly, although the service is out because the host itself is out, the service's state is not UNKNOWN or UNREACHABLE... UNKNOWN and UNREACHABLE means something couldn't be checked properly because we already know for a fact that a host ahead of it is out... it could be UP/OK, but we don't really know for certain because we can't actually reach it to get a proper check due to the blocking outage. In a case like the host being down though, the service is CRITICAL because it's not there doing its job, we know so for a fact and the reason why is besides the point.

So the only real option is also the best one and that's to have some sort of filter that would allow you to get a list of all the services affected by a down host without inappropriately changing the state or coloring of them.

The question is, can it be narrowed down to a parent and it's children using what is already there or will filters need to be expanded a bit? Perhaps Ricardo knows that better than I.

#9 Updated by mjbrooks over 2 years ago

Haven't heard back... @cyildiri, is my understanding correct?

#10 Updated by cyildiri about 2 years ago

Hello @mjbrooks,

sorry for my late answer.
Your understanding was correct ! I´m ok with the situation, that the service going into the critical state, if a network outage occur. But another problem, which i have to deal with is the notification. Icinga allows me to configure a notification for the service states like "Warning, Critical or Unknown", but in a case of network outage i would get a flow of notifications, which would be difficult to handle. It would be a fine idea, to have a option for services, not to notify if network outage occur, although the notification is enabled for all states. Could it be realized ?

Greets,
cyildiri

#11 Updated by mjbrooks about 2 years ago

  • Status changed from Feedback to Rejected

If you define parent/child relationships for your hosts you will avoid the problem you are concerned about.

For more information see: http://docs.icinga.org/latest/en/networkreachability.html

#12 Updated by cyildiri about 2 years ago

Yes i am agree with you, but as you mentioned, the definition of a parent/child relationsship works for hosts, not for services. I know also, that you are able to define dependencies between services. But, what i need is an extension for the critical state of services, especially for notification reasons. It should be possible, to activate a notification for a critical state, but with the feature to ignore the notification if the host gets the "Unreachable" state due to a network outage.

#13 Updated by dnsmichi about 2 years ago

when a host goes down, no notifications for associated services are sent. that's the default behaviour. if that fails, verify your host check really getting into down state.

check base/checks.c:1545 for further information on the logic itsself.

#14 Updated by mjbrooks about 2 years ago

Join us on IRC http://webchat.freenode.net/?channels=#icinga if you'd like to discuss it.

If I'm not on, I'm sure one of the other devs or users can help clarify it for you.

Also available in: Atom PDF