Introduction

Logging is really important.

Logging is a great way to track important events in the system or help you troubleshoot issues. Every log message you print should be an answer to the question how it will help you understand the daily operations of the system better. When an application has an online problem, if adequate logs are not printed in advance, there is insufficient information to determine the source of the problem, resulting in several times the time spent troubleshooting and fixing the online problem.

This is easier said than done.

It’s hard to know up front what your logging needs are. Most of the time you only find out after an issue has occurred. Don’t be afraid to adjust your logging as you start using your system.

Don’t do too much. On the other hand, too much logging will render your log files unreadable and therefore unusable. You have to find a balance between those two practices.

When should we print logs?

Usually you need to record logs in these places/occasions:

  1. When interact with external systems : log the request data and response data of network requests. Print the request URL, HTTP method, request body, response status code, response body, etc. in the log as needed. This information can help you analyze the content of requests and responses and locate the exact location of the problem. These logs help you a lot when you validate if the error is in external systems or in your own application.
  2. When a user logs in or logs out: If your application involves user login and session management, record user identification information (e.g., user ID) and session information (e.g., session ID, expiration time, etc.). This information can help you track actions and issues related to a specific user or session. However, do not print users' private information.
  3. When important business operations occur: Log critical business operations, such as user orders, payments, and shipments. The logs of these operations can help you track business processes and locate the reasons for operation exceptions or failures.
  4. When an error or exception occurs: Log detailed information about exceptions and errors, including exception types, error messages, stack traces, and so on. This information can help you locate where and why the problem occurred and perform problem troubleshooting and repair. This usually happens when you call a third-party library or code written by other colleagues. At this point, you don't know its internal workings or what exceptions will occur, so you need to catch the exceptions.
  5. When validate user inputs: it's helpful to log any validation errors or invalid inputs. This information can assist in identifying patterns or common mistakes made by users.

When handling exceptions, you should try to:

  1. Print logs in every where exceptions probably occur. When you predict that this is a frequently occurring exception, give a clear error message and error handling advice, and record it in the log. For unknown exceptions, be sure to print out the entire stack trace.
  2. Don't swallow any exceptions!!! If an exception occurs and you swallow it instead of sending it back to the client or outputting it to the logs, that's a very, very big problem. Having your application deployed to a formal environment but not running as expected with no one knowing why. This makes the debugging process very difficult.

What information should be printed?

You should realize that we run a busy system. A lot of things happen at the same time and all these things may be printing log messages. It is very difficult to separate the background noise from the message you’re looking for, so try to be as explicit as possible