Reading traces and the service map

Reading traces and the service map

The service map

The map shows every service and the calls between them, with health and latency on each edge. Use it to spot a single degraded dependency rippling outward, and click a node to drill into its traces and errors.

The trace waterfall

A trace is a waterfall of spans. Read it top-down:

• Total duration at the root tells you how slow the request was.
• The longest span is usually your bottleneck — often a DB query or a downstream call.
• Red spans carry errors; open one for the exception and attributes.
• Gaps between spans can indicate queueing or uninstrumented work.

Method-level profiling

When a span is slow but you need the exact code path, profiling surfaces the hot methods and their invocation counts so you can go straight to the offending function.

Worked example: "checkout got slow at 14:20"

1. Service map shows checkout-api latency up; the edge to payments is red.
2. Open a slow trace: the payments.authorize span dominates.
3. Errors view shows timeouts beginning at 14:20 — matching a deploy on the timeline.
4. Open a War Room (or it auto-opened) to coordinate the rollback.

Want this correlation automatically on a schedule? An APM Observe node in a Workbook asserts hasErrors == false and a latency budget for a service after your synthetic journey runs.