01 What the map shows #
Nobody draws this map. It is derived from the traces themselves: whenever a span in service A is the parent of a span in service B, ZenPlus records an edge A → B. The map is therefore always a picture of what your system actually did in the selected window, not what an architecture diagram says it should do.
- Node colour
- Service health over the window — the same thresholds as the Services page.
- Node size
- Throughput. The biggest circles are carrying the most inbound traffic.
- Edge width
- Call volume, on a logarithmic scale so a very busy edge stays legible next to a quiet one.
- Edge colour
- Error rate of the calls: grey below 1%, amber at 1%, red at 5%.
- Edge tooltip
- Call count, error rate, and average latency for that dependency.
The graph rollup stores a sum and a count per edge, which can produce a mean but cannot reconstruct a percentile. Percentile latency is a property of a service (where a t-digest sketch is kept) and is shown on the node. If an edge's average looks fine but users are unhappy, open the service and read its p95.
02 How edges are built #
A background job aggregates parent/child span pairs into a dependency rollup once every closed five-minute bucket. The map reads that rollup, and joins raw spans only for the few minutes not yet aggregated.
This matters for two reasons. First, cost: the map used to self-join the raw span table across the whole selected range on every page load, which is the first query to fall over at real volume. Second, correctness under sampling: aggregating continuously means edges are recorded from the full stream rather than from whatever traces happened to be retained.
Raw traces expire after 7 days, but the dependency rollup is kept for 90. You can look at last quarter's topology and see which dependencies are new.
03 Reading it during an incident #
- Follow red upstream. A red edge into a red node usually means the downstream service is the cause. A red edge into a healthy node is more interesting: the callee is fine, so the failure is in how it is being called — timeouts, bad payloads, auth.
- Check who depends on the broken thing. Every inbound edge is a blast-radius statement. This is the fastest honest answer to “what does this affect?”
- Click any node to open that service, carrying the same time range.
- Drag and zoom. The layout is force-directed; drag nodes apart in a dense graph, and hover to dim everything except a node's own neighbourhood.
04 Why a service might be missing #
| Symptom | Cause | Fix |
|---|---|---|
| Service missing entirely | It reported no spans in the window | Widen the range; check it is still reporting on the Services page |
| Service present, no edges | Trace context is not propagating across the call | Ensure both sides use compatible propagators (W3C traceparent by default) and that the client call is instrumented |
| Node grey (“no inbound RED”) | It only ever appears as a caller or callee, with no SERVER/CONSUMER spans of its own | Instrument its inbound handler — see Services |
| Edge missing one direction | Only one side is instrumented | An edge needs a parent span and a child span; a call into an uninstrumented service cannot be seen |
| Databases not shown | Database calls are spans within a service, not services | Open a trace waterfall to see database spans |
The map exists only because a parent span id crosses the wire. If a service strips headers, uses a proxy that drops traceparent, or hops through a queue without propagating context, the trace fragments and the edge disappears — even though both services are perfectly instrumented on their own.