So this next post is to expand on Sunny Dua‘s “Automatically place ESXi hosts in maintenance in vROps using properties” blog post.

I have been using a similar method in my own environment for some time but with a slight twist…. For example I also wanted to include some Parent and Children ResourceKinds to block alerts from….

Why would I want to do this you ask? Well anyone that manages a vSAN environment knows how noisy the vRops Alerts can be from the related ResourceKind’s…. IE: vSAN Cluster, vSan Disk Group, vSAN Cache Disk, vSAN Capacity Disk… etc when working on a single host in the cluster.

This helps suppress alerts on related objects automatically within vRops… and the great thing is…. vRops will continue collecting data where possible while performing maintenance.

How can it be done?? well we use supermetrics silly!!

So I have 2 separate super metrics for child objects (depth) or a combined one… and another for parent objects

Child ResourceKind’s: (Disk Group)

Count(${adaptertype=VMWARE, objecttype=Hostsystem, depth=-1, attribute=runtime|maintenanceState, where = "!contains notInMaintenance"})

Child ResourceKind’s: (Capacity & Cache disks)

Count(${adaptertype=VMWARE, objecttype=Hostsystem, depth=-2, attribute=runtime|maintenanceState, where = "!contains notInMaintenance"})

Combined Resource Kind’s: (DiskGroup, Capacity and Cache disks)

Count(${adaptertype=VMWARE, objecttype=Hostsystem, depth=-2, attribute=runtime|maintenanceState, where = "!contains notInMaintenance"}) || Count(${adaptertype=VMWARE, objecttype=Hostsystem, depth=-1, attribute=runtime|maintenanceState, where = "!contains notInMaintenance"})

Parent ResourceKind’s: (vSAN Cluster)

Count(${adaptertype=VMWARE, objecttype=Hostsystem, depth=1, attribute=runtime|maintenanceState, where = "!contains notInMaintenance"})

Enable the super metric’s in your “BlackOut” policy:

Create a custom group, link it to your BlackOut Policy, specify the criteria…

Preview the group, woohoo..

Hope this was helpful

vMan