Mustafa Turan
Aug 29, 2017 · 1 min read

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!

HackerNoon.com

how hackers start their afternoons.

Mustafa Turan

Written by

Go, Elixir, Ruby, Software Architecture, Microservices

HackerNoon.com

how hackers start their afternoons.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade