Many posts about logging seem to include the technical advice
> Attach a request/trace id. This goes along with distributed tracing, and helps you filter effectively. Filtering down by log level won't give you context, but correlating by request id will give you all the logs for a given event!
without mentioning the organisational part
*Any personal information collected, including through trace, can be a liability. Ensure you have a log retention policy, don't use trace, or don't collect anything personal information *
Being a hacker's not just about code. It's about working a system.
>Let's use WARNING as an example. Suppose you should have a WARNING log level, and some of those show up in your logs. What should you do when you see them? There are three choices:
- If the information isn't useful at all, in any scenario, delete them entirely!
- If it helps you make sense of other logs, potentially related to an error, then these are just info logs for debugging! They should be INFO level to reflect that.
- And if it is an error you need to fix, well, it's not a warning now is it? Make that an ERROR log.
Nope. The there are logs for debugging that are just verbose stuff so you can track something.
They're neither regular "info" (high level stuff to know what the system is doing, perf stats after an operation, etc) that you want to always see, nor indicating an error.
Those can be "debug", so that you can filter them out and still see ERROR you need to fix.
> Attach a request/trace id. This goes along with distributed tracing, and helps you filter effectively. Filtering down by log level won't give you context, but correlating by request id will give you all the logs for a given event!
without mentioning the organisational part
*Any personal information collected, including through trace, can be a liability. Ensure you have a log retention policy, don't use trace, or don't collect anything personal information *
Being a hacker's not just about code. It's about working a system.