[Xymon] system reboot email alert

J.C. Cleaver cleaver at terabithia.org
Fri Jul 11 22:14:25 CEST 2014


On Fri, July 11, 2014 11:20 am, Asif Iqbal wrote:
> On Thu, Jul 10, 2014 at 11:24 AM, Bauer-Lee, Sue <
> Sue.Bauer-Lee at multiplan.com> wrote:
>
>> And if not, suggestions for a simple approach? I’m not exactly getting
>> the
>> desired results server-wide with an external script that should just
>> send
>> an email for a CPU status color=yellow without interfering with our
>> other
>> configured alerts. L
>>
>
> You could right a server side extension script based on the [uptime]
> section of clientdata
>
>

Yeah, the state model does tend to break down when trying to interpret
one-time events like this (monitoring systems tend to fall into one camp
or the other philosophically).

Getting the data in is easy enough: either parsing uptime, or cat-ing in
/proc/uptime to get it in a single value, the question is whether it's
especially useful to "waste" an entire status column in memory just for
this.

The one spot in xymon that does work around event-based tracking is the
log file parser or 'msgs' test, which converts a point-in-time event into
a 6x(runtime)-long stateful alert. As a quick hack, you could look for
strings that occur in the log file only on a (normal) bootup and trigger
those as a critical alert:

Something like...

analysis.cfg:
  LOG /var/log/messages "kernel:  bootmap" COLOR=red GROUP=hostrestart
  LOG /var/log/messages "%(?-i)syslog.+start" COLOR=red GROUP=hostrestart

alerts.cfg
SERVICE=msgs COLOR=red GROUP=hostrestart
  MAIL me at example.com


This is... totally untested, but I think it should work.

Longer-term, yeah it would be nice to have a single "fake" status column
that would accept non-stateful event alerts (or modify's) and passes them
through. It might make integration with other alerting systems easier.


HTH,
-jc




More information about the Xymon mailing list