Tag Archives: logging

Deployed To Production Is Not Enough

You have developed a new feature. The code has been reviewed, and all the tests pass. You have just deployed this new feature to production. So on to the next task, right? Wrong. Most of the time, you should check that the feature behaves as expected in production. For a simple feature it may be enough to just try it out. But many features are not easily testable. They may be just one part of a complex flow of actions. Or they deal with external data fed into the system.

In such cases, checking if the feature is working means looking at the logs. Yet another reason for checking the logs is that the feature may be working fine most of the time, but given unanticipated data, it fails. Usually when I deploy something new to production, I follow up by looking at the logs. Often I find surprising behavior or unexpected data.

Continue reading

Good Logging

To check if a program is doing what it should, you can inspect the output from a given input. But as the system grows, you also need logging to help you understand what is happening. Good log messages are crucial when troubleshooting problems. However, many developers don’t log enough information in the right places.

Continue reading

Session-based Logging

To trouble-shoot software, logging of some kind is essential. But for most systems, it is simply not possible to log everything that happens. Many systems and logging frameworks let you limit the amount of data by giving a logging level (e.g. error, warning, info, debug) and by specifying where in the code logging should be done. An alternative way of limiting the data is to use session-based logging. You then get all data pertaining to a specific session, but nothing for any of the other sessions. Continue reading

Finding Bugs: Debugger versus Logging

One common reaction to my post on writing debuggable code was: you don’t need logging, just use a debugger. While there are cases where a debugger is the best option, there are many reasons why having proper logging in place is superior to using a debugger for trouble shooting. Continue reading

Automatically Include Revision in Log Statement

When there is a problem with your software, the first thing you usually ask for is a log showing what happened (provided you write debuggable code), and the version of the software that was running. But it is easy to have the revision of the software automatically added to the log. Continue reading

Great Programmers Write Debuggable Code

All programs need some form of logging built in to them, so we can observe what it is doing. This is especially important when things go wrong. One of the differences between a great programmer and a bad programmer is that a great programmer adds logging and tools that make it easy to debug the program when things fail.

When the program works as expected, there is often no difference in the quality of the logging. However, as soon as the program fails, or you get the wrong result, you can almost immediately tell the good programmers from the bad. Continue reading