Kubernetes DaemonSets Monitoring: Rollout and Resource Usage

The DaemonSets view shows rollout status and aggregated resource usage. If Available < Desired, the DaemonSet is not fully rolled out: possible causes include taints without tolerations, insufficient resources, or cordoned nodes.

Kubernetes DaemonSets list view showing available/desired counts and resource columns — *DaemonSets List View*

DaemonSets List Page Columns

DaemonSet Name

This column is derived from the resource attribute k8s.daemonset.name.
Identifier of the Kubernetes DaemonSet.
Click the name to open the detail page and drill into CPU/memory vs request/limit charts, network activity, logs, and events for the DaemonSet's pods across all the nodes it runs on.

Namespace Name

This column is derived from the resource attribute k8s.namespace.name.
Namespace the DaemonSet belongs to.
Use it to filter the list to a specific tenant or team and to navigate to the namespace-level view for aggregate workload status across Deployments, StatefulSets, DaemonSets, and Jobs.

Scheduled Nodes

A combined, always-visible summary of the daemonset's node scheduling: Current (green) and Desired (blue) shown side by side. Both are described in full in the Current and Desired sections below. At a glance: Current equal to Desired means the daemon pod is running on every node it should; Current below Desired means some target nodes are not yet running it (scheduling pressure, taints, or a rollout in progress).
This summary is display-only and cannot be sorted. To sort the list by node count, enable the dedicated Current Nodes and Desired Nodes columns (both hidden by default) from the Columns selector.

Current

This column relies on the OTel metric k8s.daemonset.current_scheduled_nodes from the k8s_cluster receiver, defined as "Number of nodes that are running at least 1 daemon pod and are supposed to run the daemon pod".
This is the K8s .status.currentNumberScheduled field: the count of nodes where the DaemonSet's pod has been placed and the placement is still valid (i.e., the node still matches the DaemonSet's nodeSelector / affinity / tolerations). Note this is a node count, not a pod count.
Current < Desired means some target nodes are missing the DaemonSet's pod: typical causes are taints without matching tolerations, insufficient node CPU/memory for the pod's requests, image-pull failure on those nodes, or a recently cordoned node.

Desired

This column relies on the OTel metric k8s.daemonset.desired_scheduled_nodes from the k8s_cluster receiver, defined as "Number of nodes that should be running the daemon pod".
This is the K8s .status.desiredNumberScheduled field: the count of nodes that match the DaemonSet's selectors and where the controller intends to run the pod. Again a node count, not a pod count; the value grows as new matching nodes join the cluster (Cluster Autoscaler scale-up) and shrinks when nodes are removed.
Sudden changes in Desired usually trace back to a nodeSelector / affinity edit on the DaemonSet, a node-label change, or cluster auto-scaling. Pair with Current to spot lag between scheduling intent and actual coverage.

Ready

This column relies on the OTel metric k8s.daemonset.ready_nodes from the k8s_cluster receiver, defined as "Number of nodes that should be running the daemon pod and have one or more of the daemon pod running and ready".
This is the K8s .status.numberReady field: the count of nodes where the DaemonSet's pod is not just placed but has passed its readiness probe. A node count, not a pod count; it is a subset of Current (a pod can be scheduled and running yet not Ready).
Ready < Desired means the rollout isn't fully healthy even where pods are placed: typical causes are failing/slow readiness probes, CrashLoopBackOff, or resource pressure on those nodes. Watch the gap between Ready and Current: Current says "pod is placed", Ready says "pod is actually serving".

Misscheduled

This column relies on the OTel metric k8s.daemonset.misscheduled_nodes from the k8s_cluster receiver, defined as "Number of nodes that are running the daemon pod, but are not supposed to run the daemon pod".
This is the K8s .status.numberMisscheduled field: the count of nodes running the DaemonSet's pod even though they no longer match its nodeSelector / affinity / taints. A node count, not a pod count; the DaemonSet controller reconciles these by evicting the stray pods, so the value should normally be 0.
A non-zero value is usually transient right after a nodeSelector / affinity edit or a node relabel, while the controller cleans up stale pods. Sustained non-zero (green at 0, warning when > 0) points to pods that can't be evicted. Check for recent selector/label changes or terminating-pod issues on the affected nodes.

CPU Req Usage (%)

This column relies on the OTel metric k8s.pod.cpu_request_utilization from the kubeletstats receiver, averaged across the DaemonSet's pods.
Average ratio of pod CPU usage to the sum of its containers' CPU requests across the DaemonSet's pods, expressed as a percentage. Values consistently >100% mean pods are using more CPU than reserved (allowed, but a signal requests are under-provisioned); values well below 50% indicate over-provisioned reservations.
Use this to detect under-/over-provisioning at the DaemonSet level. Adjust resources.requests.cpu in the DaemonSet's pod template (any change applies to every targeted node, so the effect on cluster-wide reservation is N × delta where N = Desired).
Color of the in-table progress bar reflects the value: amber below 50% (request likely over-provisioned, wasted capacity), green between 50% and 100% (healthy), red between 100% and 150% (request under-provisioned), and dark red above 150%.

CPU Limit Usage (%)

This column relies on the OTel metric k8s.pod.cpu_limit_utilization from the kubeletstats receiver, averaged across the DaemonSet's pods.
Average ratio of pod CPU usage to the sum of its containers' CPU limits across the DaemonSet's pods, expressed as a percentage. Per K8s docs, "when a container approaches its cpu limit, the kernel restricts access to the CPU". Values near 100% indicate active or imminent throttling.
Sustained high values mean the DaemonSet's pods are throttling under load; raise limits.cpu to give them headroom.
Color of the in-table progress bar reflects the value: green below 60% (healthy headroom), light amber between 60% and 80% (caution), amber between 80% and 95% (high, throttling becoming likely), and red above 95% (critical, at or beyond the limit).

CPU Usage (cores)

This column relies on the OTel metric k8s.pod.cpu.usage from the kubeletstats receiver, summed across the DaemonSet's pods.
Total CPU consumed by all of the DaemonSet's pods in CPU-core units: a value of 1.0 means one full core in use across the DaemonSet.
Use this for absolute capacity planning when you need the DaemonSet's raw CPU draw rather than a ratio; pair with the chart on the detail page to see how the cores trend against the DaemonSet's aggregate requests/limits.

Mem Req Usage (%)

This column relies on the OTel metric k8s.pod.memory_request_utilization from the kubeletstats receiver, averaged across the DaemonSet's pods.
Average ratio of pod memory usage to the sum of its containers' memory requests, expressed as a percentage. As with CPU, sustained values >100% mean pods are using more memory than reserved; values well below 50% indicate over-provisioned reservations.
Use this to right-size the DaemonSet's resources.requests.memory; consistently low values free up scheduling capacity for other workloads on every node the DaemonSet runs on.
Color of the in-table progress bar reflects the value: amber below 50% (request likely over-provisioned, wasted capacity), green between 50% and 100% (healthy), red between 100% and 150% (request under-provisioned), and dark red above 150%.

Mem Limit Usage (%)

This column relies on the OTel metric k8s.pod.memory_limit_utilization from the kubeletstats receiver, averaged across the DaemonSet's pods.
Average ratio of pod memory usage to the sum of its containers' memory limits, expressed as a percentage. Per K8s docs, "when a container uses more than its memory limit, the kernel may terminate it" via an OOMKill. Values near 100% indicate sustained OOMKill risk.
Sustained values approaching 100% mean a single pod in the DaemonSet is on the verge of an OOMKill; raise limits.memory or fix the memory leak in the DaemonSet's container.
Color of the in-table progress bar reflects the value: green below 60% (healthy headroom), light amber between 60% and 80% (caution), amber between 80% and 95% (high, OOMKill becoming likely), and red above 95% (critical, at or beyond the limit).

Mem Usage (WSS)

This column relies on the OTel metric k8s.pod.memory.working_set from the kubeletstats receiver, summed across the DaemonSet's pods.
Total Working Set Size across the DaemonSet's pods: anonymous + active file pages, excluding reclaimable inactive file pages (the value the kubelet uses for eviction).
Sustained high WSS without explicit limits.memory on the DaemonSet's containers means individual pods can grow until the kubelet evicts them under node MemoryPressure; set explicit limits or add a LimitRange to the namespace.

Pod Counts by Phase

This column relies on the OTel metric k8s.pod.phase from the k8s_cluster receiver, encoded 1 = Pending, 2 = Running, 3 = Succeeded, 4 = Failed, 5 = Unknown.
Counts of the DaemonSet's pods grouped by their latest observed lifecycle phase within the selected window, per the Kubernetes pod-lifecycle spec.
A Pending count means one or more of the DaemonSet's pods can't be placed on their target nodes: typically a taint without matching toleration or requests larger than the node's available capacity; Failed / Unknown warrant inspecting kubectl describe daemonset/<name> and the affected pods' events.

Pod Counts by Status

This column relies on the OTel metric(s): k8s.pod.phase, k8s.pod.status_reason, and k8s.container.status.reason from the k8s_cluster receiver. The latter two are disabled by default in the upstream receiver but enabled by default in the k8s-infra chart; all three must be flowing for this column to be populated.
Counts of the DaemonSet's pods grouped by their kubectl-style display status within the selected window. The status is derived exactly as on the Pods view: see Pod Status for the full priority cascade, the statuses it surfaces, and the statuses it cannot derive.
Because a DaemonSet runs the same pod fleet-wide, a CrashLoopBackOff / Error count usually means the agent image or config is broken on every node at once, while OOMKilled points to the per-node resource budget being too tight; inspect with kubectl describe daemonset/<name> and the affected pods' logs.

DaemonSet Detail Page

Click a DaemonSet name to open the detail page. The header shows DaemonSet Name, Cluster Name, and Namespace Name. The detail page includes five tabs: Metrics, Logs, Traces, Events, and Pod Metrics.

DaemonSets Metrics - Charts and Panels

CPU Usage, Request, Limits

This chart relies on the OTel metrics k8s.pod.cpu.usage, k8s.container.cpu_request, and k8s.container.cpu_limit from the kubeletstats receiver, aggregated across the DaemonSet's pods and containers.
Plots three series, all averaged within the step interval and summed across the DaemonSet's pods: the DaemonSet's total CPU Usage in cores, container CPU Requests, and container CPU Limits. Usage approaching Limits means the kernel is throttling; Usage well below Requests means the DaemonSet is reserving more capacity than it consumes (multiplied by the number of nodes it runs on).
Use this to right-size the DaemonSet's requests.cpu and limits.cpu and to confirm whether high CPU Limit Usage (%) on the list page corresponds to a real throttling pattern. If Usage hugs the Limits line, throttle events are happening.

Memory Usage, Request, Limits

This chart relies on the OTel metrics k8s.pod.memory.usage, k8s.container.memory_request, and k8s.container.memory_limit from the kubeletstats receiver, aggregated across the DaemonSet's pods and containers.
Plots three series, all averaged within the step interval and summed across the DaemonSet's pods: the DaemonSet's total Memory Usage in bytes, container Memory Requests, and container Memory Limits. Note that this uses k8s.pod.memory.usage (which includes reclaimable page cache), so it reads higher than the working-set value the kubelet uses for eviction decisions.
Use this alongside the Mem Limit Usage (%) column on the list page: Usage approaching Limits is a leading indicator for OOMKills, and inspecting whether it's a slow climb (leak) or a sudden spike (workload change) shapes the fix.

Network IO

This chart relies on the OTel metric k8s.pod.network.io from the kubeletstats receiver, a cumulative Sum in bytes with attributes direction and interface, shown as a per-second rate and aggregated across the DaemonSet's pods.
One line per direction :: interface combination, showing transmit/receive throughput across all pods of the DaemonSet.
Use this to detect whether the DaemonSet is the source of unusual network load on a node: sudden throughput spikes, sustained saturation near the underlying NIC's rated bandwidth, or a discontinuity in the receive-vs-transmit pattern that doesn't track an explained workload change are the signals worth investigating. "No Data" means none of the pods are reporting per-pod network metrics.

Network Errors Count

This chart relies on the OTel metric k8s.pod.network.errors from the kubeletstats receiver, a cumulative Sum with attributes direction and interface, shown as a per-second increase and aggregated across the DaemonSet's pods.
One line per direction :: interface combination, sourced from the kubelet's per-pod-interface error counters.
Sustained non-zero values warrant attention: common causes are misconfigured CNI plugins, MTU mismatches, or faulty NICs on the underlying nodes; correlate with the Node Detail → Network Errors chart on the specific node(s) hosting the DaemonSet's pods.

Pod Metrics

The Pod Metrics tab breaks resource utilization down per pod across every pod in the DaemonSet (a DaemonSet runs one pod per node, so each line is effectively one node). All charts are scoped to this DaemonSet (filtered by k8s.cluster.name, k8s.namespace.name, and k8s.daemonset.name), grouped by k8s.pod.name (one line per pod), averaged within each step interval, and expressed as a percentage.

CPU Limit Utilization By Pod Name

This chart relies on the OTel metric k8s.pod.cpu_limit_utilization from the kubeletstats receiver, a pod's CPU usage as a fraction of the sum of its containers' CPU limits, emitted directly as a ratio.
Plots one line per pod in the DaemonSet, each showing that pod's CPU usage against its CPU limit; values near 100% mean the kernel is actively throttling that pod's CPU.
Use it to pinpoint which node's pod is throttled: a single line hugging 100% while the rest sit low points to one node carrying more work, whereas all pods running high means the DaemonSet's limits.cpu is too low for the workload.

CPU Request Utilization By Pod Name

This chart relies on the OTel metric k8s.pod.cpu_request_utilization from the kubeletstats receiver, a pod's CPU usage as a fraction of the sum of its containers' CPU requests.
Plots one line per pod in the DaemonSet, each showing usage against its CPU request; values above 100% mean the pod is using more CPU than it reserved (allowed, but a sign the request is low).
Use it to judge reservation accuracy per pod: pods consistently far below 100% are over-provisioned, pods above it are under-requested; since a DaemonSet runs one pod per node, uneven values reflect differing per-node load.

Memory Limit Utilization By Pod Name

This chart relies on the OTel metric k8s.pod.memory_limit_utilization from the kubeletstats receiver, a pod's memory usage as a fraction of the sum of its containers' memory limits.
Plots one line per pod in the DaemonSet, each showing that pod's memory usage against its memory limit; a line at or near 100% is a pod on the verge of an OOMKill.
Use it to isolate the node whose pod is at risk: a steady per-pod climb is a memory-leak signature on that node; raise limits.memory or fix the leak.

Memory Request Utilization By Pod Name

This chart relies on the OTel metric k8s.pod.memory_request_utilization from the kubeletstats receiver, a pod's memory usage as a fraction of the sum of its containers' memory requests.
Plots one line per pod in the DaemonSet, each showing usage against its memory request; values above 100% mean the pod exceeds its reservation.
Use it to right-size requests.memory and catch per-node imbalance: pods well below 100% reserve memory they never use, while pods above it risk eviction first under node memory pressure.

FileSystem Usage Percentage By Pod Name

This chart is derived from two kubeletstats metrics: k8s.pod.filesystem.usage (bytes used) divided by k8s.pod.filesystem.capacity (total bytes); only the computed ratio is plotted, not the raw metrics.
Plots one line per pod in the DaemonSet, each showing that pod's local/ephemeral filesystem fill level as a percentage of its capacity.
Watch any pod trending toward 100%: that node's pod is filling its ephemeral storage (unrotated logs, cached artifacts, temp files) and writes will start failing or the pod may be evicted; the line isolates the node.

Next steps

Kubernetes Monitoring: back to the Kubernetes Monitoring overview.
Setup Kubernetes Metrics: configure the receivers this page's metrics depend on.
Nodes and Pods: see the nodes this DaemonSet runs on or drill into individual pods.