Inspired by this and this here (and this too). It started from this example, coming from another domain: “You’re hired on at a new company placed in charge of securing their online business. You know next to nothing about the technical details of the infrastructure other than they have no existing web/software security program and a significant portion of the organizations revenues are generated through their websites. What is the very first thing do on day 1?” At about the same time, I saw a message posted to one of the mailing lists where the poster wondered: "I’ve been asked to look into finding a replacement to our current log management/auditing system.  This is a field I haven’t even come close to touching before, and really don’t know the ideal things to look for (or ignore), etc. I’ve been searching through SANS site as well as googling, and I’m not coming up with a lot of great starter information. " And then he asks "Where should I start?" This is indeed a really good question!  Let's rephrase the above for the case of logging: "You’re hired on at a new company placed in charge of TAKING CONTROL OVER THE LOGS. You know next to nothing about the technical details of the infrastructure other than they have no existing LOG MANAGEMENT process and tools... What is the very first thing do on day 1?” So the "Day 1" of a log management project. What's up?! The very first thought that should cross you mind before you even do whatever first thing you wanted to do is "WHY?" "Log management" is a solution, not a problem. What is your problem that you now have a mandate to solve? In other words "Why log management for you?" Logs server way too many different purposes so that proceeding without asking "Why?" is dangerous. What is it that motivated your boss (or his boss, or whoever) to decide to "address this", to "take control over logs?" Was it a new compliance mandate, PCI perhaps? Was it a recent incident where investigation hit the wall due to utter lack of logs? Was it a new corporation-wide IT efficiency improvement project? Was it a lawsuit where an e-discovery request was not satisfied and thus fine was levied? Was it a hot IT project that is impossible to complete without having a tool to analyze logs? This "need" is very important since logging is a huge realm and not focusing on the need is akin to starting a journey into a hostile wilderness without  a map - in other words, it might be fun for a while, but it will probably end badly. Next, what do you actually do first? Figure out what logs are needed for this effort and what systems produce them (and who is responsible for them!) Analyzing SAP logs for J-SOX is a VERY different effort from analyzing Cisco ASA logs for network troubleshooting. Only at this point you can start thinking about "tools:" parsers, logs, databases, reports, alerts, indexing and other technical things as well as capacity planning, scalability, etc. This is the stage where you learn the lingo and learn to cut through marketing messaging to get to the actual tool capabilities. So, remember: given mandate to "tame the logging monster", think "WHY?" first!