On Thu, Oct 2, 2008 at 4:26 AM, Jon Angliss <[EMAIL PROTECTED]> wrote:
> You might want to look at $SERVICEPROBLEMID$ and $HOSTPROBLEMID$ > instead. And the $LAST...$ versions of both of those. Combining with > an event handler, you can probably use a small table containing the RT > ticket number, the host/service name, and the problem ID. You'd then > feed the state, statetype, service, host, and the problem ID macros to > the event handler, and you should then be home free :) Yes, event handlers were the plan all along but I lacked a simple method to track an incident between nagios and RT reliably. Your suggestion of problem id's looks very promising. This, combined with nagios having its own queue within RT, and a few custom ticket fields should do quite nicely. Thanks again! -- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Nagios-users mailing list Nagios-users@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
