If you’ve spent any amount of time in the software industry, you’ve probably bumped up against logging. Maybe you first encountered it as a way to debug your program as you worked, printing “you are here” messages. Go much beyond that, especially in 2017, and your logging efforts likely graduate to the use of a logging framework.
What Is a Logging Framework? Let’s Get Precise.
So what marks this distinction? When do you go from newbie printing out “got into the Calculate() method” to user of a logging framework? To understand that, let’s define logging framework.
A logging framework is a utility specifically designed to standardize the process of logging in your application. This can come in the form of a third party tool, such as log4j or its .NET cousin, log4net. But a lot of organizations also roll their own.
You have to go beyond just standardizing, however, to qualify as a framework. After all, you could simply “standardize” that logging meant invoking the file system API to write to a file called log.txt. A logging framework has to standardize the solution by taking it care of the logging for you, exposing a standard API.
To get more specific, we can conceive of a logging framework encapsulating three main concerns: recording, formatting, and appending. When you want to capture runtime information about your application, you start by signaling what to record. Then, you determine how to format that information. And, finally, you append it to something. Classically, this is a file, but you can also append to RDBMS tables, document databases, or really anywhere capable of receiving data.
If you have a piece of code dedicated to solving these problems, you have yourself a logging framework.
Should You Use an Existing Logging Framework or Build Your Own?
Now that we have precision around the definition, let’s examine your options for making use of a logging framework. Notice that I frame the question in terms of which one you should pick, rather than whether or not you should use one. I do that because production applications should most definitely make use of logging frameworks. Without them, you’re flying blind about what your application does in the wild.
The question then becomes whether you should use an existing one or write your own. Use an existing one — full stop. It’s 2017, and this is a well solved problem in every tech stack. You shouldn’t write a logging framework any more than you should write your own source control tool or build a bug tracker. Others have built these, and you can have them cheaply or freely. Stick with solving problems in your own domain, rather than reinventing wheels.
So you need a logging framework, and you should use an existing one. The question then becomes “which one?” Which logging framework should you use? I won’t answer that outright, since it will depend on your stack and your needs. Instead, I’ll offer guidance for how to choose.