Does Hobbits LOG directive parse line-by-line, or all data?
Charles Jones
jonescr at cisco.com
Wed Jun 13 21:54:05 CEST 2007
I have setup both types of logfile monitoring. In client-local, I have:
log:/some/application/logfile.log:10240
ignore MARK
linecount:/some/application/logfile.log
timeouts:.*Session.Timeout.*
The *log* directive makes the Hobbit client parse a particular
application log.
The *linecount* directive is being used so that Hobbit graphs the number
of "Session Timeout" errors in a particular application log.
My hobbit-clients.cfg includes this, for example:
LOG /some/application/logfile.log %.*Session.Timeout.* color=yellow
LOG /some/application/logfile.log %.*Session.Error.* color=red
The above two entries allow me to get Hobbit alerts if there are any
session timeouts in the log (yellow alert), or if there are any errors
in the log (red alert).
Now, what I need, is the ability to set alerts based upon HOW MANY
timeouts or errors are in the log. I'm thinking this regex should work
(it does according to pcretest):
LOG /some/application/logfile.log %(.*Session.Timeout.*){10,} color=red
The above *should* set a red condition if there are 10 or more Session
Timeouts in the log, or at least in the part of the log that Hobbit
received.
My question is...does Hobbits logfile parsing perform the multi-line
regex or single? If it applies the regex to the entire logfile, my
regex should work. If it only tests each line individually, it will not.
Other thoughts on Hobbits log monitoring:
* I think it makes more sense for the the "linecount" to be in
hobbit-clients.cfg instead of client-local.cfg
* Its sort of confusing that "linecount" does not require a % in front
of a regex, like everything else in Hobbit does (at least according to
the man pages)
* Why do we need client-local.cfg at all? Couldn't these directives all
be done via hobbit-clients.cfg, and any clients that are using local
instead of server-side config would then use client-local.cfg?
* If Hobbit indeed does parse line-by-line and such my regex would fail,
perhaps linecount could have an additional parameters to set an alert if
the linecount is exceeded, something like: linecount filename pattern
<optional minimum yellow count> <optional minimum red count>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20070613/f629ad5f/attachment.html>
More information about the Xymon
mailing list