Host state vs service state

hi,

i have a question regarding host state vs service state.

when a host is down it is reported under the host problems menu item.
it is added to the counter of hosts with a problem. if the host has failed that also means that the services for that host have failed but they do not seem to be in the service problems counter. also the host has a large red box indicating it has failed, the service has a light red small bar on the left (like when you acknowledge a problem)

is that by design? i would expect the service to also be added to the failed service counter and be indicated with a big red box in the list with services problems.

i also have a second question, we have a number of hosts where we only want to check if they respond to ping requests. for the host template i selected ‘hostalive’ for the check command. is that enough for this basic check or is it recommended to also add a ping check service to the host?

thanks in advance

when a host is down it is reported under the host problems menu item.
it is added to the counter of hosts with a problem. if the host has failed
that also means that the services for that host have failed but they do
not seem to be in the service problems counter. also the host has a large
red box indicating it has failed, the service has a light red small bar on
the left (like when you acknowledge a problem)

is that by design?

Yes, it is:

https://icinga.com/docs/icinga2/latest/doc/03-monitoring-basics/
#implicit-dependencies-for-services-on-host

i would expect the service to also be added to the failed service counter
and be indicated with a big red box in the list with services problems.

You can change the behaviour if you wish, but I think the default arrangement
makes sense because surely you don’t want to be alerted for every single
service on a host which is down - just being notified that the host is down and
needs attention is preferable?

There’s no point in overloading people with redundant alerts - it leads to
complacency, or people overlooking something important in amongst all the
clutter.

i also have a second question, we have a number of hosts where we only want
to check if they respond to ping requests. for the host template i
selected ‘hostalive’ for the check command. is that enough for this basic
check or is it recommended to also add a ping check service to the host?

“hostalive” is a ping check, but for more detail you can add another if you
wish:

https://icinga.com/docs/icinga2/latest/doc/03-monitoring-basics/
#host-and-service-checks

"hostalive is the same as ping but with different default thresholds. Both use
the ping CLI command to execute sequential checks.

If you need faster ICMP checks, look into the icmp CheckCommand."

Regards,

Antony.

1 Like

thanks for clarifying Anthony,

i assumed it was something like that and indeed it makes sense.

Hey @Pooh, could you please tell how this behavior could be changed?
In my use case i would prefer that services are not displayed as critical.handled when the corresponding host is reported down.
I’ve already tried with host-to-host and service-to-host dependencies but that solved only the reachable flag.

A hint on how this could be resolved is highly appreciated

Kind regards
Chris

Hi. Welcome to 2021.

You say you “would prefer that services are not displayed as critical.handled
when the corresponding host is reported down.”

What do you want them displayed as?

You can’t get an accurate service check result when the host is down (or
unreachable), so how do you want these service checks to be shown in this
situation?

Antony.

Hey Antony,

thanks for your reply.

I guess you answered it already but yes i would like to have the services not marked as „handled“ in any way without user interaction. No matter if the corresponding host is down or not. Means the services should just appear in their state that was set in the last execution.

I know it sounds not intuitive maybe but the way we use icinga2 (as umbrella monitoring system) requires the ability to sort services by severity, decoupled from the host state.
If the services appear critical handled they are below critical and warning states with the risk of not being seen at all or to be confused with already acknowledged services.

However having the host state available is also required for other use cases so dummy, always green and reachable hosts are not a solution.

I was hoping there is an easy way to do this :frowning:

Anyway - thank you Antony

Kind regards
Chris