How to get application logging right
The advice here is unglamorous, which is probably why it gets skipped. The short answer to application logging is that it is mostly a sequence of small decisions, not one big one.
The question is rarely whether something can be built, but what it costs to keep running afterwards. If two people in the business would answer this differently, that gap is the actual problem.
Why this earns attention
Logs are what you have when something breaks at 2am. This is the sort of thing that compounds, quietly, in both directions. If it only works because one person remembers to do something, it does not work yet.
The steps
- Establish what you have today before changing anything
- Structure them so they can be searched, not just read
- Never log passwords, tokens, or full card numbers
- Write down the decision so the next person does not re-litigate it
Never log passwords, tokens, or full card numbers. This is the sort of thing that compounds, quietly, in both directions. It rarely shows up as a line item, which is exactly why it slips.
A reasonable first step
In practice
Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about application logging before you move on:
- Someone can say what the current setup is without going to look
- Structure them so they can be searched, not just read — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you want a second opinion on how yours is set up, ask.