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