Hey HN, we built Subtrace (<a href="https://subtrace.dev">https://subtrace.dev</a>) to let you see all incoming and outgoing requests in your backend server—like Wireshark, but for Docker containers. It comes with a Chrome DevTools-like interface.
Check out this video: <a href="https://www.youtube.com/watch?v=OsGa6ZwVxdA" rel="nofollow">https://www.youtube.com/watch?v=OsGa6ZwVxdA</a>, and see our docs for examples:
<a href="https://docs.subtrace.dev">https://docs.subtrace.dev</a>.<p>Subtrace lets you see every request with full payload, headers, status code, and latency details. Tools like Sentry and OpenTelemetry often leave out these crucial details, making prod debugging slow and annoying. Most of the time, all I want to see are the headers and JSON payload of real backend requests, but it's impossible to do that in today's tools without excessive logging, which just makes everything slower and more annoying.<p>Subtrace shows you every backend request flowing through your system. You can use simple filters to search for the requests you care about and inspect their details.<p>Internally, Subtrace intercepts all network-related Linux syscalls using Seccomp BPF so that it can act as a proxy for all incoming and outgoing TCP connections. It then parses HTTP requests out of the proxied TCP stream and sends them to the browser over WebSocket. The Chrome DevTools Network tab is already ubiquitous for viewing HTTP requests in the frontend, so we repurposed it to work in the browser like any other app (we were surprised that it's just a bunch of TypeScript).<p>Setup is just one command for any Linux program written in any language.<p>You can use Subtrace by adding a `subtrace run` prefix to your backend server startup command. No signup required. Try for yourself: <a href="https://docs.subtrace.dev">https://docs.subtrace.dev</a>
Looks great! Reading through the docs it seems the subtrace process sends all data to your server. I'm reluctant to do that on a production environment, where API keys and personal data are being handled.<p>Is there any way to run it completely self hosted? If not, are there plans? And how will you monitize self hosted options (if it's possible)?
Wireshark seems a bit misleading. More like a "network inspector" if one leans towards the browser's network tab in the inspector?<p>But it really looks useful and I'll definitely play with it to see if I put it into my toolbox.
Have not played around with it, but, curious, how does debugging on production work for a specific request/session? Can I filter by some sort if request trace id or something?
My most painful debugging scenarios with Docker networking (for me) has always been dealing with non-TCP traffic. But still, this seems useful. One thing I don't understand is why this requires an account token? Does this require a network connection to subtrace? It seems like this should all be running locally, and these kinds of connection details are _exactly_ the kind I would not want to leave the host, let alone go to a third party.
Congrats on the seccomp-based interception, that's a really neat way to solve this problem! We did some BPF_PROG_TYPE_CGROUP_SOCK eBPF shenanigans in mitmproxy for redirection, but that doesn't work with containers at all. Cool to see that intercepting all relevant syscalls works that well.
You can use mitmproxy and mitmweb to achieve the same. It is in Docker hub and you can pass environment variables to your other containers to make it work.<p>The TLS certificate setup is more tricky but that is always going to be a pain.<p>Burp Proxy is another great tool that is even more powerful but harder to set up.
So "tcpdump as a service"? Why wouldn't I just generate my own pcap and stick it into wireshark or whatever I like for looking at packet captures? I'm having trouble seeing the value prop here.
stratoshark, the docker container part of wireshark, may be a better match for that description.<p>I'd probably use a postman related pitch instead. This is much closer to that and looks like a nice complement to that workflow
We use <a href="https://treblle.com/" rel="nofollow">https://treblle.com/</a> at work for this in production. Very handy to see what requests are being made and by whom.