I wrote in one of my previous blog posts about the debugging process in software development where I also mentioned the concept of logs. Basically, logging is a mechanism that helps you to track the behaviour of the application.
As Thomas cared to explain about logging magic in one of his previous blog posts, almost every vital and complex application must have a logging system, hence most of the programmers are familiar with this paradigm. Also, Garry wrote a blog post about few cool logging tools. It’s not rocket science, but let’s see what’s the big deal with logging.
all about the context
The problem is that even though logging is simple to do, doing it the right way requires practice, understanding and forward thinking. But you know you got it right when you or other people working on the same codebase don’t have to spend countless hours or even days trying to figure out a bug in the production system.
A very important aspect of logging is to ensure that sufficient information about the context is included in the message. Consider the following examples:
2019-07-17 12:17:23 [ERROR] Communication failure blah.blah.ServerException: Unable to connect to server ...
2019-07-17 12:17:23 [INFO] Message processed
Now if you would have to diagnose a faulty application, would you like to see that? This is actually useless. Being concise and descriptive can be tough sometimes, however, keep in mind that each logging statement should contain both data and description. Let’s try to add some context that would possibly lead us to the next step in fixing the issue.
2019-07-17 12:17:23 [ERROR] Failed to communicate with server:server1, error code:401 2019-07-17 12:17:23 [INFO] Message with id:1234 processed
It’s already getting better! Now we have some meaningful data that would be more helpful in tracing the problem.
In summary, a log message without context information is often as useful as no log message at all!
don’t forget the levels
Do you actually think every time you write a log statement and choose which logging level is appropriate for that event? Well, most of the developers don’t. Many programmers don’t pay attention to these levels and they’re just logging everything on the same level, usually INFO or ERROR.
Nowadays, logging frameworks bring a major benefit over the old
System.err. They allow you to selectively print logging statements at various states of the application, making it easier to search the log for entries relating to a certain level. This post has a good set of guidelines on which log level to use with Apache Log4j 2.
On the other hand, there are some mistakes that inexperienced developers would carelessly add to the codebase. For example, you should log an exception only if you handle it. Otherwise, you’ll end up with a massive log file packed with logged errors, even though some of them are even expected.
Also, logging everything is not an option. As any other line of code, it takes time, it affects performance and log files full of unuseful information are hard to analyse.
Did I mention not to log passwords and any credentials or personal information? Well, don’t!
If someone looks at your logs and sees
you should definitely read this blog post. Consequently, a statement with enough context and logged at the right place could become an easy task to trace the issue of the application.
If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.