notification subsystem vs event_handler

[Ryan C Ash]

We are in the process of designing a Nagios deployment which is
replacing portions of a vendor solution.  We have a mature ticketing
system which we are integrating with Nagios.  Our initial design
utilized the event_handler functionality to interface with the ticketing
system.  This appears to be standard operating procedure for this type
of integration according to the documentation. I have been fighting with
design issues surrounding the use of a event_handler and I am wondering
if using the notification subsystem isn't a better design.  

Issues with event_handler: 
1. The "acknowledgement" of a svc/host check will be important us. While
the ticket is open in our ticketing system we will not allow any more
events through for that host-svc combination.  This can be easily done
with the integration but the event_handler would continue to fire. 
2. Multiple event_handler needed, one of which may "ack" the event, thus
stopping the ticketing integration
3. Limited control of when these fire, leading to wasted cycles
4. No feature like the external command "ACKNOWLEDGE_SVC_PROBLEM"

Essentially we would just use a custom service_notification_command (and
host) within a custom "contact".  That contact is essentially the global
ticketing integration and would do nothing else.  The "contact would be
assigned to everything, or at least everything going to the ticketing
system.   

Am I missing anything or is the notification route as good as it sounds?


Ryan Ash

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null