> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Infrastructure and Kubernetes

> Hosts, processes, containers, Kubernetes objects, databases and network flows — what appears here, and what you must send for it to appear.

Beneath your services is the infrastructure running them. These views cover
hosts and processes, Kubernetes objects, database telemetry and observed
network flows.

<Warning>
  **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](/send-data/otel/collector-config#receivers-beyond-otlp).
</Warning>

## Hosts and processes

| View            | Shows                                     |
| :-------------- | :---------------------------------------- |
| **Hosts**       | Every host seen, with its resource usage  |
| **Host detail** | One host in depth                         |
| **Processes**   | What is running, and what it is consuming |
| **Compute**     | Aggregate CPU and memory                  |
| **Disks**       | Filesystem and disk usage                 |

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

| View           | Shows                          |
| :------------- | :----------------------------- |
| **Clusters**   | Clusters reporting telemetry   |
| **Nodes**      | Nodes and their capacity       |
| **Namespaces** | Namespaces and their workloads |
| **Pods**       | Pods, phases and restarts      |
| **Containers** | Per-container resource usage   |

<Warning>
  **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](/send-data/platforms/kubernetes).
</Warning>

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.

<Note>
  **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.
</Note>

## Network

| View         | Shows                                  |
| :----------- | :------------------------------------- |
| **Flows**    | Observed connections between endpoints |
| **Topology** | The resulting network-level graph      |

<Note>
  **Network topology and the [service map](/guides/services/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.
</Note>

## Filling gaps without changing code

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

<CardGroup cols={2}>
  <Card title="Install a Collector" icon="server" href="/send-data/overview">
    Host, container and Kubernetes telemetry, with no change to your
    applications.
  </Card>

  <Card title="Zero-code instrumentation" icon="wand-magic-sparkles" href="/zero-code/overview">
    Application spans and RED metrics from services nobody instrumented. Early
    access.
  </Card>
</CardGroup>

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

<CardGroup cols={3}>
  <Card title="Kubernetes install" icon="dharmachakra" href="/send-data/platforms/kubernetes">
    A DaemonSet and gateway pair, with working manifests.
  </Card>

  <Card title="Service map" icon="diagram-project" href="/guides/services/service-map">
    The logical view above this one.
  </Card>

  <Card title="Alerting" icon="bell" href="/guides/alerts/overview">
    Alerting on host and pod conditions.
  </Card>
</CardGroup>