Ok, I scratched out some time to illustrate this process. Basically, here's the high-level:
- Create a super metric (or import the one I'll provide you here)
- Duplicate it N times to cover all possible volumes (drives) you might ever have on Windows.
- Turn all of them on in your policy.
- Create a test VM with all possible drive letters mounted (can be done at any stage; doesn't have to be here but must be before step 5).
- Create a symptom definition using these new supermetrics.
- Create an alert using the new symptom definition.
Here's the super metric configuration. Either re-create this manually or use the JSON I provide. Click individual images in the post to see them full sized if they appear cut off.
We're basically saying to take the capacity metric and subtract from it the usage metric on a per-volume basis. Call this "C GB remaining" or whatever you like. You'll need to duplicate this however many times to cover all possible volumes you might have mounted. Clone and edit the definition. Don't try and use the object and metric picker to find a VM, just edit the text. After saving them, set the object type to apply to VMs.
Next, go into your policy and activate them.
Only change the ones where Object Type is a VM. You can opt to use them for KPIs and DTs if you wish. Make sure in your policy to ensure it's applied to your licensing group or whatever subset of your infra.
Go back to the super metrics and ensure they are tied to a policy.
Let a couple collection cycles pass and check a VM to make sure the new super metric is collecting and is accurate.
Now create a new symptom based on them. This is the part that kind of sucks. In order to do this, you'll have to create a VM that has all drives possible. I'd suggest just creating a throw-away Windows VM like you see in the screenshot above, create a volume for every letter and carve out like a 1 GB drive or something. It doesn't matter, you just need the volume letters to be present so vROps can collect the metrics necessary. This is the only way you can expose those in the symptom definition as I'll show below.
When you go and create your symptom definition, you won't see those super metrics.
Click that button I've highlighted and select your test VM that has all those drives. Now you should see those super metrics.
Drag ALL of your super metrics onto the designer until they're stacked up. Fill out the forms to meet your config necessary. I did this.
Name it and save it. When you do, it creates not one but individual symptom definitions for each one. This saves time so you don't have to save and re-enter the symptom definition designer.
Now, go create an alert definition comprised of those.
Drag them into the same symptom box so they look like that. Don't add another condition. Make sure the match is Any. Select your base object type, impact, etc. Save it. Go back to the policy and make sure the alert is active. It should be because it is in the default policy and that's the parent policy. Double-check just to be sure. Use that test VM and fill up a drive. Check the alerts after enough collection cycles have elapsed and you should see your alert.
If you expand the non-triggered symptoms, this should prove that other drives are being watched independently but the alert doesn't have those as active.
Now you have an alert that works on remaining capacity rather than remaining percentage of drive space. Also keep in mind with super metrics that they don't apply retroactively--until you create that super metric and collects upon it, it doesn't exist in the system.