What should server disk-capacity monitoring include?
Monitor the storage layer that the application actually writes to, not only the server’s total advertised disk size. Filesystem space, quotas, volume pools and application limits can fail independently. On filesystems that use a fixed inode allocation, file-count exhaustion is another separate risk.
Before you start
- An inventory of application data paths, mounted volumes, quotas and storage layers.
Instructions
1. Map each important write path
Identify database data and logs, uploads, application logs, temporary work and container storage. Associate each path with its real mount or volume. Include separate data disks and storage pools; a nearly empty root filesystem does not protect an application whose data volume is full.
2. Track usable space and growth
Monitor available bytes, percentage use and the rate of change. For relevant Linux filesystems, monitor available inodes as well. On Windows, include the actual volumes and applicable quotas. Choose warning periods based on the time needed to investigate or expand capacity, not just a fixed percentage.
3. Check alert coverage
Detect missing mounts and failed metric collection so an unmounted data path does not appear healthy by accident. Review thin-provisioned or container storage at the appropriate layer. When capacity is low, identify the owning workload and approved retention or expansion action before removing anything.
Check the result
- Every critical write path has monitored capacity and a responder who can identify its storage layer.
- A growth trend provides enough warning to perform the approved corrective action.
Troubleshooting
- The application says no space left but the main disk has room
- Check the actual target filesystem, inode availability, user/project quotas and underlying pool. Total server free space can hide a limit at another layer.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.