logfetch unreliable?

Have you considered increasing the amount of data being reviewed on the
log line (1024...change to 10240, perhaps)?
-- 
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

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: user-cc5c6e80f4c5@xymon.invalid
To: user-66e2e196cd54@xymon.invalid

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