Set up tracing

Send a service name #

A service appears once your traces report it, so service.name is the one attribute to get right first. It is the primary key for every service-level view: two services sharing a name appear as one service with doubled traffic.

service.name              required — the service's identity
deployment.environment.name  the environment column
version                  the version, for release comparison
host.name                the host, for service-to-machine drilldown
service.version          the version, when `version` is taken by something else

Start with the entry span #

A request is an entry span: a server or consumer span, or a span with no parent. The requests-per-second figure counts entry spans, so a service whose spans are all children has traffic attributed to whatever called it.

Make sure the outermost HTTP handler on each service is a server span. A framework that only produces client spans makes its service look like part of its caller.

Correlate with logs #

Logs carry trace and span identifiers when the sender can correlate them. With that in place, a log line links to the request that produced it, which is the single most useful thing you can wire up early.

trace_id      links a log to the request
span_id       links a log to the exact operation

Check your work #

• APM lists your service with traffic and latency.
• APM → Traces shows requests as they complete.
• Infrastructure lists the hosts your spans named.

Then #

Once services are listed, Services and latency explains what the numbers mean, and Searching traces shows how to open a slow request and follow it to its cause.

To keep ingest under control, Ingestion controls covers sampling by host, service and endpoint.