Re-Architecting Log Management for DevOps

Source – itbusinessedge.com

Log management in a DevOps environment requires a lot more than just the right platform. As enterprises become more steeped in DevOps processes, tools like deep visibility and AI-driven analytics are proving invaluable to continuous integration/continuous deployment (CI/CD). But in many cases, even the most advanced of these technologies will fail to produce the desired results if not implemented and orchestrated properly.

Among the initial questions organizations face when revamping their log practices is what components to log and how to prioritize the log data that is being collected. Loggly’s Sven Drummer notes that in order to maintain the holistic view of events as required in an integrated DevOps environment, you should log at multiple levels – not just the application logs, but the web server and database as well. From there, it depends on the use case, but it is not unheard of to start logging the operating system, hypervisor and even routers, load balancers and other low-end resources. Of course, not everyone will need to see all kinds of logs, but it is also important not to cut anyone out of a particular loop, since this will create silos of knowledge that can be detrimental to smooth-running workflows.

Equally confusing are the types of analyses that promulgate the most effective operations. Erik Dietrich, development trainer at Pluralsight, says nuances exist across the analytics spectrum, from initial collection and aggregation to final interpretation and delivery, and it doesn’t help that the data within log files is often noisy and unstructured. This means you’ll have to define how this data should be parsed and interpreted semantically to best suit your unique use cases, followed by a thorough cleaning and indexing in order to maintain efficient and searchable archives. For the analytics itself, of course, there is a wide range of statistical and predictive modeling approaches to choose from, as well as processes like pattern recognition and machine learning.

The most straightforward way to keep a handle on all of this is to establish an effective log management policy framework, says Rapid7’s Robert Reselman. Not all log events carry equal weight in terms of severity, so you’ll have to define what qualifies as an all-hands emergency and what can wait until the morning. One way to do this is to classify log events depending on what type of response is warranted – anything from simple debugging to warnings that a fatal condition is fast approaching. From there, it is important to communicate the policy across all stakeholders and then to enforce it, preferably through an automated system.

The enterprise will also have to differentiate between the objectives of basic log management versus other log-based systems like security information and event management (SIEM). BMC’s Stephen Watts says that while these two functions may seem similar on the surface, they are in fact quite different. LM concerns itself primarily with collecting, storing and analyzing logs for a variety of purposes, including security but also compliance, operations and optimization. SIEM focuses on security but incorporates multiple processes up and down the stack, including log management, event management, information management and event correlation. Making sure all of these elements work together seamlessly while keeping overlap to a minimum is crucial to a properly functioning DevOps environment.

Log management in a DevOps world will be a delicate balance between minimally effective and overkill. The temptation to restrict it to only the most essential functions will likely be matched by the desire to drill down into everything to squeeze every last bit of inefficiency out of the process.

Neither approach is right, and neither is wrong. But as a rule of thumb, make sure that whatever log data you are collecting is handled properly and analyzed with the appropriate goals in mind.