Skip to main content
Beneath your services is the infrastructure running them. These views cover hosts and processes, Kubernetes objects, database telemetry and observed network flows.
None of this appears on its own. Application SDKs produce spans, logs and metrics about your code; they know nothing about CPU pressure, disk usage or pod restarts.Infrastructure telemetry comes from a Collector with the right receivers enabled. If these views are empty, that is the reason — see Collector configuration.

Hosts and processes

Produced by the Collector’s host metrics receiver. Correlation with your services works through host.name, so that attribute is what connects “this service is slow” to “this host is out of memory”.

Kubernetes

Set a cluster name. Without one, two clusters reporting into a single organization are indistinguishable — the same namespace name from two places, silently merged into one view.This is set once when installing the Collector or agent per cluster, and it is very annoying to correct after the fact. See Kubernetes.
Kubernetes attributes are attached to telemetry by the Collector’s Kubernetes attributes processor, which needs read access to pods. That is what makes a span from a service also carry its pod, namespace and node — and it is what makes “which pod served this failing request” a one-click question.

Databases

Per-engine database telemetry, with time series. Populated from database metrics you collect, or from the client-side spans your application already produces when it queries.
Client-side database spans are free if your services are instrumented. Auto-instrumentation captures outbound queries, so query latency and error rate appear without any database-side configuration at all. That covers most of what an application team needs; server-side engine metrics are what you add when you need to see the database’s own health.

Network

Network topology and the service map are different pictures. The service map is built from trace parent-child relationships — it shows logical calls between named services. Network topology shows observed connections, including from things that emit no traces at all.When the service map is missing an edge you know exists, network flows will often show it. That difference is frequently the diagnosis.

Filling gaps without changing code

The most common reason infrastructure looks incomplete is that some hosts never had a Collector installed. The two answers:

Install a Collector

Host, container and Kubernetes telemetry, with no change to your applications.

Zero-code instrumentation

Application spans and RED metrics from services nobody instrumented. Early access.
They are complementary rather than alternatives: the Collector produces infrastructure telemetry the eBPF agent does not, and the agent produces application spans the Collector cannot see.

Next

Kubernetes install

A DaemonSet and gateway pair, with working manifests.

Service map

The logical view above this one.

Alerting

Alerting on host and pod conditions.