If there’s something that lies in the heart of every developer, it’s the desire to properly observe running code and understand what’s happening within their applications. However, inspecting the internal state of an application is not always easy, especially with the complex nature of modern applications. This is why you find a wide range of application performance monitoring and tracking tools in the software market.
Even with these tools, most developers still rely on logging to gain insights into their code. For this reason, you often hear developers put out statements like, ”Adding more logs will help you pinpoint the problem” or “It looks like the API fails intermittently, please take a look at these 50MB logs to determine if there’s a pattern”. Other times you will hear developers say “I see a log indicating an error, but unfortunately, it doesn’t print the reason”.
All this is what we call logging FOMO – when developers fear missing out on some log lines and the debugging data they provide. It’s the anxiety that things may go wrong when there aren’t enough log lines to help you understand issues and fix them. So, how can developers get over this FOMO feeling?
First, it’s my understanding that logging will only provide the desired results if implemented correctly. Secondly, there’s a need to highlight that as technologies evolve, so does the software development space see more innovative and value-rich solutions. I’m talking of a better approach to logging which will be covered towards the end.
Logging: The Black Pit of Software Development
However, creating and maintaining an efficient logging pipeline comes at a cost. And in most cases, these shortcomings come in the way of your development workflow.
These challenges can be understood better by painting a clear picture of common logging problems.
Excessive Logging means a Larger Codebase
Every event or instance of code logged means an additional coding line. As the logs increase, so does the codebase grow. When you reach a point where this logging code is visible, then it becomes clutter and could obscure the actual code behind your application. Additionally, this is also a cause of technical debt.
Logging Affects the Performance of an Application
Every log line you write comes at the expense of your application’s performance, regardless of the logging framework you use. This becomes a problem especially when your code needs to
perform complex computations and place the result in your log file.
As an example, let’s say you have a logline like this.
LOGGER.debug(“Your total cart price is now {}”, cart.getTotalPrice());
In the above statement, the cart. get total price() method is called and executed in all cases. This is fine. But if the method to calculate the total price has complex logic like calling another service to apply a discount, then time will be wasted calculating the time total price of the cart.
You Risk Logging Sensitive Information
More logging might subject you to data privacy regulatory audits. If your logs hold personally-identifiable data or security-sensitive information, then this should be a point of concern.
Here’s an example code snippet where the error message created will contain sensitive information from the database.
Managing Log Levels is no Easy Feat
When someone talks about logging best practices, implementing log levels will is more likely to be on that list. However, getting every developer in your team to agree on the exact meanings of DEBUG, FATAL, INFO, TRACE, ERROR, and any other logging levels you use could be a nightmare.
Poorly Written Logs Provide no Context
Some log statements do not provide sufficient contextual information, which renders the log statements useless. Having logs like the ones below barely makes sense:
1 Transaction failed
OR
1 java.lang.IndexOutOfBoundsException
A logging statement should explicitly describe the context of an error. Understandability is key because other developers might be tasked with maintaining or debugging the software in the future. Here are good examples of understandable log lines that provide sufficient error context for easier diagnostics.
1 Transaction 43956402 failed: cc number checksum is incorrect
OR
1 IndexOutOfBoundsException: index 5 is lesser than collection size 12
One more thing – Always keep in mind that the more loglines you add to your code, the less you’re likely to find. So, no matter how awesome your parsing tools are, do not bury fellow developers in an avalanche of noisy loglines and log data.
No one wants to spend their time mining gigabytes’ worth of log files looking for diagnostic information.
A Better Approach: Setting Up Dynamic Logs
I’ve heard some developers say it’s better to bloat your code with logging statements rather than struggling to diagnose problems when they occur in production. Developers whose logging mechanisms are based on such claims often have a hard time keeping up with their logs.
This does not mean that you should refrain from logging but rather log only when required.
The bottom line here is that logging is not a waste of time, but abusive logging is.
With this in mind, how do you minimize garbage logs and save time your development team spends maintaining them? Using tools that allow you to inspect the state of your applications in both development and production environments without affecting their performance.
Some popular tools include Google Stack Driver ,Splunk and Elastic Stack.
Conclusion
Logging, when implemented correctly, provides helpful data and clues when diagnosing the cause of a problem. With log data, you can dig deeper into the application and understand the state of the system when a problem occurred. However, poor logging practices have significant drawbacks and could be detrimental to your productivity.
Development teams should therefore invest in data-collection and logging solutions that allow you to fetch on-demand data from an application without stopping it or affecting its performance.