Integrate with trouble ticket system?

Andreas Ericsson ae at op5.se
Wed May 26 07:00:02 CEST 2004


Stanley Hopcroft wrote:
>>To: <jnichols at pbp.net>,
>>    <nagios-users at lists.sourceforge.net>
>>Subject: RE: [Nagios-users] Integrate with trouble ticket system?
>>Date: Tue, 25 May 2004 15:31:05 -0700
>>
>>If you are using something like RT (www.bestpractical.com/rt/), you could
>>just define a new host notification command in nagios and then have email
>>alerts mailed to support at rtbox.com or whatever your trouble ticket box's
>>address is.
> 
> 
> define contact{
>        use                             generic-contact
> 
>        contact_name                    RT
>        alias                           Request Tracker
>        email                           Networks at Xena
>        host_notification_commands      bit-bucket
>        service_notification_commands   notify-request-tracker-by-email
>        }
> 
> # 'notify-request-tracker-by-email' command definition
> define command{
>         command_name    notify-request-tracker-by-email
>         command_line    /usr/bin/printf "%b" "***** Nagios 1.2 
> *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: 
> $SERVICEDESC$\nHost: $HOSTNAME$\nAddress: $HOSTADDRESS$\nState: 
> $SERVICESTATE$\n\nDate/Time: $DATETIME$\n\nAdditional Info:\n\n$OUTPUT$" 
> | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ alert - 
> $HOSTNAME$/$SERVICEDESC$ is $SERVICESTATE$ $DATETIME$ $USER3$ **" 
> $CONTACTEMAIL$
>         }
> 

How on EARTH can you keep track of that? Why not just let it execute a 
script which does something like;
cat << EOF | /usr/bin/sendmail
To: $1
From: Nagios
Subject $2 alert
...
...
EOF

I'm sure you get the idea.

> # from resource.cfg
> 
> # Request Tracker open request Ids
> $USER3$=[IPAustralia #1701]
> 
> But this only handles one open request I hear you say. Yep. The proper
> way to do this is to have a notification command that consults a hash of
> requests keyed by service descriptions/names. The notify command 
> probably should also determine the request queue using similar means.
> 
Aye. We've done it a bit differently. The notification script we use 
check to see if ~/etc/$CONTACTNAME$ exists and is a directory. If so, it 
rolls over * of the files (that's all 'non-dot' files) and adds a 
variable with the name of the file. It then greps the file for the 
hostname and everything beyond a marker (currently \t I think) is the 
value of the variable (simple, eh? I'll redo this, come to think of it). 
This way we can add special meaning to certain hosts, and let each have 
its own ticket-number.

Also, the script greps ~/etc/$CONTACTNAME$/.notification_types for 
$NOTIFICATIONTYPE$. If the file exists, but $NOTIFICATIONTYPE$ isn't in 
there, we don't send any alerts (this was done to let one of our 
customers get ACKNOWLEDGEMENT emails only to their support database).

Btw. Would anybody be interested in checking this script out?

> Closing requires an event handler to post a 'request resolved' to the RT 
> web interface. AFAIK (and that's not saying much) this can't be done by 
> email or perhaps it can if the nagios mailer is authorised by Request 
> Tracker as an admin for the relevant request queue.
> 
> 
> 
>>Closing the ticket automatically when the outage ended would
>>probably be a bit more difficult. Anyone with more RT experience care to
>>comment?
> 

I've conjured up a way of doing this as well, but decided against it (it 
involved some absurd db-handling and procmail scripts parsing 
confirmation emails).
Most of the problems are worthy of commenting, and the extra effort of 
clicking 'resolve' is better than having a bunch of tickets resolving 
themselves before I even have time to check into what caused the problem.
Also, 'old' tickets are great for logging 'cause-and-fix' stuff. In time 
we turn it into a trouble-shooting guide for our network. So far we have 
one entry;

Q: What should I do if the wireless hub goes down?
A: If you don't know, it's your turn to buy coffee.

The guide isn't really used much.

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





More information about the Users mailing list