A service map turns your traces into a live picture of how services depend on each other, and where the failure is.
A service map is an automatically generated topology of your services and how they call each other, derived from distributed traces, showing the dependency graph with request rate, latency and error rate on each edge.
Because every trace records which service called which, aggregating traces reveals the call graph: nodes are services, edges are calls, and each edge can carry its own rate, latency and error rate. The map is generated from real traffic, so it reflects how the system actually behaves, not an out-of-date architecture diagram.
When an incident hits, the service map shows blast radius and direction: which downstream dependency is failing, which upstreams are affected, and where latency originates. It turns 'something is slow' into 'this edge between these two services is the problem', which is where investigation should start.
Sentinel AI uses service topology when it investigates, tracing a symptom along the dependency graph to the service and edge actually responsible before it proposes an action.
From distributed traces: aggregating which service calls which produces the dependency graph, with per-edge rate, latency and error metrics.
A service map is generated from live traffic and stays current; an architecture diagram is drawn by hand and drifts from reality.
Ops Singularity turns open telemetry into autonomous, governed resolution. See it on your own stack.