This is very interesting. I've wanted something like this for a while. When debugging SSR in Next.js, I have a script to spin up mitmproxy and configure Next.js to send requests through it. I also have a script that can dump the logs of all containers while sending some request, but it's such a hack I hardly ever use it. I've toyed with the idea of scaling this up to include more services in the stack with some tcpdump or eBPF magic, but it gets complicated really fast.<p>At work we have about two dozen images which spawn about 60+ containers (including replicas) in prod, and 30 in dev. The services run the gamut in terms of role and language, including everything from stock haproxy images to esoteric Python or JS images. In development we use docker-compose and in prod we use Nomad.<p>I'm not familiar with OpenTelemetry. Does this require adding some instrumentation to every downstream service, or do you/OpenTelemetry sidestep that somehow (eg with eBPF on the shared network interfaces)?<p>How easy would it be to add this into our e2e tests within our JS stack? For example, say we want to make assertions that Next.js SSR results in an HTTP request through haproxy (standard), then web-openresty (customized), then auth-service (Python). Can we write the tests in JS, only worrying about the Next.js service, without touching the other services, or do we need to add instrumentation to them as well? Ideally, we could add the instrumentation once in the development stack for docker-compose, and once in "prod" (temporary staging environments where we run e2e tests) for Nomad. (And ideally "adding it once" wouldn't mean adding two dozen sidecar services, but rather once per network interface, eg task groups in Nomad and Docker networks in docker-compose.)<p>Also, I see you have a bunch of "coming soon" services - is this just about writing the assertion adapters for their protocols, or do they require some low level adaptation to even work at all?