NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?

This support forum board is for support questions relating to Nagios XI, our flagship commercial network monitoring solution.
Post Reply
snapier3
Posts: 144
Joined: Tue Apr 23, 2019 7:12 pm

NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?

Post by snapier3 »

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?
User avatar
danderson
Posts: 234
Joined: Wed Aug 09, 2023 10:05 am

Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?

Post by danderson »

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?
snapier3
Posts: 144
Joined: Tue Apr 23, 2019 7:12 pm

Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?

Post by 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?
Basically
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.
User avatar
danderson
Posts: 234
Joined: Wed Aug 09, 2023 10:05 am

Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?

Post by danderson »

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.
snapier3
Posts: 144
Joined: Tue Apr 23, 2019 7:12 pm

Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?

Post by snapier3 »

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.
Dangit!
Thanks a ton, I'm tired of staring at C anyway :lol:
User avatar
danderson
Posts: 234
Joined: Wed Aug 09, 2023 10:05 am

Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?

Post by danderson »

Could you try doing a persistent comment?
snapier3
Posts: 144
Joined: Tue Apr 23, 2019 7:12 pm

Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?

Post by snapier3 »

danderson wrote: Wed Jun 05, 2024 2:49 pm Could you try doing a persistent comment?
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.
snapier3
Posts: 144
Joined: Tue Apr 23, 2019 7:12 pm

Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?

Post by snapier3 »

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.
What about host or service notifications? Would the notifications also be fired after the XXXX_async_check_result calls in Nagios Core?
User avatar
swolf
Developer
Posts: 361
Joined: Tue Jun 06, 2017 9:48 am

Re: NagiosXI | Reaping of "Sticky" Acknowledgments or Event Handler execution, which comes first?

Post by swolf »

snapier3 wrote: Tue Jul 16, 2024 10:29 am
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.
What about host or service notifications? Would the notifications also be fired after the XXXX_async_check_result calls in Nagios Core?
Yes! handle_xxx_check_result() is actually the function that determines whether a check result needs to be logged/have a notification sent
Developer @ Nagios 2017-05-15 thru 2024-08-06
Post Reply