Trace/Monitor Chain of Microservice Logs in the Same Transaction

Written by mustafaturan | Published 2017/08/18
Tech Story Tags: microservices | best-practices | software-architecture | microservice-architecture | monitoring

TLDRvia the TL;DR App

In microservice architecture, it is possible to get lost with logs, errors, monitors, etc... Having a common logging place is good practice to make the service logs query-able sequentially. In the microservice world each service is responsible for its own exceptions and logs.

Consider pipelined microservices which make calls to other microservices inside/outside the universe. If one call in the chain fails, we can expect that previous calls in the chain might raise errors as well, but how you can trace which request caused this error in the chain?

Demonstration

The quick solution is; if the request does not have a ‘request ID’ information, then put a ‘request ID’ or ‘transaction ID’ information from the beginning of the request and pass the same ‘request ID’ through services. If you are using HTTP to make connection between microservices, you can put the ‘request ID’ as a HTTP header.

When you start logging the chain of requests, you will have the same ‘request ID’ which will be easy to query and analyse which one caused the error.

Lastly, if you are interested in completely traceable systems, also checkout opentracing specs.

Happy monitoring!


Published by HackerNoon on 2017/08/18