Mon and rt

RT Users
1

I’m looking at having our mon (mon.sourceforge.net) install open rt
tickets instead of paging or sending email. Awhile ago, I heard
something about someone having done this, but “mon” and “rt” aren’t
very good things to search on.

Anyone have more information?

thanks
seph

2

I’m the author of gnats.alert for mon so I have a little experience in this
matter ;).

Basically things are much easier under RT, you can just have mon open tickets
by using the email address to generate the tickets.

The problem with any of these systems, is that mon doesn’t know about ticket
numbers, so if the problem gets fixed and you get an up-alert, there is no way
that I have found to close the opened ticket.

Not a big deal if you only have mon open tickets on a few things, but if you
have a huge mon install, this could present a problem.

I mean how much fun is it to go and look at mon to verify it is now up in order
to close the ticket.

Ted Serreyn

Quoting seph seph@commerceflow.com:

3

The problem with any of these systems, is that mon doesn’t know
about ticket numbers, so if the problem gets fixed and you get an
up-alert, there is no way that I have found to close the opened
ticket.

This was one of the issues I was curious how the other person who did
the mon/rt stuff did. I can think of a couple ways, none very clean.

If I come up with something clean, I’ll send it to the various contrib
sections.

seph

4

For mon, the following environment variables are available to alerts:

    $ENV{"MON_LAST_SUMMARY"}        = $sref->{"_last_summary"};
    $ENV{"MON_LAST_OUTPUT"}         = $sref->{"_last_output"};
    $ENV{"MON_LAST_FAILURE"}        = $sref->{"_last_failure"};
    $ENV{"MON_FIRST_FAILURE"}       = $sref->{"_first_failure"};
    $ENV{"MON_LAST_SUCCESS"}        = $sref->{"_last_success"};
    $ENV{"MON_DESCRIPTION"}         = $sref->{"description"};
    $ENV{"MON_GROUP"}               = $args{"group"};
    $ENV{"MON_SERVICE"}             = $args{"service"};
    $ENV{"MON_RETVAL"}              = $args{"retval"};
    $ENV{"MON_OPSTATUS"}            = $sref->{"_op_status"};
    $ENV{"MON_ALERTTYPE"}           = $alert_type;
    $ENV{"MON_STATEDIR"}            = $CF{"STATEDIR"};
    $ENV{"MON_LOGDIR"}              = $CF{"LOGDIR"};

It should be possible to write an alert script that constructs a unique
“event id” using some combination of MON_FIRST_FAILURE, MON_GROUP,
MON_SERVICE and the issuing system hostname or IP address. If mailgate or
enhanced mailgate could extract this ID and within RT internally bind it to
the issued ticket number, then it should be possible to track multiple
alerts for one event within a single ticket. The algorithm would be
esentially:

    select ticketID from newTable where uniqueID = $thisUniqueID
    if ($ticketID)
        inject new content into existing ticket
    else
        create new ticket as usual

Using MON_ALERTTYPE, it could be possible to automatically close the ticket,
but might be better to leave it open until manually investigated and closed.

I’m fairly new to RT internals – how hard would it be to add this uniqueID
binding? I’m thinking it would be a completely separate table, but the
uniqueID field could also be added to the Tickets table. This method should
work for any monitoring system where a unique string could be generated that
is tied to the lifetime of an event.

Mark----- Original Message -----
From: “seph” seph@commerceflow.com
To: “Ted Serreyn” ted@serreyn.com
Cc: rt-users@lists.fsck.com
Sent: Wednesday, August 21, 2002 5:18 PM
Subject: Re: [rt-users] mon and rt

The problem with any of these systems, is that mon doesn’t know
about ticket numbers, so if the problem gets fixed and you get an
up-alert, there is no way that I have found to close the opened
ticket.

This was one of the issues I was curious how the other person who did
the mon/rt stuff did. I can think of a couple ways, none very clean.

If I come up with something clean, I’ll send it to the various contrib
sections.

seph

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm