I have a large environment that uses an on-state-change event-handler integration with ServiceNow Incident table.
In the handler I have a call-back that acknowledges the problem and writes the ServiceNow sys_id of the incident into the comment of the problem acknowledgement in NagiosXI.
The incident sys_id from the ACK comment is then used for updates, problem state changes and ultimately auto-resolution of incidents created in ServiceNow.
This all works as it should but, what I have noticed in testing auto-resolution is that when I use "Sticky" acknowledgements, the comment entries are not present at the time of the firing of the event handler in XI. My testing with using the different types of ACKs led me to the conclusion that the reaping of the "Sticky" acknowledgements from the comment table is happening prior to the execution of the on-state-change event handler for hosts and services.
Is it possible to control the order of operation of these two activities?
Can one change the order in which clearing for the "Sticky" ACK from the comment table and the execution of event handler happens?
NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?
Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?
Thanks for reaching out @snapier3,
Just for clarity purposes, are you meaning that the event handler can't access any comments previously made with a "sticky" acknowledgement but it can with others? Maybe I'm missing something, but is the event handler that tries to access the comments made by the acknowledgement the same one that acknowledges the problem? Or are you trying to access previously made sticky acknowledgement comments?
Just for clarity purposes, are you meaning that the event handler can't access any comments previously made with a "sticky" acknowledgement but it can with others? Maybe I'm missing something, but is the event handler that tries to access the comments made by the acknowledgement the same one that acknowledges the problem? Or are you trying to access previously made sticky acknowledgement comments?
Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?
BasicallyJust for clarity purposes, are you meaning that the event handler can't access any comments previously made with a "sticky" acknowledgement but it can with others?
Sorry for the confusion I've been chewing on this for a bit.
When a problem has a sticky acknowledgement, on resolution the ack is cleared before the handler fires and I can't access the comment.
Also, I'm pretty sure this is all Nagios Event Broker voodoo with the callbacks.
Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?
It looks like in the function handle_async_service_check_result in checks.c in Nagios Core calls service_state_or_hard_state_type_change which removes the acknowledgements before the handle_service_event function which calls the event handler.
So unfortunately I don't think this is possible right now as the sequence of events is hard coded in Nagios Core.
So unfortunately I don't think this is possible right now as the sequence of events is hard coded in Nagios Core.
Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?
Dangit!It looks like in the function handle_async_service_check_result in checks.c in Nagios Core calls service_state_or_hard_state_type_change which removes the acknowledgements before the handle_service_event function which calls the event handler.
Thanks a ton, I'm tired of staring at C anyway

Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?
Could you try doing a persistent comment?
Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?
That's what I ended up doing.
I did file a feature request on the back of that change to make comment management a little easier with bulk actions like search, sort check all and delete.
Until then I can work something out to manage the comments via the api.
Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?
What about host or service notifications? Would the notifications also be fired after the XXXX_async_check_result calls in Nagios Core?danderson wrote: ↑Tue Jun 04, 2024 5:34 pm It looks like in the function handle_async_service_check_result in checks.c in Nagios Core calls service_state_or_hard_state_type_change which removes the acknowledgements before the handle_service_event function which calls the event handler.
So unfortunately I don't think this is possible right now as the sequence of events is hard coded in Nagios Core.
Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?
Yes! handle_xxx_check_result() is actually the function that determines whether a check result needs to be logged/have a notification sentsnapier3 wrote: ↑Tue Jul 16, 2024 10:29 amWhat about host or service notifications? Would the notifications also be fired after the XXXX_async_check_result calls in Nagios Core?danderson wrote: ↑Tue Jun 04, 2024 5:34 pm It looks like in the function handle_async_service_check_result in checks.c in Nagios Core calls service_state_or_hard_state_type_change which removes the acknowledgements before the handle_service_event function which calls the event handler.
So unfortunately I don't think this is possible right now as the sequence of events is hard coded in Nagios Core.
Developer @ Nagios 2017-05-15 thru 2024-08-06