As a system maintainer, I would Nagios to monitor VHDX expansion to give an early predictor of disk space creep. Currently, the VHDX files do not have consistent names, shut down VMs, rename critical VHDs and restart. Thinking about this, this is a background/opportunity based task which will probably require replication to be re-started (the names are also replicated so will need re-initializing). This however may be possible as replication may be stopped as part of support server maintenance/quiescing during this shutdown.
Acceptance Criteria
1) All critical instrument VHDs sizes show up in Nagios.
2) Nagios is able to alert if there is a rapid change in VHD size.
Notes
There may be a cunning way to furnish this information from WMI (VMs can be queried to ordinally list their disks). i.e. disk 0, 1,2 have these sizes (without name being needed?).
There are more complex relationships to existing physical space etc. which may not be wise (or possible) to calculate in Nagios.
As a system maintainer, I would Nagios to monitor VHDX expansion to give an early predictor of disk space creep. Currently, the VHDX files do not have consistent names, shut down VMs, rename critical VHDs and restart. Thinking about this, this is a background/opportunity based task which will probably require replication to be re-started (the names are also replicated so will need re-initializing). This however may be possible as replication may be stopped as part of support server maintenance/quiescing during this shutdown.
Acceptance Criteria 1) All critical instrument VHDs sizes show up in Nagios. 2) Nagios is able to alert if there is a rapid change in VHD size.
Notes