TL;DR · Key Takeaways
- Every dashboard, alert and capacity number is built from four things: objects, metrics, properties and relationships.
- Objects are the things such as hosts, VMs and datastores. Metrics are the numbers that change on the default 5-minute collection cycle.
- Properties are configuration strings. Mixing up a metric and a property is how you build an alert that can never fire.
- Relationships link an object to its neighbors and power the correlation you rely on in later troubleshooting.
- Treat collection as something you tune to what you will actually use, not something you max out.
You built an alert to catch hosts running an out-of-date BIOS, pointed it at what looked like the right field, set a threshold, and it never fired. Not once, through a quarter of patching. The field you picked was a property, a string, and you tried to alert on it as if it were a number that crosses a line. That single confusion, metric versus property, is behind a surprising share of alerts that look correct and do nothing.
So before dashboards and alerts, the data model. Get these four nouns straight and the rest of VCF Operations stops being a guessing game.
Objects: the nouns of your environment
An object is a structural component VCF Operations tracks: a virtual machine, a datastore, a virtual switch, a port group, a host, a cluster. Each object has a type (object type) and is collected through an adapter. VCF Operations discovers objects and their relationships automatically the moment you create an adapter instance, which is the connection to a data source such as a vCenter. You can also add objects by hand for things an adapter does not reach.
The number that matters here is count. A real fleet does not have dozens of objects, it has tens of thousands, and each one carries its own bundle of metrics and properties. That growth is the quiet driver of how large your single VCF Operations instance has to be, which is exactly why Part 1 told you to size it for the whole fleet. The data model is not academic. It is your capacity plan.
Metrics vs properties, and why alerts fail
VCF Operations groups what it collects into attribute types: metrics, properties and super metrics. The cleanest way to keep them straight: a metric is a number that changes over time, a property is a string that describes how the object is configured. CPU workload, memory usage, disk IOPS and latency are metrics. Guest OS, power state, hardware version and vCPU count are properties. There is a subtle vocabulary point worth knowing, because it shows up in the Management Pack Builder and the API: an attribute is the definition, the metadata describing what to collect, and a metric is an instance of that attribute on a specific object.
Why it matters operationally: you alert on them differently. A metric supports thresholds and dynamic thresholds, because there is a number to compare. A property does not trend, so you alert on it by existence or equality, is the value this or not this, not by crossing a line. The BIOS alert in the opener failed because version is a property. The fix is a property-based symptom that checks whether the string equals the approved value, not a threshold.
| Attribute | Data type | Example | How you alert on it |
|---|---|---|---|
| Metric | Number, time-series | CPU workload %, latency ms | Static or dynamic threshold |
| Property | String, configuration | Guest OS, hardware version | Existence or equality check |
| Super metric | Calculated number | Formula across objects | Threshold, like a metric |
Relationships, and why one problem spreads
Relationships are the part people skip and then wonder why root-cause analysis feels blind. Objects are related physically (a VM runs on a host), logically (all storage in a silo) or structurally (the VMs that support one database). Most relationships form automatically as the adapter discovers objects, building the classic parent-child tree: vCenter to datacenter to cluster to host to VM, with datastores hanging off the side. When objects are related, a problem on one shows up as an anomaly on the others. That propagation is the entire mechanism behind fast troubleshooting. Pull the relationships away and every object is an island.
Custom groups and applications
Beyond the discovered tree you can build your own. Custom groups organize objects by rules: a dynamic group of every powered-on Linux VM, for instance, automatically picks up the next Linux VM you boot and applies the right policy to it. Applications go further, wrapping a set of objects across tiers (web, app, database) into a single object whose health rolls up from its children. This is how you stop monitoring 40 VMs and start monitoring one service. It is also where you apply different alerting and capacity rules to production versus test, by grouping and assigning policy rather than touching objects one by one.
How an attribute becomes an alert
The data model only earns its keep when it turns into an alert. The chain is short. An adapter collects a metric or property for an object. A policy decides, per object type, which attributes are even collected, which are flagged as KPIs, and which carry a dynamic threshold. A symptom defines the condition (a metric above a threshold, a property not equal to the approved value). An alert definition bundles symptoms into something that fires and, ideally, recommends an action. Flag an attribute as a KPI and a violation generates an alert and surfaces it in dashboards.
This is where I take a side. The default instinct is to collect everything and flag generously. Resist it. Every activated KPI is an evaluation against every matching object on every collection cycle, and every loose dynamic threshold is a future false positive. I would rather run a tight set of KPIs that map to real operational pain than a wall of green badges nobody trusts. Coverage is not the goal. Signal is.
Where the data model lives in the UI
Vocabulary sticks faster once you can find it on screen. In VCF Operations the data model surfaces in a few consistent places, and knowing the route saves you from clicking blind during an incident.
Inventory is where objects live
Open an object under Inventory and you see its detail tabs, including a Metrics tab where the collected metrics and properties for that object appear. This is the fastest way to confirm what is actually being gathered for, say, a specific host, rather than assuming the default policy did what you expected. If a metric you wanted is not here, the answer is upstream in policy, not in the object.
Configurations is where the rules live
From the left menu, Infrastructure Operations then Configurations gives you the tiles that govern the model: a Policy Definition tile where you choose, per object type, which attributes are collected and which are flagged as KPI or carry a dynamic threshold, and a Symptom Definitions tile where you write the metric, property and super metric conditions that feed alerts. The mental map is clean: Inventory shows you what an object has, Configurations decides what the platform does with it. When an alert misbehaves, you start in Symptom Definitions and Policy Definition, not in the dashboard that displayed it.
One practical habit: when you edit metric collection, you can do it from the policy workspace or directly from the Metrics tab under Inventory by editing the metrics collection for that object. Pick the policy route for anything that should apply broadly, and reserve the per-object route for genuine exceptions. Editing one object when you meant to change a class of objects is how drift creeps into a model that is supposed to be consistent across the fleet.
Worked example: why collect everything costs you twice
The data model has a price, and the multiplication makes it concrete.
Take 500 VMs and 24 hosts. A single VM exposes hundreds of metrics; a host exposes more. Say you settle on a modest 20 KPI attributes for VMs. That is 500 times 20, or 10,000 KPI evaluations every collection cycle, from VMs alone, before you add hosts, datastores and clusters. Now picture the alternative that feels safer: flag 80 attributes as KPI because you might want them. You did not get four times the insight. You got four times the evaluations, four times the dynamic-threshold surface that can misfire, and a console where real problems hide behind badges. The first cost is storage and compute on your single Operations instance. The second cost, the expensive one, is the operator who stops trusting the alerts. Collect with intent.
Quick questions, honest answers
What is the actual difference between a metric and a property?
A metric is a number that changes over time, so you can trend it and set thresholds. A property is a string describing configuration, so it does not trend and you check it by equality or existence. If you find yourself trying to set a numeric threshold on something that never moves, it is probably a property.
Do I have to configure relationships myself?
Mostly no. VCF Operations builds parent-child relationships automatically when an adapter discovers objects. You only add relationships or custom groups when you want connections the discovery does not make, such as grouping objects by business service or environment.
What is a super metric and do I need one now?
A super metric is a calculated value, a formula across one or more metrics or objects, that behaves like a metric once defined. It is useful for roll-ups, but you do not need it to start. This series covers super metrics in depth in a later part.
Why are my dynamic thresholds noisy right after deployment?
They have no baseline yet. Dynamic thresholds learn each object’s normal range from collected history, so until enough cycles have passed they can fire on ordinary variation. Give them time before you let them drive alerts.
What is an adapter instance?
It is the configured connection to a data source, such as a vCenter, that lets VCF Operations discover and collect from that source. Creating it is what populates objects, metrics and relationships in the first place.
Where this leads
Hold onto one sentence: objects carry metrics and properties, relationships connect them, and policies decide what becomes an alert. My verdict for this part is the same as my verdict for collection in general, be deliberate. The administrators who get value from VCF Operations are not the ones who turned everything on. They are the ones who can explain, for any number on the screen, what it is and why it is being watched.
Next we get hands-on: deploying VCF Operations and connecting it to your first data sources, which is where these objects and relationships actually appear.
By the numbers: what KPI sprawl costs every cycle
The same 500 VMs, evaluated on the default 5-minute cycle, at two levels of discipline.
| Choice | KPI attributes per VM | VMs | Evaluations per cycle |
|---|---|---|---|
| Disciplined | 20 | 500 | 10,000 |
| Flag everything | 80 | 500 | 40,000 |
« Previous: Part 1 | VCF 9 Operations Complete Guide | Next: Part 3 »
References
- About Objects, VCF 9.0 Infrastructure Operations (Broadcom TechDocs)
- Metrics and Properties Details, VCF 9.0 (Broadcom TechDocs)
- Configuring Object Relationships, VCF 9.0 (Broadcom TechDocs)
About The Author
DrJha