logfetch unreliable?

I'm happy that I could help. :-)

-- 
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

That's where I went first, but then somewhere I read there was a MAX value
and I thought I was there. But now that you put the two values next to
each other .... clearly!
and the man page shows
    log:/var/log/messages:10240

so clearly I have room. I will up that. I also noted that my entry in
analysis.cfg

        LOG /var/log/rmsupload.log "failed. File Transfer Failed. Notify
Mainframe On-Call. (rmsupload.sh)"

is way more specific. It should have worked, but maybe I should make it
less specific to maximize my chances.

Thanks for thinking with me.

Date: Tue, 24 Sep 2013 10:03:59 -0400
Subject: Re: [Xymon] logfetch unreliable?
From: user-cc5c6e80f4c5@xymon.invalid
To: user-66e2e196cd54@xymon.invalid
CC: xymon at xymon.com

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