Request Tracker & Nagios

Has anyone every tried to integrate RT and Nagios?

Nagios, like most NMS tools, has the ability to send an email alert upon
detecting a specified failure, example - host pings out, send email.

While it’s simple enough to get RT to receive the email, and make a
ticket for the alert, any additional emails for this alarm will just
create new tickets rather then update the existing one

Ie: there is no deduplication going on.

Has anyone been able to solve this issue? Does any documentation exist?

While it’s simple enough to get RT to receive the email, and make a
ticket for the alert, any additional emails for this alarm will just
create new tickets rather then update the existing one

You could create a ticket with a special ID Subject, i.e.

Subject: [RT Ticket #1001] ping failure on machine blah

then have all your email notifications go to RT with the
ticket ID already existent.

This could create one ticket for each machine/service monitored,
and can expand from there.

jakeOn Oct 14, 2004, at 9:14 AM, Rodney Caston wrote:

Has anyone every tried to integrate RT and Nagios?

Nagios, like most NMS tools, has the ability to send an email alert
upon
detecting a specified failure, example - host pings out, send email.

While it’s simple enough to get RT to receive the email, and make a
ticket for the alert, any additional emails for this alarm will just
create new tickets rather then update the existing one

Ie: there is no deduplication going on.

Has anyone been able to solve this issue? Does any documentation
exist?


The rt-users Archives

Be sure to check out the RT wiki at http://wiki.bestpractical.com

Has anyone every tried to integrate RT and Nagios?

Not RT and Nagios but RT and BB.

Lets assume that Nagios and BB provide the same function, monitoring and
notifications based on events in ones environment.

While it’s simple enough to get RT to receive the email, and make a
ticket for the alert, any additional emails for this alarm will just
create new tickets rather then update the existing one

Has anyone been able to solve this issue? Does any documentation exist?

Not to mention if your system sends recoveries, RT doesn’t know how to
deal with those.

I came to the conclusion that automatically generating tickets in RT
from a proactive monitoring system is a bad idea (or at least not worth
the complexity it would involve). By being proactive you have a certain
amount of false positives you have to deal with. Part of being proactive.

I prefer a human to determine when an ‘event’ becomes a ‘problem’.
Problems are good to put into RT, not events.

Scott Walters
-PacketPusher

Has anyone every tried to integrate RT and Nagios?

Not RT and Nagios but RT and BB.

Lets assume that Nagios and BB provide the same function, monitoring and
notifications based on events in ones environment.

While it’s simple enough to get RT to receive the email, and make a
ticket for the alert, any additional emails for this alarm will just
create new tickets rather then update the existing one

Has anyone been able to solve this issue? Does any documentation exist?

Not to mention if your system sends recoveries, RT doesn’t know how to
deal with those.

Exactly.
The problem becomes twofold: it would be (IMO) necessary to teach Nagios
about the RT ticket-number it gets, so it can also close a ticket again.
E.g. if some mailserver becomes unavailable for 15 minutes, Nagios can
create a ticket - but would normaly mail-out a ticket number.
Now, Nagios would have to somehow be able to associate this
ticket-number with the specific mailserver and be able to send a
“close-ticket” event in case the server goes up again (which is most
likely).

I came to the conclusion that automatically generating tickets in RT
from a proactive monitoring system is a bad idea (or at least not worth
the complexity it would involve). By being proactive you have a certain
amount of false positives you have to deal with. Part of being proactive.

Indeed. It’s a nice idea, but in reality, one would end-up extending
either Nagios with RT features or vice-versa.
Both only sounds good on the first look.

cheers,
Rainer
~ Rainer Duffner - rainer@ultra-secure.de ~
~ Freising - Munich - Germany ~
~ Unix - Linux - BSD - OpenSource - Security ~
~ http://www.ultra-secure.de/~rainer/pubkey.pgp ~