Skip to main content
The service inventory is every service that has emitted telemetry. The service map is the graph of which of them call which, built from observed parent-child relationships between spans. Both are discovered, never configured. There is nothing to register and no topology file to maintain — which also means the map shows what is true rather than what someone documented.
Before you start. You need traces from at least two services that call each other. A single service produces an inventory entry and no edges.

​
What identifies a service

service.name, and nothing else.
A service that does not set service.name becomes unknown_service, and every such service collapses into one entry that looks enormous and is not anything.If your map has a single huge node with edges to everything, this is why. Fix it at the source — see Resource attributes.
Two corollaries worth knowing before you name anything:
  • The same name in two environments is one service. Use deployment.environment to separate them, not checkout-api-staging.
  • The same name in two clusters is one service. Set a cluster name when installing a Collector or agent per cluster, or two clusters silently merge.

​
Reading the map

The map is scoped to the time range. A service that was quiet in the last 15 minutes is absent from a 15-minute map. Widen the range before concluding something is gone.

​
Why an edge is missing

In likelihood order:
1

Context propagation broke

The callee received no traceparent and started its own trace, so there is no parent-child relationship to draw. The tell is that the callee still appears as a node, with its own root traces.
2

One side is not instrumented

A service that emits nothing cannot appear, and its callers show a call to an unnamed peer instead of an edge.
3

Independent sampling

Services sampling separately produce partial traces, so some edges exist in some traces and not others. See Sampling.
4

The call is not over an instrumented protocol

Work handed over through a queue, a shared database or a file is a real dependency that produces no span linking the two.
The map shows the edges that carry instrumented traffic — not your architecture. A dependency through a message queue, a shared table or a cron job is genuinely invisible here. Do not read an absent edge as an absent dependency.

​
Zero-code fills the gaps

The most common reason a map is incomplete is that some services were never instrumented and never will be. The eBPF agent observes them at the socket boundary, so they appear without anyone changing their code. That is the strongest case for zero-code instrumentation: coverage of exactly the services an SDK rollout was never going to reach. See Zero-code instrumentation.

​
What else is discovered

Versions are how you connect a regression to a release. If error rate moved at the same moment a new service.version appeared, you have your answer in one step. This requires setting service.version — it is the third most valuable resource attribute after name and environment.

​
Next

Explore traces

The spans the map is built from.

Infrastructure

Hosts, containers and Kubernetes beneath these services.

Zero-code instrumentation

Fill the gaps without changing code.