Managing and analyzing logs can be complicated and time-consuming — but there are a few easy practices that you can follow to make logging less painful and more productive. Let’s examine a few.
Logging is to technology what health history is to doctors: It’s a crucial diagnostic tool. But, it isn’t enough to create logs. We need to be able to extract useful information from the data easily.
Centralized Logging and Log Aggregation
The first thing we need to do is make sure all our log data flows from their sources into one shared pool.
Centralizing data saves us from digging through multiple individual servers when we’re looking for a piece of information. When we centralize our data, we’re also improving the quality of the information we derive. For instance, the occurrence of an error message from users may correspond with the depletion of some server resources.
A centralized logging solution that provides data visualization, like Mezmo, formerly known as LogDNA, presents us with boards, graphs, and screens that we can use to make these deductions more easily.
Use Logging Proactively
We shouldn’t use logging exclusively for troubleshooting. We should make a habit of analyzing our logs even when things are going well. Knowing what works well also influences our future product development efforts.
Many dev teams let logs pile up only refer to them when there’s an issue they need to resolve. Just like paying attention to your health only when you’re ill means that you’re neglecting yourself to a degree only looking at logs when problems arise means that you’re missing an opportunity to identify and mitigate errors before your users notice.
Write Descriptive Log Messages
Imagine you’re trying to locate a building in an unfamiliar city without explicit instructions. The person giving you the directions told you to head east, so that’s all you have in terms of help. With no street names or lot numbers to refer to and no map to follow, you’re left wandering around searching. Minimal directional information usually isn’t enough to get you to your destination.
Logging also applies this same logic, as without helpful descriptions that tell us what happened, where it happened, when it happened, and who or what it affected, debugging a problem could still be a daunting task. Creating detailed, descriptive logs makes pinpointing and resolving issues easier.
Use the Right Logging Level for Every Log Entry
If there’s anything as bad as trying to locate a building without an exact address, it’s trying to find it with the wrong address.
Logging fatal application errors as “info” doesn’t do our debugging or log analysis efforts any good. For example, if you log “Login failed due to invalid password” as ERROR, you might mislead yourself into thinking that a functional system has had an error.
Don’t Reinvent the Wheel
Unless you’re using an antiquated programming language, there’s no reason why you shouldn’t take advantage of existing solutions. There’s RSpec and Minitest in Ruby, Log4j in Java, Apache log4net, and Serilog for .NET.
These tools output your logs in a machine-readable format conducive to log aggregation. Some, like Serilog, even support sending logs directly to centralized logging tools like Mezmo!
Use Unique Identifiers
While debugging or analyzing log data, it’s helpful to track the activity sessions of your users. Using unique identifiers, we can trace the actions taken by a user within a specified timeframe.
Unique identifiers can also come in handy with customer support. When you can query your log data for actions taken by an individual user, you are better able to understand the cause of their issues and provide help.
Implement Strategic End-to-End Logging
When it comes to logging, more is more. It would be great to log everything, but storage is cost-intensive. As a result, we often have to decide what to log and what not to log. Our goal is to have a comprehensive view of how our application performs and how end-users use it.
We want to go beyond security logs. Monitoring system components, application layers, communication channels, database queries, and network speed helps us better assess the efficiency of our infrastructures and improve user experience.
Conclusion
What’s worse than not logging? Not efficiently using log data. Your thoroughness should pay off, not lead to even bigger headaches. Why put in the effort that effective logging demands only to fall into a dilemma when we want to analyze our log data? To get the most out of your logs, pair proper logging with the right logging tools.
