Yes, yes I have all that. But fair point. It did not show up in nemo - msgs
from history:
Date Status Duration
Mon Sep 23 17:55:51 2013 yellow 0:10:03 Tue Aug 13 13:56:01 2013 green 41 days 3:59:50
The entry I wanted (see below) was at about 17:05 and as you can see above msgs was happily green. The yellow was me adding the fake file entry - without adding the file yet. So it threw a legit error. If cut a chunk of the file and cat it into the fake file - it alerts perfectly. So I believe my alert setup is good. And msgs does turns red - just to be specific.
451 Transfer aborted due to file error. File is catalogued. 221 Quit command received. Goodbye. /usr/local/bin/rmsupload.sh[27694]: Fatal error: RMS Report upload for rmsfile43 failed. File Transfer Failed. Notify Mainframe On-Call. (rmsupload.sh) Mon Sep 23 17:05:58 EDT 2013 /usr/local/bin/rmsupload.sh[28432]: Arguments: 32 181 /ftpstage/rms/HEERDTS.10094575_MAINFRAME_ASCII.txt.tmp Mon Sep 23 17:05:58 EDT 2013 /usr/local/bin/rmsupload.sh[28432]: converting /ftpstage/rms/HEERDTS.10094575_MAINFRAME_ASCII.txt.tmp to /ftpstage/rms/rmsupload28432.t
Date: Tue, 24 Sep 2013 09:46:25 -0400 Subject: Re: [Xymon] logfetch unreliable? From: mburger at bubbanfriends.org To: bakgat8 at hotmail.com
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:
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
_______________________________________________Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon