TL;DR · Key Takeaways
- A super metric is a formula that combines metrics across one or more objects. Its main use is rolling child values up to a parent, like summing every VM’s vCPU to a cluster total.
- Looping functions such as sum, avg, max, min and count work across many objects. Single functions work on one value or pair. Most useful super metrics start with a looping function over a group’s members.
- A custom group is static (a fixed list) or dynamic (a membership rule). Pair a super metric with a dynamic group and the rollup maintains itself as objects come and go.
- On one tenant, a dynamic group tracked growth from 40 to 52 VMs while a static group stayed frozen at 40 and under-reported by a quarter.
- Super metrics cost compute every collection cycle. Ten of them cost about 20 ms per cycle, a hundred cost around 240 ms. Build what you need and delete duplicates of built-ins.
- Keep formulas readable. A nested ternary nobody else can maintain is tech debt with a nice name.
Super metrics are the feature people either ignore or overuse, rarely the middle. Ignored, and you are stuck with per-object metrics when the question is about a group. Overused, and you have thirty formulas, half of them duplicating a built-in, quietly taxing every collection cycle. The right amount is small and deliberate.
This part answers a plain question: when do you actually need a super metric, and how do custom groups make it maintain itself? I will build one real rollup end to end, show what it costs to run, and give you the line I use to decide whether a formula earns its place.
What a super metric actually is
A super metric is a mathematical formula built from one or more metrics across one or more objects. The everyday case is a rollup: you have a metric on each child, and you want the total, average or worst value on the parent. VCF Operations gives you two kinds of function to do it. Looping functions, like sum, average, max, min and count, walk across many objects and return one number. Single functions work on a single value or a pair. Nearly every useful super metric I build starts with a looping function over the members of a group, then does a little arithmetic on the result.
You write the formula in the Super Metrics tab, where the editor autocompletes functions, object types, metrics and properties as you type, so you are picking real names rather than guessing at them. Then you assign the super metric to an object type and, this is the step people miss, enable it in the policy that governs those objects. A super metric that is defined but not enabled in policy collects nothing and leaves you staring at an empty chart.
| Looping function | What it returns | Reach for it when |
|---|---|---|
| sum | Total across members | Provisioned vCPU, memory or storage for a group |
| average | Mean across members | Typical utilization of a fleet |
| max | Worst single member | The hottest VM in a group, for an alert |
| min | Best or lowest member | Spotting a stalled or idle outlier |
| count | How many members | Density and membership over time |
Single functions and plain arithmetic
Not every super metric loops. Single functions and ordinary operators handle the cases where you already have a value and just need to reshape it. A single function might take one metric and one number, or a pair of metrics on the same object, and return a result. The tenant ratio is exactly this once the looping sum has run: take the group total and divide by the physical core count, which is plain arithmetic on two numbers. I think of it as two stages, a looping function to collapse many members into one number, then single functions and operators to turn that number into the thing I actually want to see. Keeping those stages separate in my head is what stops formulas from turning into unreadable one-liners.
Custom groups: static or dynamic
A super metric needs something to loop over, and that something is usually a custom group. You build a group two ways. A static group is a fixed list you add objects to by hand. A dynamic group has a membership rule, a tag, a naming pattern, a property, and it recalculates who belongs whenever objects change. The policy attached to the group is what actually applies its thresholds, metrics, super metrics and alerts to the members, so the group and the policy work as a pair.
My default is dynamic, and it is not close. A static group is right for a small, deliberately fixed set, a named list of golden VMs you never want changing silently. For anything that grows, a static group is a slow lie. It looks correct the day you build it and drifts out of true as the environment moves. The chart below is a tenant that grew from 40 to 52 VMs over four weeks. The dynamic group tracked every addition. The static one sat at 40 and under-reported the tenant by a quarter, which is the sort of error that makes a capacity number worthless.
Custom properties are the glue
Dynamic groups are only as good as the thing they match on, and the built-in properties do not always carry what your organization cares about. Custom properties fix that. A custom property is metadata you attach to objects yourself, an owner, a tier, a cost center, an application name, which then becomes something a dynamic group rule can match. Set a tenant property on every VM and your dynamic group rule becomes trivial and accurate. Skip it and you are matching on brittle naming conventions that break the first time someone names a VM off-pattern.
The three features work as a chain. Custom properties describe objects, dynamic groups gather objects by those descriptions, and super metrics compute across the gathered set. Get the properties right and the rest falls into place, because membership is driven by real metadata instead of a guess. Get them wrong and every group downstream inherits the error. I spend more time getting properties clean than writing formulas, and it pays back every time the environment changes.
A worked rollup
Here is the one I build most often: tenant oversubscription. I make a dynamic group whose rule is the tenant tag, so it currently holds 52 VMs and will hold more tomorrow without my help. Then a super metric sums provisioned vCPU across the group, which comes to 208 vCPU. I divide that by the 48 physical cores in the cluster serving the tenant, and the super metric reads 4.33 to 1. My comfort line for this workload class is 4 to 1, so the number is telling me the tenant has crept past where I want it. None of that is visible on any single VM. It only exists at the group level, which is exactly what super metrics are for.
Plot that ratio over a day and the story sharpens. It sits near 2 to 1 first thing, climbs through the morning, and peaks at 4.8 to 1 in the early afternoon before easing off. The average would have hidden the peak. The super metric plus a Trend view shows me the window where the tenant is actually overcommitted.
Groups nest, and that is worth using. I keep a dynamic group per tenant and a parent group that gathers all tenants, so the same super metric definition gives me a per-tenant ratio and a site-wide one without rewriting anything. When a new tenant is onboarded with the right custom property, it appears in its own group and rolls into the parent automatically. No formula changes, no manual membership edits, just the number staying correct as the environment grows. That self-maintaining quality is the whole reason to pair super metrics with dynamic groups rather than hand-built lists.
A conditional with the ternary operator
The formula editor supports a ternary operator, which lets a super metric return one value or another based on a condition. I use it to turn a messy number into a clean flag. For the tenant ratio, a super metric of the form ratio greater than 4 returns 1, otherwise 0, gives me a 0 or 1 signal I can alert on or colour a badge with, instead of asking every dashboard to re-evaluate the threshold. Resource entry aliasing lets you rewrite the objects a formula points at without retyping the whole expression, which keeps a group of similar super metrics consistent. Both are worth knowing. Neither is an excuse to nest three ternaries into a formula only you can read.
What super metrics cost to run
Every super metric is computed on every collection cycle, and cycles run on a five-minute cadence. That is cheap for a handful and not free for a hundred. The figures below are indicative, from watching compute time climb as super metric count grew on one node: ten cost around 20 milliseconds a cycle, fifty around 110, and a hundred around 240. That is not a reason to avoid them. It is a reason to avoid the twenty that duplicate a built-in metric you already collect. Before you write a formula, check whether the number already exists.
| Super metrics | Compute per cycle | Read |
|---|---|---|
| 10 | ~20 ms | Comfortable |
| 50 | ~110 ms | Fine if each earns its place |
| 100 | ~240 ms | Audit for duplicates of built-ins |
Where these numbers land
A super metric on its own is just a number. Its value comes from what consumes it. The tenant ratio I built feeds three things at once. It drives a badge on the group so an operator sees the tenant go amber without reading a chart. It backs an alert through the ternary flag, so the on-call is told when the ratio crosses 4 to 1 rather than discovering it later. And it lands in a Trend view on the capacity board from the dashboards part of this series, where it sits next to demand and allocation and makes the overcommit conversation concrete.
That is the pattern worth internalizing. Custom properties, dynamic groups and super metrics are plumbing. They exist to feed the dashboards, alerts and capacity work I covered earlier. When you build a super metric, know which of those it serves before you write the formula, because a number with no consumer is the kind of clutter that shows up in the next audit. If the answer is that it feeds a capacity decision, it has earned its place. If the answer is that it seemed useful once, it has not.
Common questions
My super metric shows no data. Why?
Almost always because it is defined but not enabled in the policy for that object type. Assigning it to an object type is not enough. Enable it in policy, then wait a cycle.
Static or dynamic group?
Dynamic for anything that grows, which is most things. Static only for a small set you deliberately want frozen. A static group of a moving population under-reports the moment something is added.
Do super metrics slow the system down?
A little, and it scales with count because each is computed every five-minute cycle. Ten are trivial, a hundred are measurable. The waste is the ones that duplicate built-ins, so audit for those first.
When should I use the ternary operator?
To turn a threshold into a clean 0 or 1 flag you can alert on or badge with. Keep it to one condition. If you are nesting ternaries, split the logic into simpler metrics instead.
Can I move super metrics between environments?
Yes. Package them with the dashboards and groups that use them into a management pack so the whole picture travels together rather than being rebuilt by hand.
« Previous: Part 12 | VCF 9 Operations Complete Guide | Next: Part 14 »
References
- VCF Operations: Configuring Super Metrics
- VCF Operations: Super Metric Functions and Operators
- VCF Operations: Managing Custom Object Groups
About The Author
DrJha