[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