[Xymon] logfetch unreliable?

[Bakkies Gatvol]

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: mburger at bubbanfriends.org
> To: bakgat8 at hotmail.com
> 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: 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:
> >>
> >> 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
> >> >
> >> >  		 	   		  _______________________________________________
> >> > Xymon mailing list
> >> > Xymon at xymon.com
> >> > http://lists.xymon.com/mailman/listinfo/xymon
> >> >
> >>
> >
> >  		 	   		  _______________________________________________
> > Xymon mailing list
> > Xymon at xymon.com
> > http://lists.xymon.com/mailman/listinfo/xymon
> >
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20130924/7f6d4b85/attachment.html>