<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.34">
<TITLE>RE: [hobbit] Logfile monitoring - I'd like some comments</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>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?). </FONT></P>
<P><FONT SIZE=2>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)</FONT></P>
<P><FONT SIZE=2>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. </FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<BR>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Hubbard, Greg L [<A HREF="mailto:greg.hubbard@eds.com">mailto:greg.hubbard@eds.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, February 15, 2006 5:40 PM</FONT>
<BR><FONT SIZE=2>To: hobbit@hswn.dk</FONT>
<BR><FONT SIZE=2>Subject: RE: [hobbit] Logfile monitoring - I'd like some comments</FONT>
</P>
<BR>
<P><FONT SIZE=2>My two cents/pence/francs/pesetas/whatever (I am overcharging):</FONT>
</P>
<P><FONT SIZE=2>I think it would be cool if the Hobbit client could watch arbitrary log</FONT>
<BR><FONT SIZE=2>files for arbitrary messages and turn that into status alarms. But</FONT>
<BR><FONT SIZE=2>don't assume that /var/log or /var/adm or /var/adm is accessible to</FONT>
<BR><FONT SIZE=2>ordinary (as in Hobbit client) users -- not around here, anyway.</FONT>
<BR><FONT SIZE=2>Besides, I already have another solution for managing my UNIX syslogs --</FONT>
<BR><FONT SIZE=2>what I don't have is a way to manage all of my application log files.</FONT>
</P>
<P><FONT SIZE=2>Wonder how it would work if the client somehow retrieved "orders" from</FONT>
<BR><FONT SIZE=2>the BB server at startup and this was used to drive a client-side</FONT>
<BR><FONT SIZE=2>scanner? I like the notion of centralized configuration, but...</FONT>
</P>
<P><FONT SIZE=2>Otherwise, you might as well forward all the logs to the central server</FONT>
<BR><FONT SIZE=2>(syslog-ng?) and have the server parse them. But this wouldn't work for</FONT>
<BR><FONT SIZE=2>the logs that I want to root through with the clients.</FONT>
</P>
<P><FONT SIZE=2>GLH </FONT>
</P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Rob Munsch [<A HREF="mailto:rmunsch@solutionsforprogress.com">mailto:rmunsch@solutionsforprogress.com</A>] </FONT>
<BR><FONT SIZE=2>Sent: Wednesday, February 15, 2006 4:22 PM</FONT>
<BR><FONT SIZE=2>To: hobbit@hswn.dk</FONT>
<BR><FONT SIZE=2>Subject: Re: [hobbit] Logfile monitoring - I'd like some comments</FONT>
</P>
<P><FONT SIZE=2>Henrik Stoerner wrote:</FONT>
</P>
<P><FONT SIZE=2>>the amount of log data that Hobbit needs to process. So you can setup a</FONT>
</P>
<P><FONT SIZE=2>>regexp of stuff in the logfile that you *never* want to see, and a </FONT>
<BR><FONT SIZE=2>>regexp of stuff that you *always* want to report - regardless of how </FONT>
<BR><FONT SIZE=2>>much the log grows.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>Well, that covers my comment. I'd much rather give a list of "this</FONT>
<BR><FONT SIZE=2>stuff is always Good" than try to cover every instance of Bad, so that's</FONT>
<BR><FONT SIZE=2>awesome.</FONT>
</P>
<P><FONT SIZE=2>It would be ideal if the central config was somewhat bb-hosts-ish, and</FONT>
<BR><FONT SIZE=2>could accept (in addition to aforementioned includes) host-specific</FONT>
<BR><FONT SIZE=2>directives for what to log. I am assuming that how to react will</FONT>
<BR><FONT SIZE=2>already be host-specific like every other test, yes?</FONT>
</P>
<P><FONT SIZE=2>As far as the logs rotating out... couldn't hobbit look for an</FONT>
<BR><FONT SIZE=2>environment variable for the format of the rotated logs...? The</FONT>
<BR><FONT SIZE=2>filenames vary host to host, but on a given host, a quick look at</FONT>
<BR><FONT SIZE=2>/var/log tells you what to expect, right? </FONT>
</P>
<P><FONT SIZE=2>Lastly - being someone who couldn't program his way out of a paper</FONT>
<BR><FONT SIZE=2>stack, i will now cheekily suggest that on install, hobbit could look at</FONT>
<BR><FONT SIZE=2>/var/log and guesstimate the format, and ask for human confirmation (as</FONT>
<BR><FONT SIZE=2>it already does for the hobbit user and homedir).</FONT>
</P>
<P><FONT SIZE=2>Even if this automated | dream doesn't happen, could it still be set</FONT>
<BR><FONT SIZE=2>manually or via config?</FONT>
</P>
<P><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>Rob Munsch</FONT>
<BR><FONT SIZE=2>Solutions For Progress IT</FONT>
</P>
<BR>
<P><FONT SIZE=2>To unsubscribe from the hobbit list, send an e-mail to</FONT>
<BR><FONT SIZE=2>hobbit-unsubscribe@hswn.dk</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=2>To unsubscribe from the hobbit list, send an e-mail to</FONT>
<BR><FONT SIZE=2>hobbit-unsubscribe@hswn.dk</FONT>
</P>
</BODY>
</HTML>