Updated by berk on 2011-12-06 13:52:35 +00:00

• Target Version changed from 1.6 to 1.7

Updated by mfriedrich on 2011-12-06 13:59:46 +00:00

• 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.

Updated by cyildiri on 2011-12-07 08:37:27 +00:00

• File added State_Unreachable.pdf

Hello,

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

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

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

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

Updated by mfriedrich on 2011-12-19 23:02:17 +00:00

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

Updated by mfriedrich on 2011-12-19 23:02:38 +00:00

• Assigned to set to mjbrooks

@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.
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

Updated by mjbrooks on 2012-01-16 08:49:40 +00:00

• 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

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

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