Service view#

The service view is the page you open when someone says an application is slow. It brings together everything known about one service: its throughput, errors, latency, dependencies, traces, logs and profiles.

Opening it#

APM → Services lists every service that has sent data in the selected time range. Click one to open its service view. Services appear automatically; there is nothing to register.

What the page shows#

Golden signals#

At the top: request rate, error rate and response time, with percentiles rather than only averages. An average hides the slow tail, which is usually the thing users are complaining about, so read the 95th and 99th percentiles first.

Operations#

A breakdown by endpoint or operation, sorted by total time consumed. This is the most useful table on the page: it distinguishes an endpoint that is slow from an endpoint that is slow and called constantly. The second is what to fix.

Dependencies#

Which services and databases this service calls, with the latency and error rate of each call. When a service is slow because something it depends on is slow, this is where it shows.

Traces#

The slowest and most recent traces, filterable by status and duration. Click one to open the waterfall.

Logs and profiles#

Logs emitted by the service in the same time window, and CPU or memory profiles if the service is profiled. Both are already filtered to this service.

Reading a trace waterfall#

Each bar is a span: one operation, with its duration. Nesting shows what called what.

A wide bar with narrow children means the time was spent in the service itself, not in something it called. Look at the profile.
A wide child means a dependency was slow. Follow it into that service.
A gap between spans means time was spent somewhere that is not instrumented. That is usually a queue, a lock, or garbage collection.

Comparison against normal#

Response times are compared against the same hour in previous weeks rather than a fixed threshold. A Monday nine o'clock peak is not flagged as a fault just because it is higher than Sunday at three in the morning.

Service naming#

The service name comes from service.name in your OpenTelemetry configuration. Two rules save significant confusion later:

Use the same name across environments and separate them with deployment.environment instead. Otherwise you get checkout-api-prod and checkout-api-staging as two unrelated services and cannot compare them.
Keep the name stable across deployments. Renaming a service starts its history over.