- Major branching points in your code
- When errors or unexpected values are encountered
- Any IO operations: calling database / stored proc or make http request
- Significant domain events
- Request failures and retries
- Beginning and end of time-consuming operations
Less is more, 5 log levels (Debug, Info, Warning, Error, Fatal) is enough for most applications.
-
Be generous with your logging but be strict with your logging levels
-
the "Fatal" level should be reserved for events that you intend to act on (events required support intervention)
- Support team monitor only the Fatal error logs. We don't care about "Business errors" such as "Product Not Found", "Input validation error" / "Business error returned by external service" etc..
- The "Information" level should be reserved for events that would be needed in production (to monitor the state or the correctness of the application).
- Application start / end, Application config changes
- Start / End events of any Time-consuming or Important operations. For cheap / unimportant operations such as "GetTransaction", "GetWalletDetails"... which are called 1000 times every sec, we don't need to logs them on production => use “Debug” level in this case.
-
In almost all other cases the level of your logs level should be "Debug".
-
If you are indecisive between "Debug" and "Information" => Use "Debug". If you are indecisive between "Debug".
- if we are indecisive it means that the event might important / interesting (but not important or interesting enough)
- It is often easy to temporarily activate a lower logs level (Trace, Debug) on Production.
- Justify log levels for each release: After deploying to Production, we recognize that some logs is more important, others is less important than we think => adapt them.