The Need for Visibility
In a microservices architecture, there are a number of small microservices talking to each other:
In the above example, let’s assume there is a problem with Microservice5, due to which Microservice1 throws an error.
How does a developer debug the problem?
They would like to know the details of what’s happening in every microservice from Microservice1 through Microservice5. From such a trace, it should be possible to identify that something went wrong at Microservice5.
The more you break things down into smaller microservices, the more visibility you need into what’s going on in the background. Otherwise, a lot of time and effort needs to be spent in debugging problems.
One of the popular ways to improve visibility is by using centralized logging.
Centralized Logging Using Log Streams
Using Log Streams is one way to implement centralized logging. The common way to implement it is to stream microservice logs to a common queue. Distributed logging server listens to the queue and acts as log store. It provides search capabilities to search the trace.
Some of the popular implementations include
- the ELK stack (Elastic Search, Logstash and Kibana) for Centralized Logging.
- Zipkin, Open Tracing API, and Zaeger for Distributed Tracing.
In this article, we had a look at centralized logging. We saw that there is a need for high visibility in microservices architecture. Centralized logging provides visibility for better debugging of problems. Using log streams is one way of implementing centralized logging.