Chapter 7. Logging
As developers, we have to communicate on many levels. We spend hours in meetings, listening and talking. We work with end users, trying to understand their needs. We write code, which communicates our intentions to a machine and documents our thinking for future generations of developers. We write proposals and memos requesting and justifying resources, reporting our status, and suggesting new approaches. And we work daily within our teams to advocate our ideas, modify existing practices, and suggest new ones. A large part of our day is spent communicating, so we need to do it well.
David Thomas and Andrew Hunt, The Pragmatic Programmer (Addison-Wesley)
It is well understood that communication is fundamental to success. We can instill the value of communication into our code by infusing it with the power of logging. The story of a system in production is not written by the developer, it’s written by the system—and the only way to hear that story is with logs.
Computing environments are becoming increasingly ephemeral, and interacting with an instance of your code in production may be impractical, impossible, or even illegal. Bugs in production will be an issue inside either your code or the environment it operates in. Logging can help you quickly understand how an undesired result was achieved by allowing you to manually step through the code without a debugger. It can also help increase confidence that an issue does not directly result from your code and ...