Now it is time to start building your own super metrics, and we can walk through the process of doing so. The first step in designing and building a super metric is to have a clear use case or problem that you are trying to solve. In our example, an administrator is keen to know if CPU Ready % (or CPU contention) is increasing on all VMs in a cluster as the amount of provisioned VMs increases. Because the administrator wants to know the maximum value of a metric that is present on all virtual machines, a Rollup super metric is the most appropriate.

When creating Rollup super metrics, understanding parent/child relationships is critical as it helps determines the depth of the looping algorithm that is being defined. The parent/child relationships can be seen in some dashboards, the Environment tab of an object, and in the Object Relationships section under Administration. An example of these relationships is shown in the following screenshot:

In our example, the Administrator has DRS set to Fully Automatic, so they are most interested in seeing if the maximum CPU ready across the VMs is increasing at the cluster level rather than the host level. For the super metric to apply correctly, the administrator needs to set the depth to a value of 2.

A VM with a single vCPU is assumed to be the norm if the CPU Ready time is below 5%. Usually, VM's with more vCPU's have higher CPU Ready. As a general guidance on a VM with four vCPUs, the CPU Ready should be below 10%, or 2.5 per vCPU.