How persistent volume claim monitoring works
The discovery of persistent volume claims and the State, Resize, Used and Inodes monitors
Applies to: Opslogix Kubernetes Management Pack (V26.11.4546.0 and later)
Last updated: November 2026 · Latest version: 26.11.4546.0
See also: Upgrade guide for 26.11.4546.0 · List of rules and monitors · Release notes
Stateful workloads such as databases keep their data on persistent volumes, which they request with a persistent volume claim. From V26.11.4546.0 the Opslogix Kubernetes Management Pack discovers every claim and warns you when a claim cannot bind, loses its volume, cannot be resized or runs out of space.
Discovery
Claims are discovered every hour under their namespace, as objects of the class Kubernetes Persistent Volume Claim with the properties Namespace, Storage Class, Access Modes, Volume Mode, Volume Name and Requested Storage. You find them in the Persistent Volume Claims folder of the Kubernetes views, which has a state view, an alert view and a performance view. A claim that is created in a namespace that SCOM discovered less than an hour ago can take up to an hour longer to appear.
Monitors
| Monitor | Healthy | Warning | Critical |
|---|---|---|---|
| Kubernetes Persistent Volume Claim State | Bound, or pending until a pod uses it (see below) | Pending | Lost: the volume the claim was bound to no longer exists |
| Kubernetes Persistent Volume Claim Resize | No resize in progress | A resize stays in Resizing or FileSystemResizePending | The resize keeps failing |
| Kubernetes Persistent Volume Claim Used Percentage | 80% or less | above 80% | 90% or more |
| Kubernetes Persistent Volume Claim Inodes Used Percentage | 85% or less | above 85% | 95% or more |
The monitors run every 300 seconds. The State monitor changes after 2 consecutive samples and the Resize monitor after 3, so a claim that is still being provisioned or a resize that completes normally does not raise an alert. The availability, configuration and performance states roll up to the namespace.
Claims that wait for their first consumer
A storage class with volumeBindingMode WaitForFirstConsumer only provisions a volume when a pod that uses the claim is scheduled. Such a claim is pending on purpose until then, so the State monitor keeps it healthy as long as no pod uses it. When a pod uses it and the claim stays pending, the monitor turns Warning.
Resize failures
When you increase the requested size of a claim, Kubernetes first expands the volume (Resizing) and then the filesystem on the node (FileSystemResizePending). The Resize monitor turns Critical when the claim has the condition ControllerResizeError or NodeResizeError (Kubernetes 1.31 and later), or when it is still resizing and Kubernetes reported a VolumeResizeFailed or FileSystemResizeFailed warning event for it. Most storage drivers only report a failure as such an event. Kubernetes throttles repeated events and removes events after an hour, so the collector remembers a failure until the resize completes or another size is requested. After a restart of the collector it only sees new failure events, so a resize that keeps failing can show Warning until the next failure event. The alert shows the error message of the storage driver.
Used and inodes percentage
Usage comes from the kubelet Summary API, the same source as the disk usage of nodes and pods. The kubelet only reports a volume while a running pod has it mounted, and only when the storage driver supports volume stats (for CSI drivers, the NodeGetVolumeStats capability). Without that, no usage data is collected and the monitors stay healthy. Block volumes and some network filesystems do not report inodes.
Performance collection rules
Persistent Volume Claim \ Capacity \ Bytes (the size of the bound volume), Used \ Percentage, Available \ Bytes and Inodes Used \ Percentage.
Requirements
The account in the kube config needs list permission on persistentvolumeclaims, pods and storageclasses, list on events to detect resize failures, and get on nodes/proxy for the usage. The read-only cluster role in How to create a Kubernetes monitoring account already grants all of these.
Troubleshooting
- A claim is pending. No volume matches the claim and dynamic provisioning failed or is not set up: the storage class does not exist, its provisioner is not running, or the storage backend has no capacity for the requested size or access mode. Run kubectl describe pvc NAME -n NAMESPACE and check the events.
- A claim is lost. Its persistent volume was deleted; the data may be gone. Restore the volume or the data from a backup.
- A resize does not complete. FileSystemResizePending: storage drivers without online expansion grow the filesystem only when the volume is mounted again; restart the pod that uses the claim. Resizing for a long time or failing: the resizer of the storage driver is not running, or the backend cannot grow the volume, for example because of a quota or too little capacity.
- No usage data. No running pod mounts the volume, or the storage driver does not report volume stats.