On Fri, July 11, 2014 11:20 am, Asif Iqbal wrote:
On Thu, Jul 10, 2014 at 11:24 AM, Bauer-Lee, Sue <
user-84011281759f@xymon.invalid> 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 user-dfde56b39b09@xymon.invalid
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