Integration with Request Tracker

[Jonathan Angliss]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Hi All
>
> How viable would it be to distribute/develop a plugin for NRPE which is
> provided with the RT3/NAGIOS distribution and which logs a ticket directly
> in the RT database when provided the necessary information by a nagios
> server? It seems NRPE plus some plugin code could serve as decent
> framework for an integration layer between RT and Nagios systems (which
> are commonly found together in the same IT environments!).

I don't think it'd have to be limited to NRPE to be honest.  As long
as you can build a script that can accept input to read/write
something that RT can understand (be it direct to the DB, or if RT
supports it via some interface), then it can be just a simple script.
NRPE will just allow you to execute that same script on different
servers, it's just a case of passing the arguments over.

> It doesn't seem technically difficult, but the question is whether this
> would be viable to maintain as part of future nagios distributions?

I'm not sure.  I guess a generic ticket generator would be feasible,
just to provide an example of how to create the ticket.  However, you
can never be entirely sure on how somebody has their RT system setup.
They might use different custom fields for stuff that the generic
generator tries to use to remember the problem ID.

- --
Jonathan Angliss
<jon at netdork.net>


> -----Original Message-----
> From: Jim Perrin [mailto:jperrin at gmail.com]
> Sent: Thu 10/2/2008 6:06 PM
> To: Jon Angliss
> Cc: nagios-users at lists.sourceforge.net
> Subject: Re: [Nagios-users] Integration with Request Tracker
>
> On Thu, Oct 2, 2008 at 4:26 AM, Jon Angliss <jon at netdork.net> 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!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32) - GPGshell v3.64

iEYEARECAAYFAkjmI5sACgkQK4PoFPj9H3NgvgCeKq/RE7aN0h0aQbIQ4fcucVsl
gAQAoP4IxiL5jnYGgbkkj3t4xvZ+8KRx
=GLtM
-----END PGP SIGNATURE-----



-------------------------------------------------------------------------
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 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