> correlation_id … microservices We actually did something slightly different: the correlation ID is generated at the start of a request, where it enters "our

> correlation_id … microservices We actually did something slightly different: the correlation ID is generated at the start of a request, where it enters "our stuff" as a whole. But downstream "microservice" style requests get a different correlation ID, but with the original as a prefix. So if you have lots of microservice calls being made this means you can select any subtree with some prefix. The original correlation ID is the entire tree, but you might have, b8a0b848-92e6-49e7-bde2-283e165b02e4 # the original request b8a0b848-92e6-49e7-bde2-283e165b02e4/authz # request to authz service b8a0b848-92e6-49e7-bde2-283e165b02e4/foo-db/0 # first subrequest to foo-db b8a0b848-92e6-49e7-bde2-283e165b02e4/foo-db/1 # second subrequest to foo-db b8a0b848-92e6-49e7-bde2-283e165b02e4/foo-db/2 # third subrequest to foo-db b8a0b848-92e6-49e7-bde2-283e165b02e4/bar-db/0 # first subrequest to bar-db etc. So you can pull just the original request with "= 'b8a0b848-92e6-49e7-bde2-283e165b02e4'", a whole subsystem with something like "starts_with 'b8a0b848-92e6-49e7-bde2-283e165b02e4/foo-db/'", so on. Very convenient. (Our graphs weren't even that deep; we really just have "backends for your frontends" and "backends" and that was mostly it, so it was mostly to correlate between the BE and the BE-for-FE.) You need structured logs first, so if you've not got that, start with that first. There's this thing called "OpenTracing", which I hear is a sort-of standardization of this, but I've not had time to investigate it.