[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mon
Subject:    Re: Asynchronous Events
From:       Kevin Handy <kth () srv ! net>
Date:       2001-08-08 18:20:03
[Download RAW message or body]

Jon Meek wrote:
> 
> Ok, I have just implemented "remote alerts" in the past few days.

I finally got this to work, with only a couple of problems.
Thought I'd report here (so others may learn from my misteaks)

First problem was that the version of mon shipped with RedHat 7.1
would crash (trying to write to a $2 in a read only match string, 
which is fixed in mon-0.38.21). Updating to version 0.38.21 fixes 
this.

> Try this.
> 
> In your mon config set up two new watches:
> 
> watch default
>     service default
>         period wd {Sun-Sat}
>             alert mail.alert name@address.com
> 
> watch pr-internet
>     service http_tp
>         period wd {Sun-Sat}
>             alert mail.alert name@address.com
> 

I had to reverse these two watches, otherwise it seemed to
want to go to the default one, and not the pr-internet one
when asked (I'm guessing it stops at the first one that matched)

> Restart or SIGHUP mon so that it reads the new config file.
> 
> Then, from a remote machine run remote.alert (in the alert.d directory),
> where yourmon.mon.com is your mon machine.
> 
> ./remote.alert -H yourmon.mon.com
> Summary line
> Detail line 1
> Detail line 2
> ^D
> 
> This should trigger a "default" alarm on the mon machine. Now, if you want
> the alarm to hit the pr-internet / http_tp watch / service then do:
> 
> ./remote.alert -H yourmon.mon.com -g pr-internet -s http_tp
> Summary line
> Detail line 1
> Detail line 2
> ^D
> 
> So, your asynchronous event generating program could run remote.alert, or
> you could incorporate its functionality in your program.

How stable is the interface used by remote.alert? If it is likely
to change radically in the near future, it may be better to pipe to
it, but if it is stable it may be more reliable to include the
code in the program (fewer things that can break).
I've had problems with (rare) failures to create a pipe in perl 
programs 'open(XXX, "| ...")', so you have to catch this error and then
try again, and then etc.. Usually easier to do it yourself instead
of trying to put in all the error trapping around it.

It seems like it almost immediately writes to /var/log/messages,
but the e-mail takes some time to make it to me (30 seconds or more)
on same machine.  This may have something to do with the way e-mail 
is set up on my test machine, but I haven't had a chance to dig 
deeper yet.

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic