Containers and Kubernetes

Monitor → Infrastructure → Containers starts with workloads: a Deployment, DaemonSet, or Compose service with its containers grouped together. This lets you find the application consuming resources before inspecting individual container instances.

Two collectors answer different questions. Containers measures resources on a node. Kubernetes reads cluster state from the API. You can use either alone or combine them for a fuller investigation.

Collect container resources

1. Create a Containers check in Configure → Test management and assign it to an agent on the host you want to measure.
2. On Linux, ensure that the agent can read the host’s cgroup hierarchy. An agent running inside a container needs the host cgroup filesystem mounted to see workloads outside its own container.
3. Choose an Identity source. Auto tries kubelet, Docker, then Podman, and falls back to container IDs. An explicit source reports a degradation if it is unavailable. None (ids only) skips identity lookup on Linux.
4. Verify a successful sample, then open Infrastructure’s Containers tab.

The default collection interval is 60 seconds. On Linux, resource accounting comes from cgroups, so Docker, containerd, CRI-O, and Podman workloads can be measured without a separate metrics integration for each runtime. Access to kubelet or a supported runtime endpoint adds names, images, pods, and workload identity. A resource reading can be valid even when the container could not be named.

On Windows and macOS, collection uses a Docker-compatible Engine endpoint for both statistics and identity. The endpoint must be reachable even when None (ids only) is selected. Restart and OOM counters are not supplied by that statistics path; do not assume the Linux fields are available everywhere.

Read workloads, then containers

Use Workloads for an application-level view across reporting hosts, and Containers for individual container rows. Search by workload, pod, container, image, or ID. A machine’s own Containers tab narrows the view to that host.

Depending on the source, rows include:

• CPU consumption and throttling, with summed consumption for a workload.
• Memory usage, configured limits, and usage against those limits when known.
• Network and block I/O rates, and process counts.
• Running state, restart information, and OOM kills where supplied.
• Runtime, identity source, owning workload, namespace, and sample freshness.

CPU percentages can exceed 100% when a workload consumes more than one core. An absent memory limit is not unlimited free memory; there is no known limit against which to calculate that percentage.

Container grouping uses the name within its pod when available so a restart can remain the same row. Workload grouping connects replacement pods under their controller or service identity. Unnamed containers cannot provide the same workload context.

Add Kubernetes cluster state

Create a Kubernetes check on exactly one collector agent with the Kubernetes plugin and read-only access to the cluster API. Set Cluster name to a stable name that distinguishes it from other clusters in the account. Use Namespaces only when you intend to limit coverage.

The cluster collector reports pod phases, workload replicas, restarts, unschedulable pods with the scheduler’s message, and node conditions. It provides the control-plane explanation for symptoms such as a rollout that cannot reach its desired replica count. Read its test results and use supported metrics in dashboards and health rules.

This is separate from the node-local container inventory. Running the cluster collector on every node would repeat cluster-wide facts. A node agent or DaemonSet collects node resources; a single cluster reader collects API state. Namespace filters and bounded workload lists limit the scope of those results.

Example: a deployment is slow after a rollout

1. Search for the workload in Containers and select a window covering the rollout. Check CPU throttling, memory usage against limits, restarts, and OOM evidence.
2. Switch to Containers to see whether the behavior is widespread or tied to particular pods or hosts.
3. Open an affected machine for host and kernel measurements. Container throttling and host-wide scheduler pressure answer different questions.
4. Check the Kubernetes test for unavailable replicas or unschedulable pods. Read the scheduler’s message before assuming resource use explains the rollout.
5. If resources look adequate, inspect the host’s passive TCP traffic and the service’s active tests during the same period.

Interpret gaps and limits

CPU and I/O rates require successive samples. Initial samples and counter resets can leave rates absent. An OOM counter can reset when a container restarts, so the reported event count may be a lower bound.

In Advanced, Include stopped containers controls whether retained, non-running containers appear. Max containers bounds each sample; the total and truncation information explain when the detail list is incomplete. Label keys chooses the labels copied onto samples. Prefer stable labels such as application or tier over labels that change on every rollout.

If rows have resource values but only opaque IDs, check the identity source’s permissions and connectivity. If Linux reports only the agent’s own container, check its cgroup view and host mounts. If the list is entirely empty, verify the check and its latest result before concluding that no containers exist.

Continue with Infrastructure troubleshooting or Metrics Explorer to inspect supported container and Kubernetes metrics by their own dimensions.