Logging

Knowing how and what to log is one of the hardest task a software engineer needs to solve ✍ . Logs enable you to troubleshoot issues with your code and services. With logs that detail what your service is doing — and why it is doing it — at any given point and time, you can remove a great deal of guesswork and manual effort from the troubleshooting process.

How to log ?
1. While troubleshooting, add logs that would have helped you solve the issue and always include remediation advice in them (i.e. specifically addresses possible actions rather than simply information).

2. Use the appropriate logging level
2.1 FATAL — Use the it for events that indicate a critical service failure.
2.2 ERROR — Use the it for events that indicate a disruption in a request or the ability to service a request.
2.3 WARN — Use it for events that may indicate a non-critical service error. Resumable errors, or minor breaches in request expectations fall into this category.
2.4 INFO — Use it for service life-cycle events and other crucial related information. You should be able to tail the log and not be overwhelmed.
2.5 DEBUG — It should be where you put all of the verbose messages that you only want to encounter when debugging a problem.
2.6 TRACE — It is the most verbose — where you log every input and output from the calls. Use it to allow for deep probing of the server behavior when necessary.

3. Don’t spam — Log messages should never be redundant, and they should not speak to uninteresting defaults like attempting to read from an empty queue every ten seconds. In this case, it would be more appropriate to log a single event when the queue is emptied.
The purpose of this is to maintain readability of the logs, as well to reduce log sizes.

4. Add context — Add all things you need to know to understand the context in which the log was emitted. Examples of relevant state include:
4.1 Context identifiers like a request ID
4.2 Lifecycle identifiers like epochs
4.3 Function inputs and outputs
4.4 Condition parameters as well as the state that sourced them

5.Avoid expensive computation — Logs should never get in the way of the meat of the runtime. They certainly should not affect performance. Make sure logging is only enabled when the appropriate log level is also enabled.