14.1 Metrics, Properties & Logs

Match the Question to the Data

Operations analysis begins by distinguishing metrics, properties and logs. A metric measures an object's behavior over time, a property describes its configuration or identity, and a log records an event/message. These categories are determined by the field's meaning and collection model, not whether the displayed value contains digits or which undocumented internal database supposedly stores it.

CPU demand in MHz, storage IOPS and read latency are metrics. A VM's name, hardware compatibility and guest OS are properties. A time-stamped message that a storage path failed is a log/event. A property can change, and a metric can remain constant: a constant value is not automatically a property. Use the integration's actual field definition when a concept such as configured CPU count is exposed in more than one form.

Read Units and Time Windows

A metric is incomplete without its object, unit, interval and aggregation. A host CPU percentage, a per-vCPU ready percentage and a cluster aggregate do not describe the same denominator. A displayed average can hide a short severe spike. A cumulative counter needs an interval/rate interpretation, while a gauge represents a sampled condition.

For example, suppose a VM generated 24,000 I/O operations over 120 seconds. Its average is 200 IOPS for that interval. That result does not mean each second contained exactly 200 operations. Similarly, averaging five-minute samples over a day does not reveal a ten-second application timeout. Select a time resolution appropriate to the question and correlate with more detailed evidence where needed.

Verify that a latency value is in milliseconds rather than microseconds and that a capacity field is allocated, consumed or remaining. A 500-GB configured disk can have much less current data, while snapshots and replicas can increase physical use. Different measurements can all be correct because they describe different layers.

Distinguish Missing from Zero

A zero-valued measurement indicates an observed value of zero under that metric's definition. A missing point may indicate a powered-off object, unsupported metric, disabled collection, failed adapter, filtering or a collection interval with no observation. Replacing missing values with zero can make an outage look like an idle healthy workload.

Check adapter state and timestamps, then compare the same object over a wider interval. If a VM was renamed, identify it by the stable object relationship/identifier rather than assuming two similar display names are one machine. If the object was recreated, its new history may not continue the old object's series.

Use Properties for Scope

Properties and tags help define custom groups and view filters. A group of production database VMs should have a membership rule that matches the actual metadata convention. Preview membership, test both an included and excluded VM, and check how quickly changes are discovered. A misspelled property or stale tag can assign the wrong monitoring policy without any CPU fault.

Do not put secrets in tags or descriptive properties that broad monitoring roles can read. Shared reports and dashboards can expose object names, IPs and configuration metadata even when they contain no log payload. Scope the audience and exported fields accordingly.

Correlate Logs with Measurements

A spike in storage latency establishes a symptom, while path-failure logs can explain its timing and context. Select the same absolute time window, timezone and source identity in Operations and Logs. Compare the first failure event with downstream retries; the most frequent message is not necessarily the initiating cause.

Log ingestion time and the event's original source timestamp can differ. Delayed forwarding, clock drift and retention limits can create apparent disagreement. Check those conditions before concluding that a log event caused a metric spike. A temporal correlation supports investigation but is not proof of causation.

Worked Triage

A dashboard shows no CPU graph for a newly deployed VM. First verify that the VM exists in the selected vCenter account and is powered on. Check its collection timestamp, requested metric and current time window. A property-only inventory record can appear before metric history arrives. Next check effective policy collection and collector health. Only after establishing live data should you interpret utilization or recommend rightsizing.

For field definitions and supported integration objects, use the VCF Operations Integration SDK introduction. The practical skill is choosing evidence with the right semantics, then explaining its limits before making a configuration change.

Review Takeaways

• Metrics measure behavior over time; properties describe objects; logs record messages/events.
• Numerical appearance and frequency of change do not alone determine the category.
• Every metric needs an object, unit, interval and aggregation context.
• Missing data is not zero, and correlated timestamps alone do not prove causation.