trace-anywhere
Think PingPlotter Pro, but open-source and running on the server instead of the desktop. I built a Docker-native continuous traceroute tool with a real-time web UI, so an intermittent routing problem shows up in a persistent history instead of vanishing between two one-off checks.
Overview
mtr and traceroute answer “what does the path look like right now.” Neither answers “was hop six degraded at 3am last Tuesday,” because neither keeps a history. Commercial tools like PingPlotter Pro do keep a history, but they are built to run from a desktop, not unattended on a headless box in a data center. TraceAnywhere fills that specific gap: deploy it anywhere Docker runs, point a browser at it, and get persistent, visual traceroute data recorded from the server’s own vantage point, so a routing issue that only shows up for ten minutes a day gets caught instead of missed.
It runs continuous traces from the host it is deployed on, storing every probe result in a local database and streaming it to a web UI with per-hop latency charts, jitter bands, and packet-loss indicators, plus a summary chart and sparkline trend lines for quick triage. Built as part of ongoing network infrastructure work managing multi-site server deployments across data centers in the US and Europe, where “is this actually a routing problem or did I imagine it” comes up often enough to be worth answering properly.
Technical
FastAPI (Python 3.12) backend, talking to SQLite in WAL mode over aiosqlite for concurrent read and write, with schema managed through numbered SQL migration files. The frontend is a vanilla JavaScript single-page app with Chart.js for the charts; no build step, no framework, no node_modules, because a page with a hop table and two charts does not need 200KB of framework to justify itself. Multiple traces can run concurrently in separate browser tabs, each with independent state, and results stream over WebSocket rather than polling.
The probe engine wraps mtr --report --report-wide --report-cycles 1 --no-dns and parses its text report output with regex extraction, since the mtr-tiny package on Debian and Ubuntu produces text rather than JSON. That engine sits behind a ProbeEngine interface with dependency injection, so a fake engine stands in during tests and the real mtr integration is swappable if the probe mechanism ever needs to change.
Security is scoped narrowly on purpose. ICMP requires CAP_NET_RAW, and rather than run the whole container as root to get it, the capability is granted only to the mtr-packet binary via setcap; the Python process itself runs as an unprivileged user. Everything ships as a single container over Docker Compose, listening on port 7890 inside and out.
Why You Should Care
Intermittent network problems are exactly the class of bug that ad hoc diagnostics are bad at catching, because by the time you notice the symptom and reach for mtr, the window has usually already closed. Persistent, continuous history turns “did that actually happen” into a question with a chart attached instead of a guess. Running it self-hosted matters for the same reason it matters for a consultancy managing infrastructure across multiple data centers: the diagnostic data about your network should not have to leave your network to be useful.
The scope is deliberately narrow: one probe engine, one database, one page. That restraint is why it stays legible, non-root by default, and easy to reason about instead of turning into a monitoring platform nobody fully understands.
Status
Phase 1 MVP shipped: continuous traceroute, real-time WebSocket streaming, per-hop charts, trace history, JSON export, single-container deployment. Later phases (environment-based configuration, retention policies, target allowlists, Prometheus metrics, CI/CD) are scoped in the repo’s roadmap but not yet built. MIT licensed.