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:
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
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:
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
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:
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
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. NotifyMainframe 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:
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
participants (2)
-
bakgat8＠hotmail.com
-
mburger＠bubbanfriends.org