RE: [hobbit] Logfile monitoring - I'd like some comments

["Deiss, Mark" <Mark.Deiss (at) acs-inc.com>]

Suggest that the framework be able to support a client side model in
addition to the server side model being contemplated (i.e. a bulk of the
handling being done on the hobbit collector server). It is fine to talk
about some initial client side processing and passing assorted areas of
interest from system and application log files for the real work to be done
on the collector. The point about administrating multiple clients from a
central collector with rules is well taken. (Aside: why not use swatch as
much as possible?). 

I think client-side processing will be important on AIX and Tru64 servers
which maintain system error logs that are in a binary format. You need the
platform tools to effectively parse the output. Passing this out in date
ranges for later, further processing on a hobbit collector will result in a
maintenance support issue. You need some flexibility in how much to pass on
which I do not see being practical on a collector-side model. The AIX and
Tru64 crowd will still be spending time on the clients making client-side
rule decisions on their regular expressions on how much to relay to the
collector for a particular event. Getting a valid set of information out of
a particular event is not always a simple, predictable matter.  This area
has been addressed with external modules developed on deadcat using
different approaches. It would appear sites using AIX and Tru64 will be
starting from scratch with the Hobbit model and will need to develop some
new tools to fit within the Hobbit collector side model. Gets worse for
Tru64 with the newer versions that require parsing tool sets that even HP
support is not happy with. I am amused per the one HP list recommendation
that you do not parse the ~5.1+ binary error logs - for a failure, you ship
the logs to HP support and let them struggle with it. (sigh....I have
resorted to scanning the newer logs using the older tools such as dia out of
desperation)

At least initially, the easist approach would be for the Hobbit collector
side approach to follow the stated aim regarding the ascii text files,
application and OS. The AIX and Tru64 sites may want to run one of the
deadcat variants as a client side only model and tweak it as a totally
separate client test. 

For the linux client base, why not configure logwatch to parse your
application/system logs and pump them over into the hobbit collector for the
additional processing? This product is capable of handling log files with
various date names. I "think".... it may also be able to handle compressed
files.


-----Original Message-----
From: Hubbard, Greg L [mailto:greg.hubbard (at) eds.com]
Sent: Wednesday, February 15, 2006 5:40 PM
To: hobbit (at) hswn.dk
Subject: RE: [hobbit] Logfile monitoring - I'd like some comments


My two cents/pence/francs/pesetas/whatever (I am overcharging):

I think it would be cool if the Hobbit client could watch arbitrary log
files for arbitrary messages and turn that into status alarms.  But
don't assume that /var/log or /var/adm or /var/adm is accessible to
ordinary (as in Hobbit client) users -- not around here, anyway.
Besides, I already have another solution for managing my UNIX syslogs --
what I don't have is a way to manage all of my application log files.

Wonder how it would work if the client somehow retrieved "orders" from
the BB server at startup and this was used to drive  a client-side
scanner?  I like the notion of centralized configuration, but...

Otherwise, you might as well forward all the logs to the central server
(syslog-ng?) and have the server parse them.  But this wouldn't work for
the logs that I want to root through with the clients.

GLH 

-----Original Message-----
From: Rob Munsch [mailto:rmunsch (at) solutionsforprogress.com] 
Sent: Wednesday, February 15, 2006 4:22 PM
To: hobbit (at) hswn.dk
Subject: Re: [hobbit] Logfile monitoring - I'd like some comments

Henrik Stoerner wrote:

>the amount of log data that Hobbit needs to process. So you can setup a

>regexp of stuff in the logfile that you *never* want to see, and a 
>regexp of stuff that you *always* want to report - regardless of how 
>much the log grows.
>
Well, that covers my comment.  I'd much rather give a list of "this
stuff is always Good" than try to cover every instance of Bad, so that's
awesome.

It would be ideal if the central config was somewhat bb-hosts-ish, and
could accept (in addition to aforementioned includes) host-specific
directives for what to log.  I am assuming that how to react will
already be host-specific like every other test, yes?

As far as the logs rotating out... couldn't hobbit look for an
environment variable for the format of the rotated logs...?  The
filenames vary host to host, but on a given host, a quick look at
/var/log tells you what to expect, right? 

Lastly - being someone who couldn't program his way out of a paper
stack, i will now cheekily suggest that on install, hobbit could look at
/var/log and guesstimate the format, and ask for human confirmation (as
it already does for the hobbit user and homedir).

Even if this automated | dream doesn't happen, could it still be set
manually or via config?

--
Rob Munsch
Solutions For Progress IT


To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe (at) hswn.dk



To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe (at) hswn.dk