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
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.
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.