Nagios Support Forum

My issue is solved. By that I mean I figured it out.
When a Host has notifications disabled and does not recover within the set downtime period, Nagios will prevent service alert being sent out after downtime period expires.
I finally managed to setup a sandbox to play with and sure enough, there it is...

Has to do with host/service dependencies. Apparently Nagios assumes that when a no-notify host does not recover from reboot within a downtime period, that's ok.
So much for unattended maintenance.... I admit there's a logic to it, but a bit far fetched and easily overlooked by a novice Nagios user.
What surprises me is that even the Nagios people on this board overlooked this.

My workaround is to enable host notifications, which brings me to the following question: What is the difference between a standard Host check and Ping??
IMHO there's no use to have both hostcheck and ping active and alerting.

Not sure I follow the question.

Host check is actually just like any service check but with a few of it's own special options and a more direct relationship to the host definition. Note that a host check does not have to use the default check_host_alive command, it could be check_dummy (some people prefer this for various reasons), check_ssh or check_anything. That is specified with the check_command directive in the host definition, but usually comes down from a template.

The can only be 1 host check defined though... so I'm not sure I follow your question.

The results of my testing on NagiosXI2014R2.6
If a Host/Service event occurs during a Host scheduled downtime and is still active after downtime ends , a Host/Service Problem Notification *does* get generated when downtime ends.

However...... checking the Global Event Handler -this is *not* the case.
So after Downtime ends, the Global Event Handler does not get triggered if a Host/Service event is still active.

This is a huge problem for me as we use the Global Event Handler to interface to a ticketing system and use this to create the tickets and notify the SupportTeams (we don't use Nagios Notifications)
It appears that the Event Handler only gets triggered when there is a state change.
Obviously, there is some logic there already to send out the notification after downtime ends, so what I'm looking for is that Event Handler gets triggered as well if a Host/Service Problem Notification goes out after Downtime ends.

Thanks to all for your patience so far getting to the bottom of this.

regards.... Fred

jdalrymple wrote:Not sure I follow the question.

I'm afraid that happened before in this thread. Not just you!

Let me explain:

I work with XI Wizards. I don't alter much defaults.
So for any given server, I have a Host check with an IP attached, and a number of service checks. All pretty basic Nagios stuff.
The Host is based on template: xiwizard_windowsdesktop_host (check command = "check_xi_host_ping")

Now my question is this: If I have a Host check active and working, I don't really need Nagios to send out additional alerts for Ping, do I?
The Host check already has that bit covered by doing an ICMP check? (i.e. ping?)

I see what you're saying - you're right, highly redundant (see screenshots)

I'll see if the devs want to either take that out of the wizard or at least have it deselected by default.

Are we on the same page now MichielvM?

Yes, same page, same book.

No need to edit the wizards on my part.
Would be nice to have it clearly documented somewhere for the next generations.

Same goes for Host dependencies.
For one: I figured out by testing that there's really no need to create a downtime schedule for services if the associated host is already in a downtime schedule.
I couldn't find a definitive document about it. Saves me a lot of work.

Enjoy your weekend!

Thanks for the feedback, let us know if we can close this thread.

My issue is resolved, i.e. I know to get around it, so it can be closed on my part.
Other replies in this thread kind of sidetracked from my OP.

Maybe leave it open, that's up to them...

I will leave this open for comment for now, otherwise it will be closed.