change coloring of services on host down
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.
#2 Updated by dnsmichi over 3 years ago
- Status changed from New to Feedback
- Target version deleted (
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.
#8 Updated by mjbrooks over 3 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.
#10 Updated by cyildiri about 3 years ago
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 ?
#11 Updated by mjbrooks about 3 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 3 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.