What is the meaning and purpose of a logging library? [closed]

Question

I want to understand the basics of a logging library.

1. What exactly is the purpose of a logging library? I understand that a log is basically information about your application process during execution. One way to do it is by writing information in a file directly.
2. What is the purpose of designing a dedicated library such as glog for logging purposes? Is my understanding of logging correct, or do I need to change it? Can someone give a practical example to exhibit the importance of using a logging library?
3. What features should one look at while choosing a logging library?
4. How can logging be effectively employed during implementations?

Answer 1

Logging information during the execution of your application can help you understand what led to a bug or crash, giving you more context than you get from simply a report of a crash, a call stack or even a minidump. This is particularly important when you are getting bug or crash reports from people who are not developers and are not running under a debugger, either end users / customers or non-developers on your team.

My background is in games and logging can be particularly valuable with games for a few reasons. One is that many issues can relate to the specifics of the hardware on a system so logging information like what kind of GPU the user has, which graphics driver version they are running, etc. can be essential to debugging problems that only show up on a specific configuration. Another is that games have a simulation aspect where the state of the game is evolving over time in response to user input combined with simulation of things like physics, AI and the game rules. Understanding what was going on in the run up to a crash or bug helps figure out how to reproduce it and can give valuable clues to the root cause of the issue.

A logging library adds functionality that is useful for logging and goes beyond what is available from a simple printf. This includes things like:

• The ability to control the amount of logging based on factors like debug vs. release builds and runtime settings like a -verbose flag.
• The concept of 'channels' that can be independently enabled, disabled or set to a particular verbosity. For example, to debug a graphics issue you may want the 'graphics' channel set to maximum verbosity while muting the 'network' and 'audio' channels.
• A flexible back end ranging from logging to a local file on disk to logging to a remote database over a network.
• Thread safety so that logging behaves itself when potentially logging simultaneously from multiple different threads.
• Automatic tagging of log entries with a timestamp and any other relevant information (channel, verbosity level, etc.).

As for how to make use of a logging library, that is somewhat dependent on your application, but here's some general suggestions:

• Make good use of channels and verbosity levels if your logging library provides them (and it should). This will help you manage what can become a very large volume of log messages as your application grows.
• If you encounter an unexpected but non-fatal condition and handle it, log some information about it in case it leads to unforeseen problems later on.
• On application startup, log any information that might come in useful for reproducing rare errors later if you receive a bug or crash report from a customer. Err on the side of too much information, you never know what might be useful in advance. This might include things like CPU type, GPU model and driver version, available memory, OS version, available hard drive space, etc.
• Log key state transitions so you can track what state your application was in and how it got there when you are debugging an issue.