VMware monitoring for vSphere, vCenter, ESXi and VMs
Monitor ESXi hosts, clusters, virtual machines and datastores through vCenter, catch CPU ready time, ballooning and storage latency early, and see which applications are affected.
Why monitor VMware vSphere with Obseria
One connection to vCenter
A single read-only vCenter account covers every datacenter, cluster, ESXi host, VM and datastore it manages.
Virtualization-aware signals
Track CPU ready time, memory ballooning and swapping, which guest metrics alone cannot show.
From VM to application
Combine vSphere data with the Obseria Agent inside the guest and OpenTelemetry traces, so a datastore issue leads to the services it slows down.
VMware components Obseria monitors
- vCenter Server. Inventory of datacenters, clusters, hosts, VMs and resource pools with their relationships.
- ESXi hosts. CPU, memory, network and disk usage and latency per host.
- Clusters and resource pools. Host and VM counts, aggregated CPU and memory, and resource pool usage.
- Virtual machines. CPU usage and readiness, memory ballooning and swapping, disk latency and network throughput per VM.
- Datastores. Capacity, utilization and growth per datastore.
- Guest operating systems. Processes, logs and services inside Windows and Linux VMs with the Obseria Agent.
The VMware vSphere signals that matter
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.Host capacity
Shows how much processing power and memory your physical hosts are using and how many hosts are available.
Virtual machine wait times
Tells you when virtual machines are waiting for processing power, a common reason for applications feeling slow.
Memory pressure
Reveals when hosts run short of memory and start borrowing it from virtual machines, which noticeably slows them down.
Storage and network
Shows how quickly storage responds, how full it is and how much traffic each virtual machine generates.
Show all 9 metrics in detail
| Metric | Unit | What it tells you |
|---|---|---|
vcenter.host.cpu.utilization | % | CPU utilization of an ESXi host. |
vcenter.host.memory.utilization | % | Memory utilization of an ESXi host. |
vcenter.vm.cpu.readiness | % | Share of time a VM was ready to run but waited for a physical CPU. |
vcenter.vm.memory.ballooned | MiBy | Memory reclaimed from the VM by the balloon driver, a sign of host memory pressure. |
vcenter.vm.memory.swapped | MiBy | VM memory swapped to disk by the hypervisor; any value above zero hurts performance. |
vcenter.vm.disk.latency.avg | us | Average disk latency seen by the VM. |
vcenter.vm.network.throughput | By/s | Network throughput of the VM. |
vcenter.datastore.disk.utilization | % | Used share of datastore capacity. |
vcenter.cluster.host.count | {hosts} | Hosts in the cluster by power and effective state. |
Set up VMware vSphere monitoring in minutes
- Step 1
Create a read-only vCenter user
Create a vCenter user with the Read-only role, propagated to all child objects of the inventory you want to monitor.
- Step 2
Point the collector at vCenter
Configure the vcenter receiver in the OpenTelemetry Collector or the Obseria Agent with the vCenter endpoint and credentials.
- Step 3
Add guest and application data
Install the Obseria Agent inside important VMs and instrument the applications with OpenTelemetry for full context.
receivers:
vcenter:
endpoint: https://vcenter.example.internal
username: ${env:VCENTER_USER}
password: ${env:VCENTER_PASSWORD}
collection_interval: 1m
tls:
insecure_skip_verify: false
processors:
batch: {}
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [vcenter]
processors: [batch]
exporters: [otlphttp]Out of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- vSphere inventory and health overview
- ESXi host CPU and memory capacity
- VM CPU ready and ballooning alerts
- Datastore capacity forecast
- VM disk latency hot spots
VMware vSphere monitoring: what matters
Why VMware monitoring still matters
A large share of enterprise workloads runs on VMware vSphere: ERP systems, databases, middleware, Windows services and, increasingly, Kubernetes clusters on virtual machines. VMware monitoring answers a question that guest-level tools cannot: is the virtual machine slow because of its own workload, or because the hypervisor, the host or the datastore underneath is under pressure?
vCenter has its own performance charts, but they are disconnected from the applications. When a payment service slows down, the on-call engineer sees high latency in traces, not CPU ready time on an ESXi host. vSphere monitoring becomes valuable when it is linked to the services that run on top, so infrastructure and application teams look at the same picture.
The vSphere metrics that matter
Virtualization adds signals that do not exist on physical servers. Focus on these:
- CPU ready time:
vcenter.vm.cpu.readinessmeasures how long a VM waited for a physical CPU. High values mean the host is overcommitted, even if the guest shows moderate CPU. - Memory ballooning and swapping:
vcenter.vm.memory.balloonedandvcenter.vm.memory.swappedshow the hypervisor reclaiming memory. Ballooning is an early warning, swapping is a performance problem. - Host utilization:
vcenter.host.cpu.utilizationandvcenter.host.memory.utilizationper ESXi host and aggregated per cluster for capacity planning. - Storage latency:
vcenter.vm.disk.latency.avgper VM and datastore. Latency spikes hit databases first. - Datastore capacity:
vcenter.datastore.disk.utilizationand its growth. Snapshots and thin provisioning can fill datastores faster than expected.
Common VMware problems and how to detect them
CPU overcommitment. Too many vCPUs on a host lead to rising CPU ready time across many VMs at once. If several VMs on one host show high readiness while their guest CPU is moderate, rebalance with DRS or reduce vCPU counts on oversized VMs.
Memory pressure. When a host runs short of memory, ballooning starts, then compression and swapping. Alerts on ballooned memory give you time to act before swapping slows applications down.
Storage contention. A noisy VM, a backup job or a failing array can raise latency for every VM on a datastore. Comparing disk latency across VMs on the same datastore separates a single heavy consumer from a storage-wide problem.
Forgotten snapshots. Snapshots grow continuously and slow down disk I/O. Datastore utilization trends reveal the growth, and a forecast alerts before the datastore is full.
Host failures and HA events. When a host goes down, HA restarts its VMs elsewhere. The host count by state and the VM inventory changes show what moved and which applications were affected.
VMware monitoring best practices
- Monitor through vCenter with a read-only account rather than through each ESXi host individually.
- Alert on CPU ready time, ballooning and disk latency, not only on utilization.
- Right-size VMs regularly; oversized VMs with many vCPUs often suffer more from CPU scheduling than small ones.
- Track datastore growth and snapshot age as part of capacity planning.
- Link VMs to the applications they host so infrastructure alerts show business impact.
How Obseria monitors VMware
Obseria collects vSphere data through the vCenter API using the OpenTelemetry Collector's vCenter receiver or the Obseria Agent, with a single read-only account. Inside the guests, the Obseria Agent adds processes, services and logs, and OpenTelemetry SDKs add traces from the applications. Obseria TopoGraph links datastores, hosts, VMs and services, so Obseria Intelligence can follow a latency increase from a slow service down to the datastore or host that caused it, with a chain of evidence. Dashboards, alerts and SLOs are included, and data can be kept in the EU or in your own cloud account.
Many teams run VMware next to public cloud. Obseria shows vSphere, AWS, Azure and Google Cloud resources in the same inventory, so migrations can be planned with real utilization data and compared before and after the move.
Related integrations
Related capabilities
Network Monitoring
Follow traffic between hosts, containers, clouds and data centers. Obseria shows latency, loss and errors on the network path and which services and users they affect.
Learn moreAnomaly Detection
Obseria Intelligence learns the normal rhythm of every service, flags real deviations instead of threshold noise and groups related anomalies into one problem with a probable root cause.
Learn moreCloud Monitoring
Monitor 300+ cloud services agentless and see how they affect your applications. One platform for multi-cloud metrics, logs, traces and topology.
Learn moreLearn more
What is observability?
What is observability? Learn how metrics, logs, traces and profiles let you understand any system state, how it differs from monitoring, and how to start.
What is root cause analysis (RCA)?
What is root cause analysis? The RCA process for software incidents, 5 Whys, fishbone and fault tree methods, a worked example and how AI speeds up RCA.
VMware vSphere monitoring FAQ
Obseria reads metrics and inventory from the vCenter Server API, using the OpenTelemetry Collector's vCenter receiver or the Obseria Agent. One read-only vCenter account covers all managed hosts and VMs.
No. All hypervisor and VM metrics come from vCenter. The Obseria Agent is only needed inside guest VMs if you want process, log and application detail.
The built-in Read-only role, assigned to the monitoring user and propagated to the inventory objects you want to monitor, is sufficient.
Yes. VM CPU readiness, ballooned and swapped memory are collected per VM, and out-of-the-box alerts flag VMs and hosts under pressure.
Yes. Monitor the VMs through vCenter and the clusters with the Obseria Agent or OpenTelemetry Collector. TopoGraph links Kubernetes nodes to the VMs and hosts they run on.
Start monitoring VMware vSphere today
Connect VMware vSphere in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.