A Super Metric earns its keep when something uses it. Over the last four parts we built a small set of KPIs: memory in GB, the worst CPU ready in a cluster, the powered-on vCPU to pCore ratio, an idle VM count, a CPU status code and a host balance index. In this final part …

After Part 3 you can build almost any formula: single-object math, aggregation across the hierarchy, filters and status codes. But there is a difference between a formula that works in Preview and a KPI you can run in production for years, across thousands of objects, and hand over to a colleague. This part is about …

At the end of Part 2 I left you with a flawed formula. Our vCPU to pCore ratio summed the vCPUs of every VM in the cluster, including the ones that have been powered off for months. A customer looking at that number would see an overcommitment that doesn’t exist. So far, a resource entry …

In Part 1 we took a Super Metric formula apart: resource entries, this, metric keys and depth. Every example worked on a single object. That is useful for unit conversions, but the real value of Super Metrics starts when one object asks many objects a question. VCF Operations already answers many cluster questions out of …

VMware VCF Operations collects thousands of metrics out of the box, and for most day-to-day questions they are all you need. Sooner or later, though, every environment has questions the built-in metrics weren’t designed to answer. A KPI that combines metrics from different objects or even different adapters. A value calculated for a scope that …