Tomorrow's Logging Problems - Part II

I would like to continue the discussion I started in my previous post called "Today's Logging Problems - Then Future Problems - Part I." Specifically, upon outlining some problems with logging, I will now forecast what will happen with them in 18-24 months.
- Which problems will be solved and forgotten?
- Which ones will simply go away?
- Which ones will persist and in fact increase?
- Finally, which new ones might emerge?
First, I'll predict that "Not knowing what to log" problem will be mostly solved in 18-24 months; at least as far as major regulations go, people will have a pretty good idea a) what the auditors want them to log (and review!) b) what they need to log for solving their problems. Now, esoteric log sources and custom application might still present a challenge from that point of view, but for basic "staples" (firewall, network gear, major OS) the mystery will be over (again, see "Tell me EXACTLY what to log for PCI?" for some reference) Next, the problem of "Log volume" will definitely get worse, much worse. One might think that 100,000 each second is a lot of log - but there WILL BE more at many companies! Big application log explosion is coming, fueled by the need to address logging in areas where such motivation was lacking before (basically, custom and vertical applications) as well as harness the power of "uncommon" logs for such tasks as fraud analysis or SOA monitoring. Keep in mind that even though in some areas logging is not a preferred way of monitoring and auditing activities (see this discussion on database logs here), application logging will still explode on us ... The problem of "Log diversity" (the fact that most logs all look different in format and meaning) will get worse before it will get better - and better it WILL get since standards are being developed. We will see people struggling with all sorts of bizarre log data in the coming years. Virtualization (on logs and VM), web services and SOA, various ERP applications and even cloud services will increase the diversity of logging in the coming years. Similar to the above, a problem of "Bad logs" (ones that are subjective, miss key information, require groping for a crystal ball to understand, turn log analysis into a painful experience or are useless in some other way) will also follow the pattern of the above log diversity problems - it will get worse before it gets better (via the CEE standard effort that now covers the OpenXDAS effort as well!) I noticed that people started asked me questions about "how to do application logging right?" and "what to tell application developers about logging?" which almost never happened in the past. More on this in the future! "Getting the logs" has gotten much easier in recent years; agentless collectors like Project Lasso (which, BTW, just got updated) and grabbing files remotely via secure protocols made application log collection easier (syslog-NG with TCP transfer and buffering also helped). Next, Windows 2008 will make it MUCH easier for the whole Windows kingdom due to their use of web services. However, in the future it might resurface as we try to collect logs from unusual places, again, clouds come to mind as well as virtual environments (e.g. how do you get logs off a dormant VM?). What's the next frontier in this area? Log discovery - automatic finding and identifying log files on systems in order to analyze and retain them. All this, however, pales in comparison with my favorite "uber-challenge", "Making sense of logs in an automated fashion" - this baby is definitely not going away in 2-3 years. Much more research is needed to make that "log->conclusion" jump automatically without head-scratching, invoking ancient deities and making wild guesses. Once there, we can attempt to reliably handle "proactive logging" (i.e. analyzing various failure or compromise precursors in logs and then predicting the future based on them), another Holy Grail of logging domain. Anything new will emerge? Yes, I think awareness of the "Logging Gap" problem will grow. "Logging gap" happens when you combine "a need to log" with utter "inability to do so." For example, this will happen when people will know that they HAVE TO log, say, for compliance, but will have no way of doing it due to application or platform limitations. This will become one of the challenges and special "logging add-ons" will appear to close the logging gap and create additional logs where activity audit is desperately needed, but native logging is not helping to achieve it. Also, I think people will finally wake up to "Log security" challenges - i.e. producing for use as evidence, compliance attestations, etc. Log security is not getting the attention it deserves, but I think this challenge will finally emerge in full force in the next 2-3 years. BTW, my next poll addresses that (vote) Anything else I missed? Share away! Related posts:
- jzhen's blog
- Login or register to post comments
- Feed: LogBlog
- Original article
User login
Current Poll
Developer Resources
Active Forum Topics
- Service crashing
- Syslog and Lasso
- Dual output from the Lasso server
- Identifying your Lasso Server
- Enhancement request: Sanitize message before sending
- Search All Via WebService Index Search
- failed get ready, Error 997 ??
- i-Tracing demonstration of creating a dashboard for a LogLogic customer
- Error: CommLasso::sendData(): Sending message stream failed ec(10053): 0 bytes of was already send. Possible duplicate message
- Open Portal Maintenance Notice

Recent Comments
3 weeks 6 days ago
4 weeks 10 hours ago
4 weeks 12 hours ago
4 weeks 1 day ago
4 weeks 3 days ago
4 weeks 3 days ago
4 weeks 3 days ago
4 weeks 4 days ago
4 weeks 5 days ago
4 weeks 5 days ago