Logging best practices

Logging best practices.md

Logging best practices

When generate a log message

• 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

How to choose the log level

1. Be generous with your logging but be strict with your logging levels

2. the "Error" level should be reserved for events that you intend to act on (events required support intervention)

• This is the most important point. Our today (big) problem: we have too much logs "Error" (critical error and meaningless errors are mixed together) => Support team are unable to monitor them all so the error logs are usually ignored => nobody notices when real problem happens.
• Errors such as "Payment / Wallet Not Found", "Input validation error" / "Business error returned by external service" etc.. are no need for Support intervention. They should be on Info or Warning level.

3. 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.

4. In almost all other cases the level of your logs level should be "Debug".

5. If you are indecisive between "Debug" and "Information" => Use "Debug". If you are indecisive between "Debug" and "Trace" => Use "Trace"

• if we are indecisive it means that the event might important / interesting (but not important or interesting enough)
• It is easy to temporarily activate a lower logs level (Trace, Debug) on Production.