[Xymon] duration of MSG red status

[Bill Arlofski]

On 10/24/2014 05:41 PM, Novosielski, Ryan wrote:
>> On Oct 24, 2014, at 14:50, J.C. Cleaver <cleaver at terabithia.org> wrote:
>>
>>> On Fri, October 24, 2014 8:13 am, Nicole Beck wrote:
>>> Hello,
>>> I think this has been asked before, but it was a long time ago and I
>>> wondered if something changed since then.
>>>
>>> How long will the status of MSGS stay red?  We just setup monitoring
>>> recently and it seems like it stays red for about 30 minutes. Is that
>>> normal?  Is this configurable?
>>>
>>> We are running Xymon server 4.2.3.
>>
>> Nicole,
>>
>> The duration of the 'msgs' test is actually a function of how many cycles
>> back logfetch will scan for content to include in the log data going
>> forward (actual calculation of the color is via the regex's performed by
>> xymond_client).
>>
>> logfetch will look back 6 runtime-positions which, combined with the
>> default xymonclient run interval of 5m, ends up causing the 30m figure.
>>
>> The former value is compiled in, however the run frequency is
>> configurable. (We run our clients on 100s cycles, which means our msgs
>> tests last for 10-12m.)
>>
>>
>> I'm not sure how easy the 6x positions would be to be made dynamic or a
>> runtime option, but that would be nice.
> 
> Could have sworn the number of lines to look at was configurable too. Maybe I'm thinking of BB?

Hi Ryan, I was thinking the same thing, but I think we may be thinking of the
max bytes to send. from client-local.cfg docs:

log:/var/log/messages:10240 - The log:FILENAME:SIZE line defines the filename
of the log, and the maximum amount of data (in bytes) to send to the Xymon server.


This thread caused me to start thinking about a similar problem I have not had
time to look into for a long time, and I think Xymon has an option that might
fix both of our problems.

My situation:
I have a  custom script on a server that checks licenses for Zimbra email
archiving accounts.  If all the available "archiving account" licenses have
been used, and an archiving account is attempted to be created, the script
will log:

"error: ArchivingAccountsLimit exceeded: 163/125"


When I set script and Xymon logfile test this up, I tested it and Xymon
properly reported yellow and I thought I was set.  I didn't realize that it
was only staying yellow for 30 minutes.  So once my testing was done, I set
the script to run at 2:00am daily and thought I was done.

Unfortunately, this just means that every morning at 2am this test goes yellow
for 30 minutes and is green by the time the IT people come in. (They do not
get/want alerts for anything other than some temperatures currently)

So... while re-investigating this, I see that the client-local.cfg has an
optional trigger:PATTERN option for logfiles which states:


"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 have not tested this, but it would seem to indicate that it would cause the
client to send the Xymon server all the lines that match the trigger pattern
(regardless of how far back in time they go in the logfile) which should cause
the test to stay non-green until the logfile is rotated and no more lines with
the trigger pattern exist.

Can anyone confirm or deny this functionality?


Bill



-- 
Bill Arlofski
Reverse Polarity, LLC
http://www.revpol.com/
-- Not responsible for any advertising below this line --