Hacker News Reader

Comment by zimpenfish | Hacker News Reader

> To follow and debug requests for example. How do you do that in a good way?

I'm assuming you mean "requests that involve multiple microservices"? And the answer there is simple for following - the first one involved tags the request and passes that tag on to all the subrequests. Easy to correlate across your logs. Debugging can be done in a similar way with a header saying "dump debug for this request" that's passed between services.

View on HN

Well yes, but when I use a debugger for example that would require me to first debug application 1, then 2, then 3 in order to fully go through the cycle. This seems quite... time consuming.

You should not need to do this with microservices. Part of creating them is implementing well-defined API's, which create concrete borders between your services. It is extremely easy to capture/log all traffic passing between your services, which you should be able to use to determine which service is misbehaving, and them aim your debugger there. If you cannot do this, then your API's are not doing what they are supposed to be doing.

> It is extremely easy to capture/log all traffic passing between your services

But you would have to create a development environment running the complete micro-services environment on a single machine. Or setup distributed/cloud logging & debug against production. Which is generally easier to do if you use a monolith. Admittedly tools like docker compose and vagrant can help with this.

If you rely on a stepping debugger, you're fscked anyway when you step outside of desktop applications and websites. Logs and trace dumps (tcpdump/strace like) are what works almost everywhere.

"correlation ID" is the common term. Has value outside of microservices as well. Monoliths don't always have a single log file.

Excellent point - and that's where I've always used it to date, as well (monoliths).

Reply on news.ycombinator.com