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