<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">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!<br>and the man page shows<br> log:/var/log/messages:10240
<br>so clearly I have room. I will up that. I also noted that my entry in analysis.cfg<br><br> LOG /var/log/rmsupload.log "failed. File Transfer Failed. Notify Mainframe On-Call. (rmsupload.sh)"<br><br>is way more specific. It should have worked, but maybe I should make it less specific to maximize my chances.<br><br>Thanks for thinking with me. <br><br><br><br><div>> Date: Tue, 24 Sep 2013 10:03:59 -0400<br>> Subject: Re: [Xymon] logfetch unreliable?<br>> From: mburger@bubbanfriends.org<br>> To: bakgat8@hotmail.com<br>> CC: xymon@xymon.com<br>> <br>> Have you considered increasing the amount of data being reviewed on the<br>> log line (1024...change to 10240, perhaps)?<br>> -- <br>> Mike Burger<br>> http://www.bubbanfriends.org<br>> <br>> "It's always suicide-mission this, save-the-planet that. No one ever just<br>> stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1<br>> <br>> <br>> ><br>> ><br>> ><br>> > Yes, yes I have all that. But fair point. It did not show up in nemo -<br>> > msgs<br>> ><br>> > from history:<br>> ><br>> > Date Status Duration<br>> ><br>> > Mon Sep 23 17:55:51 2013 yellow 0:10:03<br>> > Tue Aug 13 13:56:01 2013 green 41 days 3:59:50<br>> ><br>> > The entry I wanted (see below) was at about 17:05 and as you can see above<br>> > msgs was happily green. The yellow was me adding the fake file entry -<br>> > without adding the file yet. So it threw a legit error. If cut a chunk of<br>> > the file and cat it into the fake file - it alerts perfectly. So I believe<br>> > my alert setup is good. And msgs does turns red - just to be specific.<br>> ><br>> > 451 Transfer aborted due to file error. File is catalogued.<br>> > 221 Quit command received. Goodbye.<br>> > /usr/local/bin/rmsupload.sh[27694]: Fatal error: RMS Report upload for<br>> > rmsfile43 failed. File Transfer Failed. Notify Mainframe On-Call.<br>> > (rmsupload.sh)<br>> > Mon Sep 23 17:05:58 EDT 2013 /usr/local/bin/rmsupload.sh[28432]:<br>> > Arguments: 32 181 /ftpstage/rms/HEERDTS.10094575_MAINFRAME_ASCII.txt.tmp<br>> > Mon Sep 23 17:05:58 EDT 2013 /usr/local/bin/rmsupload.sh[28432]:<br>> > converting /ftpstage/rms/HEERDTS.10094575_MAINFRAME_ASCII.txt.tmp to<br>> > /ftpstage/rms/rmsupload28432.t<br>> ><br>> ><br>> >> Date: Tue, 24 Sep 2013 09:46:25 -0400<br>> >> Subject: Re: [Xymon] logfetch unreliable?<br>> >> From: mburger@bubbanfriends.org<br>> >> To: bakgat8@hotmail.com<br>> >><br>> >> Per the man page for client-local.cfg<br>> >> (http://http://www.xymon.com/xymon/help/manpages/man5/client-local.cfg.5.html:<br>> >><br>> >> "The trigger PATTERN line (optional) is used only when there is more<br>> >> data<br>> >> in the log than the maximum size set in the "log:FILENAME:SIZE" line.<br>> >> The<br>> >> "trigger" pattern is then used to find particularly interesting lines in<br>> >> the logfile - these will always be sent to the Xymon server. After<br>> >> picking<br>> >> out the "trigger" lines, any remaining space up to the maximum size is<br>> >> filled in with the most recent entries from the logfile. "PATTERN" is a<br>> >> regular expression."<br>> >><br>> >> I don't see anything where it's supposed to do anything more than send<br>> >> those entries to the "msgs" area in Xymon.<br>> >><br>> >> You'd have to actually put together something that causes that pattern<br>> >> to<br>> >> generate a status (yellow, red) and then something in the alerts.cfg to<br>> >> actually send out an alert, if so desired.<br>> >><br>> >> --<br>> >> Mike Burger<br>> >> http://www.bubbanfriends.org<br>> >><br>> >> "It's always suicide-mission this, save-the-planet that. No one ever<br>> >> just<br>> >> stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1<br>> >><br>> >> On Sunday, September 8, I'll be participating in the Spokes of Hope<br>> >> ride,<br>> >> to raise money for cancer awareness and make a difference in the lives<br>> >> of<br>> >> cancer victims and their families/friends. If you'd care to donate,<br>> >> please<br>> >> click:<br>> >><br>> >> http://ow.ly/nIdrC<br>> >><br>> >> Thank you.<br>> >><br>> >><br>> >> ><br>> >> ><br>> >> ><br>> >> > I am in the throws of replacing a commercial monitoring product with<br>> >> > xymon. (Before this product we ran big brother. )<br>> >> ><br>> >> > But I am in a pickle. The commercial product picked up a log entry<br>> >> last<br>> >> > night, that xymon did not. I know this because both products are<br>> >> alerting<br>> >> > currently. My biggest issue is the non-report is not reproducible.<br>> >> If I<br>> >> > send test messages into my fake log, it works - but I have proof it<br>> >> failed<br>> >> > last night in the real log file. How do I even go about debugging<br>> >> this?<br>> >> ><br>> >> > My client-local.cfg has<br>> >> ><br>> >> > [nemo]<br>> >> > log:/var/log/fake.log:1024<br>> >> > trigger "Notify Mainframe On-Call."<br>> >> > log:/var/log/rmsupload.log:1024<br>> >> > trigger "Notify Mainframe On-Call."<br>> >> ><br>> >> ><br>> >> > G<br>> >> ><br>> >> > _______________________________________________<br>> >> > Xymon mailing list<br>> >> > Xymon@xymon.com<br>> >> > http://lists.xymon.com/mailman/listinfo/xymon<br>> >> ><br>> >><br>> ><br>> > _______________________________________________<br>> > Xymon mailing list<br>> > Xymon@xymon.com<br>> > http://lists.xymon.com/mailman/listinfo/xymon<br>> ><br>> <br></div></div>
</div></body>
</html>