[Xymon] logfetch unreliable?

[Mike Burger]

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: 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
>> >
>>
>
>  		 	   		  _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>