tbird> 2) Given a particular operating system and/or system purpose tbird> (such as a UNIX mail server, or a Windows Domain Controller, or tbird> whatever), what are the (pick your favorite integer) 15 most tbird> frequently logged messages in the elusive "typical" tbird> environment? What do they mean? Do we have sample data? ebersman> I think the key problem is that in order to do this, you ebersman> have to define "standard" platform/usage profiles. Most of ebersman> us can't even get that for the company we're working for at ebersman> the time, much less across the Internet. B^) tbird> Yeah, yeah, yeah, and for decades, system administrators have tbird> talked themselves out of doing the experiment with arguments tbird> exactly this way. Part of my point is that different apps will need different knobs/alarms at significantly different usage levels. What I need to maintain 1000 users and 20,000 emails a day isn't what I'd need if I had 2Meg users and 20 machines churning 2Meg emails/day each. The amount of constraints we'd have to put on variables to get statistically accurate samples would make the results of limited use. If we could lock down configs and apps with no variation based on "we've still got these P1s, use them!" or "our funding depends on using the froobaz mailer even if sendmail works better" or whatever other stupidity realities throws us, we probably wouldn't have most of our security/system problems. tbird> Look, everyone, presumably at least some of us have access to tbird> log data on a "live server." I posit that we'll learn really tbird> really interesting things by taking a day's or a week's worth tbird> of data and looking at the messages. [...] tbird> My hope is that by providing this sort of information we'll tbird> make it easier for people to get up to speed on what is and is tbird> not typical >>for them<<. 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. Most folks don't learn any forensic techniques until something's already exploded and most literature I've seen deals with those explosions. Everyone always says "log and you'll know what's normal" but I haven't seen too many folks give good examples of how to weed through things during normal operations. ebersman> I'll posit the next straw man to torch: what would be useful ebersman> is a standardized methodology for how to turn two weeks of ebersman> verbose logging into a template against which to compare ebersman> "normal", "abnormal" and "catastrophic" at your particular ebersman> site/application. This does assume your first point of ebersman> somewhat standardized logging being available on all ebersman> critical OSs and Apps. tbird> Remember that by "standardized logging" I'm not >>even<< tbird> worrying about log formats or severities --just message tbird> categories. Taking yet another step back. Agreed. My use of "standardized logging" is simply message format, not message content. I'm also making the assumption that when I turn the logging knob to "log everything" that your goal of programming standards of logging for OS and App has turned into something useful. _______________________________________________ LogAnalysis mailing list LogAnalysisat_private https://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Tue Aug 20 2002 - 08:03:19 PDT