> Paul Ebersman <list-loganalysisat_private> > Sent by: loganalysis-adminat_private 08/20/02 10:51 AM > To: loganalysisat_private > cc: > Subject: [logs] Re: What's normal? > > tbird> Yeah, yeah, yeah, and for decades, system administrators have > tbird> talked themselves out of doing the experiment with arguments > tbird> exactly this way. > > Fair enough. But I'd still guess that for most newbies, the real first > problem is learning to drink from the firehose. Coming up with some > semi-standard way of chewing through megabytes of raw logs to figure > out your baseline would be useful even if we *never* come up with a > standardized configuration. I listen more than speak on mailing lists such as this one; this is probably not even my fifth post to this particular list. However, I read with great interest not Tina's initial message, but her restatement of a longish list of default behaviours that she'd like to see logged (or treated in this discussion). There appears to be tension between "descriptive" and "normative" here. As a designer/architect of applications systems and "data center environments", I recognize the need for categorization/classification (descriptive); the most benefit I've seen reaped in the past came from automated software that processed thousands of emails from applications across more than 100 enterprise-class UNIX boxes in a data center - back in the days when syslog was broken on most UNIX flavors. Categorization is "low-hanging fruit". However, what could *really* be exciting would be breaking new ground - yes, think of templates for "format" (but interpret that word as loosely as possible!). Yes, if a "segregation" scheme can be devised, it would be a huge gain for "newbies" - or for the senior admin who's just thinking about moving to a new logging architecture and wants to be using it effectively *today*. Combining these two perspectives, then, might result in the following solution characteristics: 1. Provide a *common*, default, out-of-the-box config that maximizes flexibility and that can be provided with package downloads such as syslog-ng, and used immediately. as we all know, compiling an enterprise or system management app is usually only 2-10% of the job. The first time I set up "cups" it took me *days* for my particular environment (with an unusual samba environment). There just isn't an "on-ramp" in too many cases. 2. Provide a "package recommendation" for log analysis that processes the raw data produced using the specification of (1) above. 3. (ideal) Provide functional feedback to a) logging facilities software maintainers/developers and b) logging analysis sw maintainers/developers with lessons learned from (1) and (2) above. I know I'd have liked to not have to process raw data in my past experiences. Front-loading *some* of the statistical analysis, "close to" if not within the local logging facility, would allow, for example, a "remote logging" server to send over "15 DEBUG last 30 min message 'Attempted Access modem port /dev/cua0'" rather than receiving the actual 15 messages. Admittedly it could be done anywhere in this architecture, and I'm simply putting forth a rather simplistic example; but, there may be many cases where "close to the action" intelligence makes more sense than a big honking "logging processor". I'm sure there are other dimensions to the discussion that I've omitted; this is just my $0.02 concerning the direction the conversation is taking. Regards, Bill Hudacek IBM Global Services "There has grown in the minds of certain groups in this country the idea that just because a man or corporation has made a profit out of the public for a number of years, the government and the courts are charged with guaranteeing such profit in the future, even in the face of changing circumstances and contrary to public interest. This strange doctrine is supported by neither statue or common law. Neither corporations or individuals have the right to come into court and ask that the clock of history be stopped, or turned back." -Robert Heinlein, Life Line, 1939 _______________________________________________ LogAnalysis mailing list LogAnalysisat_private https://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Tue Aug 20 2002 - 11:32:47 PDT