Integrate with trouble ticket system?

[Andreas Ericsson]

Jamie Baddeley wrote:
> Stanley (and list)
> 
> Upon investigation, alternatively one could take advantage of the cli
> interface shipped with later versions of rt3.
> 
> To change a ticket to resolved would only require the command
> 
> /usr/bin/rt edit ticket/118 set status=resolved
> 
Lovely. Didn't know that.

> to be issued on the rt host, where in this example 118 is the relevant
> ticket number. So instead of needing to parse incoming email, you could
> use sh or ssh commands.
> 
> So now it becomes a question of how to feed the autoreply email into
> nagios, so nagios gains a sense of the ticket number. (given that event
> hanlders can easily handle setting of the ticket to resolved)
> 
Easy. procmail lets you parse incoming email with scripts, so it's 
rather trivial to fetch host-info and all from it (grep, sed, awk)

Here's how it could be done;
A webserver breaks down (for instance).

Nagios notices this and calls a notification script.

The notification script adds a couple of values to an sql-database 
(mysql batchmode makes this really easy), like service_description and 
host_name, and sends the notification off to RT.

RT gets the notification, makes a ticket of it and sends out an auto-reply.

Procmail receives the auto-reply, parses it, finds service_description 
and host_name in subject-line (or wherever) and sets ticket number.

Company webguru notices that things have gone wrong, and checks in an 
acknowledgement.

Notification script checks for entries with current service_description 
and host_name in sql-db, retrieves the ticket number and sends off a 
ticket continuation to RT.

RT adds the acknowledgement to the ticket in the proper queue, but sends 
no auto-reply.

The broken-down IIS webserver pops back up.

Nagios notices this, and once again calls the notification script, so 
that a RECOVERY notification goes out.

Notification script fetches ticket number from db, adds it to the 
subject line, sends the notification, deletes the ticket number from sql 
db (it's prudent, but not necessary) and executes the proper remote 
command by some means thus resolving the ticket.


Plain enough?

> http://naplax.sourceforge.net/REL.html
> 
> (or something like that) could probably form the basis of how we get
> data in - but instead of sending it to nagios.cmd, we could send it to
> comment.log. We could store the ticket number in comment.log - and we
> grep for it when the service resolves...
> 
Why on earth would you want to add it to a file that nagios keeps open?
Think race conditions...


> ..This is starting to feel like an ugly hack, but it is perhaps
> something to build upon?

It is a hack, but that doesn't necessarily mean its a bad thing.

> - the next tricky part is differentiating
> between services and hosts...

Not really. It's actually quite trivial to differ between services and 
hosts, as you can have two different scripts for the two.

> but I sense the right info in the subject
> line is the key.
> 
Or anywhere else, as long as it stays in circuit from RT to Nagios.


> jamie

-- 
Sourcerer / Andreas Ericsson
OP5 AB
+46 (0)733 709032
andreas.ericsson at op5.se


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
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