(Resending, as I forgot to include the list)
Per the man page for client-local.cfg
(http://http://www.xymon.com/xymon/help/manpages/man5/client-local.cfg.5.html:
"The trigger PATTERN line (optional) is used only when there is more data
in the log than the maximum size set in the "log:FILENAME:SIZE" line. The
"trigger" pattern is then used to find particularly interesting lines in
the logfile - these will always be sent to the Xymon server. After picking
out the "trigger" lines, any remaining space up to the maximum size is
filled in with the most recent entries from the logfile. "PATTERN" is a
regular expression."
I don't see anything where it's supposed to do anything more than send
those entries to the "msgs" area in Xymon.
You'd have to actually put together something that causes that pattern to
generate a status (yellow, red) and then something in the alerts.cfg to
actually send out an alert, if so desired.
--
Mike Burger
http://www.bubbanfriends.org
"It's always suicide-mission this, save-the-planet that. No one ever just
stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1
On Sunday, September 8, I'll be participating in the Spokes of Hope ride,
to raise money for cancer awareness and make a difference in the lives of
cancer victims and their families/friends. If you'd care to donate, please
click:
http://ow.ly/nIdrC
Thank you.
I am in the throws of replacing a commercial monitoring product with
xymon. (Before this product we ran big brother. )
But I am in a pickle. The commercial product picked up a log entry last
night, that xymon did not. I know this because both products are alerting
currently. My biggest issue is the non-report is not reproducible. If I
send test messages into my fake log, it works - but I have proof it failed
last night in the real log file. How do I even go about debugging this?
My client-local.cfg has
[nemo]
log:/var/log/fake.log:1024
trigger "Notify Mainframe On-Call."
log:/var/log/rmsupload.log:1024
trigger "Notify Mainframe On-Call."
G