Mastering Spring Cloud by Packt Publishing

Author:Packt Publishing [Packt Publishing]
Language: eng
Format: epub
Publisher: Packt Publishing
Published: 2018-04-26T08:56:15+00:00

Best logging practices for microservices

One of the most important best practices for dealing with logging is to trace all the incoming requests and outgoing responses. Maybe it seems obvious to you, but I have seen a couple of applications that did not comply with that requirement. If you meet this demand, there is one consequence that occurs with microservices-based architecture. The overall number of logs in your system increases compared to monolithic applications, where there is no messaging. This, in turn, requires us to pay even more attention to logging than before. We should do our best to generate as little information as possible, even though this information can tell us much about the situation. How do we achieve this? First of all, it is good to have the same log message format across all the microservices. For example, let's consider how to print variables in the application logs. I suggest you use the JSON notation in view of the fact that, usually, messages exchanged between microservices are formatted with JSON. This format has a very straightforward standard, which makes your logs easily readable and parseable, as shown in the following code fragment:

17:11:53.712 INFO Order received: {"id":1,"customerId":5,"productId":10}

The preceding format is much easier to analyze than something like the following:

17:11:53.712 INFO Order received with id 1, customerId 5 and productId 10.

But generally, the most important thing here is standardization. No matter which format you choose, it is crucial to use it everywhere. You should also be careful to ensure that your logs are meaningful. Try to avoid sentences that do not contain any information. For example, from the following format, it is not clear which order is being processed:

17:11:53.712 INFO Processing order

However, if you really want this kind of log entry format, try to assign it to different log levels. It is really a bad practice to log everything with the same level of INFO. Some kinds of information are more important than others, so the one difficulty here is to decide what level the log entry should be logged at. Here are some suggestions:

TRACE: This is for very detailed information, intended only for development. You might keep it for a short period of time, just after deployment to a production environment, but treat it as a temporary file.

DEBUG: At this level, log anything that happens in the program. This is mostly used for debugging or troubleshooting by developers. The distinction between DEBUG and TRACE is probably the most difficult.

INFO: At this level, you should log the most important information during the operation. These messages have to be easily understandable, not just for developers, but also for administrators or advanced users, to let them quickly find out what the application is doing.

WARN: At this level, log all events that could potentially become errors. Such a process may be continued, but you should take extra caution with it.

ERROR: Usually, you print exceptions at this level. The important thing here is not to throw exceptions everywhere if, for example, only one business logic execution has not succeeded.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.