Orbtrace

Service map

A live graph of who calls whom across your fleet. Read this page to understand what edge thickness, colour, and node shape mean — and how to use the map to find a bad dependency in seconds.

The service map is a force-directed graph. Each circle is one service; each arrow is "service A called service B at least once in the current time window". Reading the map well is a learned skill — this page is the entire skill.

What's drawn

On screen
  • Node (circle)One service. Diameter scales with requests-per-second handled. The biggest circles are your busiest services.
  • Node ring colourSame health colour code as elsewhere — emerald (healthy) / amber (degraded) / rose (page-worthy) / slate (silent).
  • Node iconA small glyph that hints at what kind of service it is — derived from service.type attribute or guessed: a database barrel for stores, a queue glyph for brokers, an antenna for HTTP services, a worker hat for consumers.
  • Edge (arrow)A traffic flow from caller to callee. Direction = who initiated.
  • Edge thicknessProportional to the rate of calls on that edge (calls/second). Hair-thin = trickle; chunky = mainline. The scale is logarithmic so a small busy edge doesn't drown the map.
  • Edge colourEmerald if 5xx-rate on this edge is below 0.1%. Amber 0.1–1%. Rose above 1%. Edges with no traffic in the window are dotted slate.
  • Edge animationFlowing dots run along the edge in the direction of calls. Speed of dots increases with calls/sec — you can feel the traffic visually.

The controls (top-left toolbar)

On screen
  • Time pickerSame as everywhere — the graph reflects whatever range you pick.
  • Environment filterProduction-only, staging-only, or all.
  • Health filter"Show only nodes with health = rose" hides the rest. Useful during an incident.
  • Edge metricSwitch what edge thickness encodes: calls/sec (default), latency p99, error rate.
  • LayoutForce-directed (default), hierarchical (sources on the left), or radial (cluster around a chosen root).
  • GroupGroup nodes by team, namespace, or environment. Groups draw a tinted region behind the cluster.
  • Fit / reset"Fit to screen" recentres and zooms; "Reset positions" un-pins any nodes you dragged.

Selecting a node

Click a service. The right-side drawer slides in with:

  • Health pill, current SLO burn, RPS now.
  • "Open service detail" button.
  • A list of every direct upstream (callers) and direct downstream (callees) with per-edge stats.
  • A "fan-out" number: how many distinct services this node talks to. A node whose fan-out grew suddenly is often the culprit in cascading-failure incidents.
  • A mini chart: this service's error-rate over the window.

Esc closes the drawer. Clicking another node updates the drawer in place.

Selecting an edge

Click the arrow itself. The drawer changes to show:

  • Calls/sec on this edge.
  • p50/p99 latency on this edge.
  • Error-rate on this edge.
  • "View traces on this edge" — opens Traces filtered to spans where parent.service.name=A and service.name=B.

This is the most under-used feature of the map. If you suspect one specific dependency, click that exact edge.

How to use the map during an incident

  1. 1

    Set the time picker to the incident window

    Click the alert that paged you → it deep-links you here with the right window already set, or set "Last 15 m" yourself.

  2. 2

    Look for rose

    Your eyes will go straight to red — that's the point of the colour code. Rose nodes are the unhappy ones.

  3. 3

    Follow the arrows backward

    If a rose node has an upstream that's also rose, the upstream is probably the root cause and the downstream is collateral. Walk the chain back to the earliest rose.

  4. 4

    Check the rose edges, not just rose nodes

    Sometimes the node is fine on average but one specific edge to it is failing. Rose edges into a healthy-looking emerald node are a sign of a partial outage that only affects one caller.

  5. 5

    Click the suspect, open service detail

    From there, dive into the chart that's anomalous and pivot into logs/traces.

When the map looks wrong

  • A service is missing → it hasn't emitted any spans in the time window. If you expected traffic, check whether the SDK is wired up and whether the time picker is too narrow.
  • Edges are missing between services that talk → the caller isn't propagating trace context. The OTel SDK does this automatically except for queue-based async calls — Orbtrace's async stitching feature reconstructs those links and marks them on the trace waterfall with a stitched-edge badge and a confidence score.
  • The graph is a "hairball" with everything connected to everything → use the Group control to cluster by team or namespace; the hairball usually decomposes nicely.

Pinning a layout for a war room

When you're sharing the map on a screen during an incident, the auto-layout can shuffle nodes between refreshes which is annoying. Drag a node — it stays where you put it for the rest of your session. Click Save as default layout in the toolbar if you want the layout to persist across reloads for everyone.

Next: Logs.