What Every IT Pro Needs to Know About Log Management

wabbott

Log management and analysis tools are powerful and can solve a wide range of problems within the security, troubleshooting, analytics, and compliance use cases. With the variety of tools and features, selecting the right solution can be tricky.

In this session, Mav Turner, Troy Bailey, and Jerry Schwartz will cover specific use cases, recommend the best tools for each, and present best practices, tips, and tricks for getting the most out of your log management.

In your opinion, what should every IT Pro need to know about log management? What do you wish someone had told you sooner?

Resources:

LEM Training - SolarWinds Worldwide, LLC. Help and Support

Papertrail - cloud-hosted log management, live in seconds

Syslog Server Windows - Log Server | Kiwi Syslog Server

Attend this session for a chance to win a FREE license of LEM!

Terms & Conditions

troyd

I'm a tiny bit biased, since I'm one of the session participants Here's a few questions/topics that I think about all the time and which are likely to come up in my answers:

• How to avoid over-thinking the problem and solve the specific problem(s) that I actually have.
  
  The software development world has iterative/incremental development (Iterative and incremental development - Wikipedia, the free encyclopedia ), and that's very loosely how log management - and most other operational processes and tools - should be implemented: solve the most pressing tiny problem; repeat until satisfied. That "tiny problem" isn't "log management," it's something specific ("One of our JVM processes keeps running out of memory, so I want a notice in Slack when a process runs out of memory or segfaults.")

• How I think about log-related problems. To me, problems that logs can solve fall into 4 buckets: operational visibility/troubleshooting ("What caused.. ?"), analytics ("How many.. ?"), practical security ("Are this request's query parameters an XSS attempt?"), and/or regulatory compliance ("Do we satisfy.. ?").
  
  While these 4 aren't completely zero-sum, they have different-enough implementation requirements that improving one usually weakens at least 2 of the others. 2 simple examples: a product/service that's built for PCI compliance will trade away usability/UX and operational troubleshooting (and probably should). OTOH, a product/service that's built for practical troubleshooting may be great for problems in the past few weeks, but will either be slower, more complex, or more expensive for, say, a year worth of data. This comes back to thinking less about "log management" and more about specific problems or questions/outcomes that are valuable to a business.

Troy