[dev.icinga.com #2156] change coloring of services on host down #810
Comments
Updated by berk on 2011-12-06 13:52:35 +00:00
|
Updated by mfriedrich on 2011-12-06 13:59:46 +00:00
can you elaborate that by example, to get a better insight on your idea? and explain a bit more
|
Updated by cyildiri on 2011-12-07 08:37:27 +00:00
Hello, i tried to explain as effectively as possible. |
Updated by mfriedrich on 2011-12-19 23:00:40 +00:00 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. |
Updated by mfriedrich on 2011-12-19 23:01:20 +00:00
moved to classic ui section, makes more sense in here. |
Updated by mfriedrich on 2011-12-19 23:02:17 +00:00
|
Updated by mfriedrich on 2011-12-19 23:02:38 +00:00
@mjbrooks_dev please elaborate. |
Updated by mjbrooks on 2011-12-20 08:43:54 +00:00 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. |
Updated by mjbrooks on 2012-01-14 05:48:51 +00:00 Haven't heard back... @cyildiri, is my understanding correct? |
Updated by cyildiri on 2012-01-16 08:38:47 +00:00 Hello @mjbrooks, sorry for my late answer. Greets, |
Updated by mjbrooks on 2012-01-16 08:49:40 +00:00
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 |
Updated by cyildiri on 2012-01-16 15:00:53 +00:00 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. |
Updated by mfriedrich on 2012-01-16 16:34:18 +00:00 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. |
Updated by mjbrooks on 2012-01-16 21:49:49 +00:00 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. |
Updated by mfriedrich on 2014-12-08 09:32:52 +00:00
|
This issue has been migrated from Redmine: https://dev.icinga.com/issues/2156
Created by cyildiri on 2011-12-06 11:24:15 +00:00
Assignee: mjbrooks
Status: Rejected (closed on 2012-01-16 08:49:40 +00:00)
Target Version: (none)
Last Update: 2014-12-08 09:32:52 +00:00 (in Redmine)
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.
Attachments
Relations:
The text was updated successfully, but these errors were encountered: