Nagios Support Forum

Is there any functionality in Nagios Core so that when a service or host alarms, and notification goes out, that if that server/host stays in a Critical or Warning state, that when the notification_interval comes up again for notification, that it can know it was already in that state previously?

Let me explain this a little better. Say a root filesystem service check on hostX goes critical at 01:00. The notification goes out, of whichever method I prefer. The notification_interval is set to say 1440 (1 day) and then at 01:00 the following day, another notification goes out. It goes out again because the state of that service/host hasn't gone OK (recovery). Can that second notification include some kind of parameter that I can script against that will let me know this is still in an unresolved Critical/Warning state?

If not, then I can simply script around it so that my notification script keeps a property file of sorts and then 1440 minutes later, if the property file still contains data, i know it's the 2nd or more occurrence. If a recovery occurs, I can remove that entry from my property file. This does seem like extra coding that if it is possible without and a parameter knows this; I'd love to KISS, so to speak.

Thanks.

I think what you're looking for are escalations (which occur after x times, so this would work for your idea.) This would allow you to specify a different notification command to run, which could be 'notify-host-by-email2' for example, and contain the extra data. See this link - https://assets.nagios.com/downloads/nag ... tions.html

The other theory you mentioned on your own script would work as well, and your logic sounds spot on.

rkennedy wrote:I think what you're looking for are escalations (which occur after x times, so this would work for your idea.) This would allow you to specify a different notification command to run, which could be 'notify-host-by-email2' for example, and contain the extra data. See this link - https://assets.nagios.com/downloads/nag ... tions.html

The other theory you mentioned on your own script would work as well, and your logic sounds spot on.

Thanks, that looks like it could work. I guess I need to decide, since I have quite a lot of services defined, this will be just as many service escalations I need to create. Those examples give a lot of power to the escalations that I can see very beneficial for some people. I wish this could be implemented with less labor, perhaps wildcards for service names etc.

You should still be able to assign a * for the members on an escalation.

The other option for large / dynamic scale, would be to run the route you mentioned with dynamic /tmp/ files, which would allow you quite a bit of flexibility / control.

Just checking in since we have not heard from you in a while. Did @rkennedy's post clear things up or has the issue otherwise been resolved?