[Xymon] logfetch unreliable?

[Bakkies Gatvol]

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

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