Event handler read host "notifications_enabled" setting?
Posted: Fri Aug 18, 2017 7:01 pm
Hello,
I've written a Nagios plugin that I currently have running as an event handler. It collects logs and emails them when a host changes states. The only remaining thing that I'd like to implement is the ability to mute it through the host notification enable/disable setting. I already have an option to not send the logs if the host is in scheduled down time. I used the $HOSTDOWNTIME$ macro for that. I don't see a macro or other method that would indicate whether notifications are enabled or not though. Any suggestions?
Instead of running it as an event handler I also experimented with running the plugin as a wrapper to the notification command. This would accomplish what I describe above in a different way. I couldn't figure out a way to send custom on demand host macros to the notification command though, a feature that I need for this plugin. For instance with the custom macro "$_FEXID$" I can get the value using the on demand macro "$_HOST_FEXID:HOSTNAME$", but hostname needs to be a static value, not another macro. I couldn't get it to resolve with the hostname as a sub macro. I did a bunch of experimenting with that and either got "$" or something that contained the hostname of the host that the Nagios server is running on instead of the host that the notification is for. The macro $HOSTNAME$ alone works just fine. Running the plugin as a host event handler had some complications since I am working around Nagios's built in structure for notifications. One problem was the ability to read the contacts for that host from within the scope of a host. I worked around that with another on demand macro. $CONTACTGROUPMEMBERS:receive_log_event_group$. Only in this instance "receive_log_event_group" is a static value instead of a variable. Using that I was able to subscibe contacts to the email list by adding them to the receive_log_event_group.
Two separate questions for the same basic problem. I'm open to other ideas for ways to accomplish what I am looking for as well.
Thanks,
Ethan Grinnell
I've written a Nagios plugin that I currently have running as an event handler. It collects logs and emails them when a host changes states. The only remaining thing that I'd like to implement is the ability to mute it through the host notification enable/disable setting. I already have an option to not send the logs if the host is in scheduled down time. I used the $HOSTDOWNTIME$ macro for that. I don't see a macro or other method that would indicate whether notifications are enabled or not though. Any suggestions?
Instead of running it as an event handler I also experimented with running the plugin as a wrapper to the notification command. This would accomplish what I describe above in a different way. I couldn't figure out a way to send custom on demand host macros to the notification command though, a feature that I need for this plugin. For instance with the custom macro "$_FEXID$" I can get the value using the on demand macro "$_HOST_FEXID:HOSTNAME$", but hostname needs to be a static value, not another macro. I couldn't get it to resolve with the hostname as a sub macro. I did a bunch of experimenting with that and either got "$" or something that contained the hostname of the host that the Nagios server is running on instead of the host that the notification is for. The macro $HOSTNAME$ alone works just fine. Running the plugin as a host event handler had some complications since I am working around Nagios's built in structure for notifications. One problem was the ability to read the contacts for that host from within the scope of a host. I worked around that with another on demand macro. $CONTACTGROUPMEMBERS:receive_log_event_group$. Only in this instance "receive_log_event_group" is a static value instead of a variable. Using that I was able to subscibe contacts to the email list by adding them to the receive_log_event_group.
Two separate questions for the same basic problem. I'm open to other ideas for ways to accomplish what I am looking for as well.
Thanks,
Ethan Grinnell