Logging

Logs are a way for the program or process to communicate to the external world what it is doing. Most software products will generate logs. Logs generated can either be stored in the same machine or node where the software producing it resides, or can be exported or redirected elsewhere. Each choice has its implications. Large software teams will have multiple different programmers who code. Just like the coding style, there is a method called the logging style. Various teams must work together to ensure that all their programmers log in a uniform logging style. Logging is an art form, and it takes a lot of time and experience to decide what and how to log, but it is a woefully undertaught subject. Let’s discuss what to log (and what not to log) and how logs will help us.

What to log?

As mentioned previously, logs are a self-commentary of what a program or process is doing. The programmer who writes or owns the code will also note what it logs. From the programmer’s perspective, they will likely peruse the logs when something goes wrong, so it is a natural choice to log exceptions, errors, etc. But it is also essential to log critical events and milestones that occurred correctly. In some cases, these log stamps might prove helpful to rule out anything defective with the workflow involved. Programmers use logs the most, but others can rely on logs to understand what is happening, like triaging a bug or a support or QA engineer who might not know the code as much as the programmer. Logs must be written and organized to serve everyone as much as possible, which is a tough ask. Therefore, logging must be strategic and evolve with the product. We can consider the following general guidelines when it comes to what each log stamp must contain:

• When? A timestamp would help establish a timeline of the sequence of events.

• What? All critical events or milestones of a process, e.g., when a software service has finished initializing and is ready to serve and when it has moved to not serving, etc.