VMware vSphere Monitoring with OpenTelemetry Collector on Windows

VMware vSphere monitoring with OpenTelemetry means running the OpenTelemetry Collector Contrib distribution with the vcenter receiver, which polls the vSphere SDK for datacenter, cluster, host, VM, datastore, and vSAN metrics and exports them over OTLP. No vendor agent goes on your ESXi hosts, and no software gets installed on the vCenter appliance.

This guide walks the whole path on a Windows host: preparing vCenter, installing the collector, writing the config, running it as a service, adding ESXi syslog, and validating that data actually landed in OpenObserve. It also covers the one configuration mistake that catches almost everyone the first time, where the inventory shows up perfectly and the Metrics explorer stays stubbornly empty.

Key takeaways

• The vcenter receiver ships only in the Contrib collector build, and it polls vCenter over HTTPS 443 with a read-only account.
• Missing disk latency or throughput series is nearly always a vCenter statistics level problem, not a collector problem.
• Use two separate otlphttp exporters: metrics with no stream-name header, logs with one. Sharing a single exporter is what collapses every metric into one stream.
• The collector's own telemetry on port 8888 tells you which half of the pipeline to blame before you go hunting in the UI.

How does the vcenter receiver collect VMware metrics?

A few things worth knowing before you touch any config:

• The vcenter receiver is a poll-based scraper. It authenticates to the vSphere SDK endpoint at https://<vcenter>/sdk and pulls metrics for datacenters, clusters, hosts, resource pools, VMs, datastores, and vSAN on an interval you choose.
• The collector runs anywhere with network reach to vCenter over 443. It does not need to run on the vCenter appliance. A Windows VM or jump host is fine.
• Metrics leave the collector through the otlphttp exporter pointed at the OpenObserve OTLP HTTP ingestion endpoint, with Basic auth.
• Metrics and logs use two separate exporter definitions pointed at the same endpoint. The only difference between them is whether the stream-name header is present. That detail matters more than it looks, and it gets its own section below.
• ESXi syslog is optional and completely independent of the metrics path.

If you have not worked with the collector before, the OpenTelemetry Collector glossary entry covers the receiver, processor, exporter model this config is built on.

What you need before you start

Preparing vCenter

Create a read-only monitoring user

1. In the vSphere Client, go to Administration > Single Sign On > Users and Groups.
2. Create a user, for example otel-monitor@vsphere.local, with a strong password.
3. Go to Administration > Access Control > Global Permissions, or the root vCenter object then Permissions.
4. Add the user with the built-in Read-only role and check Propagate to children.

The receiver only reads inventory and performance data. It never needs write, console, or datastore browse permissions, so there is no reason to grant them.

Check your performance counter statistics levels

Several metrics depend on vCenter statistics levels, found under Administration > vCenter Server Settings > Statistics, or Configure > General > Statistics on the vCenter object:

If disk latency or throughput series are missing in OpenObserve, this is almost always why. Raise the level on the shortest interval (5 minutes) only. Raising every interval bloats the vCenter statistics database and buys you nothing.

Two related gotchas worth checking at the same time:

• Powered-off VMs emit no performance counters. Inventory metrics such as vcenter.datacenter.vm.count still include them, but CPU, memory, disk, and network series will not exist for them.
• Hosts in maintenance mode or in a disconnected state drop out of performance collection while staying in the inventory. If a whole cluster looks like names without numbers, check host connection state first.

TLS

By default the receiver rejects self-signed vCenter certificates. Your options, best first:

1. Use a vCenter with a CA-signed certificate, in which case there is nothing to configure.
2. Export the vCenter CA certificate and reference it with tls.ca_file.
3. Set tls.insecure_skip_verify: true. Acceptable for a proof of concept, avoid it in production.

Installing the OpenTelemetry Collector Contrib on Windows

The vcenter receiver ships only in the Contrib distribution. The core otelcol build does not include it.

Download

Grab the latest Windows amd64 release from the collector releases page. In PowerShell, running as Administrator:

# Pin the version you want, and check the releases page for the current one
$version = "0.135.0"

New-Item -ItemType Directory -Force -Path "C:\otelcol" | Out-Null

Invoke-WebRequest `
  -Uri "https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v$version/otelcol-contrib_${version}_windows_amd64.tar.gz" `
  -OutFile "C:\otelcol\otelcol-contrib.tar.gz"

tar -xzf C:\otelcol\otelcol-contrib.tar.gz -C C:\otelcol

You should now have C:\otelcol\otelcol-contrib.exe.

Releases also publish an MSI (otelcol-contrib_<version>_windows_x64.msi) that installs the binary and registers a Windows service named otelcol-contrib in one step:

msiexec /i "otelcol-contrib_0.135.0_windows_x64.msi" /qn COLLECTOR_SVC_ARGS='--config "C:\otelcol\config.yaml"'

Verify you got the right build

C:\otelcol\otelcol-contrib.exe components | Select-String "vcenter"

You should see vcenter listed under receivers. If nothing comes back, you downloaded the core distribution by mistake.

Directory layout used here

C:\otelcol\
  otelcol-contrib.exe
  config.yaml
  logs\            (optional, the collector's own file logs)

Finding your OpenObserve endpoint and credentials

In OpenObserve, go to Data Sources (Ingestion) > Custom > Metrics > OTLP HTTP, or the Traces and Logs tabs for their endpoints. The UI shows a ready-made endpoint plus an Authorization: Basic <base64> header value for your organization. Copy both. They are exactly what the collector needs.

Endpoint patterns

The otlphttp exporter appends /v1/metrics, /v1/logs, and /v1/traces to the base endpoint on its own, so configure only the base path shown above. Appending the signal path yourself is a common source of 404s.

One warning about localhost. Use http://localhost:5080/api/default only when OpenObserve and the collector run on the same machine. If you browse the OpenObserve UI at localhost:5080 from your desktop but the collector runs on a different Windows host, the collector needs the real hostname or IP of the OpenObserve machine. The default organization on a fresh self-hosted install is default.

Building the Basic auth token by hand

The token is base64(email:ingestion_password):

$pair = "you@company.com:YOUR_INGESTION_TOKEN"
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($pair))

Use the resulting string as Basic <value> in the exporter headers.

The full collector config

Save this as C:\otelcol\config.yaml. It is a complete, production-oriented config: the vcenter receiver, a health check, memory protection, resource tagging, batching, retry and queueing on the exporter, and the collector's own telemetry.

Read the exporter section carefully. otlphttp/openobserve_metrics deliberately carries no stream-name header, which is what lets OpenObserve create one stream per metric name and populate the Metrics explorer normally. otlphttp/openobserve_logs carries the header and is used only by the logs pipeline further down. Do not add stream-name to the metrics exporter.

receivers:
  vcenter:
    endpoint: https://vcenter.yourcompany.local
    username: otel-monitor@vsphere.local
    password: ${env:VCENTER_PASSWORD}
    collection_interval: 2m
    initial_delay: 1s
    timeout: 90s
    tls:
      # Preferred: point at your vCenter CA bundle
      # ca_file: C:\otelcol\vcenter-ca.pem
      # Proof of concept only:
      insecure_skip_verify: true
    metrics:
      # Defaults are all on. Enable the optional extras below if you want them.
      vcenter.host.memory.capacity:
        enabled: true
      vcenter.vm.memory.granted:
        enabled: true
      vcenter.vm.cpu.time:
        enabled: true
      vcenter.vm.network.broadcast.packet.rate:
        enabled: true
      vcenter.vm.network.multicast.packet.rate:
        enabled: true

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 1024
    spike_limit_mib: 256

  resource:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert
      - key: service.name
        value: vmware-vcenter
        action: upsert
      - key: vcenter.instance
        value: vcenter.yourcompany.local
        action: upsert

  batch:
    send_batch_size: 8192
    send_batch_max_size: 16384
    timeout: 10s

exporters:
  # METRICS. No stream-name header. OpenObserve creates one stream per metric name.
  otlphttp/openobserve_metrics:
    endpoint: https://api.openobserve.ai/api/your_org_id
    # Self-hosted example:
    # endpoint: http://openobserve.internal:5080/api/default
    headers:
      Authorization: "Basic ${env:O2_AUTH_TOKEN}"
    compression: gzip
    timeout: 30s
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 60s
      max_elapsed_time: 10m
    sending_queue:
      enabled: true
      num_consumers: 4
      queue_size: 5000

  # LOGS ONLY. Used by the syslog pipeline below. Safe to delete if you are not
  # collecting ESXi logs.
  otlphttp/openobserve_logs:
    endpoint: https://api.openobserve.ai/api/your_org_id
    headers:
      Authorization: "Basic ${env:O2_AUTH_TOKEN}"
      stream-name: vmware
    compression: gzip
    timeout: 30s
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 60s
      max_elapsed_time: 10m
    sending_queue:
      enabled: true
      num_consumers: 4
      queue_size: 5000

  # Handy while validating, remove in production
  debug:
    verbosity: basic
    sampling_initial: 2
    sampling_thereafter: 100

extensions:
  health_check:
    endpoint: 127.0.0.1:13133

service:
  extensions: [health_check]
  pipelines:
    metrics/vmware:
      receivers: [vcenter]
      processors: [memory_limiter, resource, batch]
      exporters: [otlphttp/openobserve_metrics]
  telemetry:
    logs:
      level: info
    metrics:
      level: basic
      readers:
        - pull:
            exporter:
              prometheus:
                host: 127.0.0.1
                port: 8888

A few notes on the choices above:

• collection_interval: 2m is a sane default. For very large vCenters with thousands of VMs, start at 5m and confirm scrapes finish inside the interval.
• ${env:...} substitution keeps secrets out of the file. Set them as machine-level environment variables so the service account can read them.
• The stream-name header names the target logs stream. Leaving it off the metrics exporter is intentional and required.
• Do not leave both debug and a production exporter on the same pipeline long term. The debug exporter is chatty.

Running the collector as a Windows service

Set secrets as machine environment variables

Run this in an elevated PowerShell so the service account can see them:

[System.Environment]::SetEnvironmentVariable("VCENTER_PASSWORD", "YourVCenterPassword", "Machine")
[System.Environment]::SetEnvironmentVariable("O2_AUTH_TOKEN", "PASTE_YOUR_BASE64_TOKEN_HERE", "Machine")

O2_AUTH_TOKEN holds only the base64 part. The config prefixes it with Basic .

Test run in the foreground first

Before creating the service, always dry-run:

$env:VCENTER_PASSWORD = "YourVCenterPassword"
$env:O2_AUTH_TOKEN = "PASTE_YOUR_BASE64_TOKEN_HERE"
C:\otelcol\otelcol-contrib.exe --config C:\otelcol\config.yaml

A healthy startup ends with Everything is ready. Begin running and processing data. The first vcenter scrape fires after initial_delay plus connection setup, so expect the first metric batch within one collection interval.

Create the service

New-Service -Name "otelcol-contrib" `
  -DisplayName "OpenTelemetry Collector Contrib" `
  -Description "Collects VMware vCenter metrics and ships to OpenObserve" `
  -BinaryPathName '"C:\otelcol\otelcol-contrib.exe" --config "C:\otelcol\config.yaml"' `
  -StartupType Automatic

Start-Service otelcol-contrib
Get-Service otelcol-contrib

If you installed via the MSI the service already exists, so just edit config.yaml and restart:

Restart-Service otelcol-contrib

Auto-restart on crash

sc.exe failure otelcol-contrib reset= 86400 actions= restart/5000/restart/10000/restart/30000

Where the collector's own logs go

Running as a service, the collector writes to the Windows Event Log, in the Application log under source otelcol-contrib:

Get-WinEvent -ProviderName "otelcol-contrib" -MaxEvents 50 | Format-List TimeCreated, Message

Firewall

Only needed if you enable the syslog receiver:

New-NetFirewallRule -DisplayName "OTel Syslog UDP 514" -Direction Inbound -Protocol UDP -LocalPort 514 -Action Allow

This is the same service pattern used for Windows host and event log monitoring, so if you already run a collector for Windows telemetry you can fold the vcenter receiver into that config instead of standing up a second one.

Optional: sending ESXi syslog to OpenObserve

The vcenter receiver is metrics only. For ESXi host logs, point each host's remote syslog at the same collector and add a logs pipeline.

Configure the ESXi hosts

On each host, under Host > Configure > System > Advanced System Settings:

• Syslog.global.logHost = udp://<windows-collector-ip>:514

Then open the syslog firewall rule on the host under Configure > Firewall > Edit, or via esxcli:

esxcli system syslog config set --loghost='udp://<collector-ip>:514'
esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true
esxcli system syslog reload

Add the pipeline to the collector

Note that this pipeline uses otlphttp/openobserve_logs, the exporter that carries the stream-name header. The metrics pipeline is unchanged and keeps using otlphttp/openobserve_metrics.

receivers:
  syslog:
    udp:
      listen_address: "0.0.0.0:514"
    protocol: rfc3164
    location: UTC
    operators:
      - type: add
        field: attributes.source
        value: esxi-syslog

service:
  pipelines:
    metrics/vmware:
      receivers: [vcenter]
      processors: [memory_limiter, resource, batch]
      exporters: [otlphttp/openobserve_metrics]

    logs/esxi:
      receivers: [syslog]
      processors: [memory_limiter, resource, batch]
      exporters: [otlphttp/openobserve_logs]

Logs land in OpenObserve under the stream named by the stream-name header, in this case vmware. To split logs into multiple named streams, define additional otlphttp exporters with different stream-name values and assign one per pipeline.

Which VMware metrics does the vcenter receiver emit?

Units follow OpenTelemetry conventions: By bytes, MiBy mebibytes, MHz megahertz, % percent, ms milliseconds, us microseconds, {KiBy/s} kibibytes per second.

Datacenter metrics (on by default)

Cluster metrics (on by default)

Host (ESXi) metrics (on by default)

Virtual machine metrics (on by default)

vcenter.vm.cpu.readiness deserves special mention. It is the single best early signal of CPU contention on an overcommitted cluster, and it shows up long before guest-level CPU metrics look unhealthy.

Resource pool metrics (on by default)

Datastore metrics (on by default)

Optional metrics (off by default)

Enable any of these with:

receivers:
  vcenter:
    metrics:
      vcenter.host.memory.capacity:
        enabled: true

Disable any default metric the same way with enabled: false. That is the main lever for cutting cardinality on the object-attributed disk and network series in large fleets.

Resource attributes

Every series carries resource attributes identifying its scope. These become labels and dimensions in OpenObserve.

On top of those you get whatever you upsert in the resource processor, which in the config above is service.name, deployment.environment, and vcenter.instance.

One naming detail that trips people up in queries: in OpenObserve, dots in attribute names are normalized to underscores. Query them as vcenter_vm_name and vcenter_host_name, not vcenter.vm.name.

How do you validate that metrics are actually arriving?

Work through these in order. The first three confirm the collector is healthy. The rest confirm OpenObserve is storing and displaying the data.

Collector side

1. Watch the foreground run, or the Event Log. Lines like Exporting failed are bad. Silence after startup is good, because the otlphttp exporter says nothing on success. The debug exporter prints Metrics {"resource metrics": N, "metrics": M, "data points": K} per batch.

2. Hit the health check endpoint.

Invoke-WebRequest http://127.0.0.1:13133/ | Select-Object StatusCode

3. Read the collector's own self-metrics. This is the single most useful check in the whole guide, because it sits upstream of OpenObserve and tells you which half of the pipeline to blame.

(Invoke-WebRequest http://127.0.0.1:8888/metrics).Content |
  Select-String "otelcol_receiver_accepted_metric_points|otelcol_exporter_sent_metric_points|otelcol_exporter_send_failed_metric_points|otelcol_scraper_errored_metric_points"

Run it twice, roughly two minutes apart, and compare:

Port 8888 is the collector's own telemetry endpoint, not OpenObserve. It is defined under service.telemetry.metrics in the config. Port 5080 is OpenObserve. If accepted and sent are both climbing and failed is flat at zero, the collector is doing its job and anything still missing is a display or routing problem in OpenObserve.

OpenObserve side

4. Check the Streams page, with the stream type filter set to metrics, not logs. You should see many streams, one per metric name: vcenter_host_cpu_usage, vcenter_vm_memory_utilization, and so on. OpenObserve converts OTLP metric names by replacing dots with underscores.

If instead you see a single stream, often named vmware, containing fields like vcenter_host_name and vcenter_cluster_name, your metrics are being written as one lumped stream. That is the stream-name header problem covered in the troubleshooting section below.

5. Query in the Metrics explorer, not the Logs view. Metrics and logs are separate areas of the UI. Browsing the Logs view will show you inventory attributes and never a metric chart. Set the time range to the last hour, then run:

vcenter_host_cpu_usage

6. Confirm with an aggregate.

topk(10, vcenter_vm_cpu_utilization)

Dashboards and queries worth building

PromQL examples for OpenObserve dashboard panels.

Capacity overview:

# Cluster CPU headroom (MHz)
vcenter_cluster_cpu_effective - scalar(sum(vcenter_host_cpu_usage))

# Cluster memory utilization %
100 * sum(vcenter_host_memory_usage) by (vcenter_cluster_name)
  / (sum(vcenter_cluster_memory_effective) by (vcenter_cluster_name) / 1024 / 1024)

Noisy neighbours and contention:

# Top 10 VMs by CPU readiness. Anything sustained above 5 percent hurts.
topk(10, vcenter_vm_cpu_readiness)

# VMs actively ballooning or swapping, which means memory pressure
vcenter_vm_memory_ballooned > 0
vcenter_vm_memory_swapped > 0

Storage:

# Datastores over 80 percent
vcenter_datastore_disk_utilization > 80

# Worst VM disk latency (read)
topk(10, vcenter_vm_disk_latency_avg{direction="read"})

Network health:

# Host NIC packet errors
sum(vcenter_host_network_packet_error_rate) by (vcenter_host_name, direction)

# VM packet drops
topk(10, vcenter_vm_network_packet_drop_rate)

Inventory tiles for stat panels:

sum(vcenter_datacenter_vm_count{power_state="on"})
sum(vcenter_datacenter_host_count)
sum(vcenter_cluster_vm_template_count)

A layout that works well in practice:

1. Row 1: stat tiles for VMs on and off, hosts, clusters, datastores, templates.
2. Row 2: cluster CPU and memory, effective versus usage, as time series.
3. Row 3: top-N VM CPU readiness, VM CPU utilization, VM memory utilization.
4. Row 4: datastore utilization bar gauge, VM disk latency top-N.
5. Row 5: host network throughput, packet error and drop rates.
6. Row 6 for vSAN shops: cluster vSAN IOPS, latency, congestion.

Once the dashboards are in place, the datastore utilization and VM CPU readiness panels are the two best candidates for alerts, since both degrade gradually and give you real lead time.

Troubleshooting

Inventory appears but no metrics

This is the most common failure by a wide margin, so it gets its own section.

Symptom. OpenObserve shows hosts, clusters, and datacenters by name, so data is clearly arriving, but the Metrics explorer is empty and no vcenter_* metric streams exist.

Cause. The stream-name header is present on the exporter used by the metrics pipeline. OpenObserve treats it as a directive to write into that one named stream, so every metric collapses into a single stream instead of one stream per metric name. Resource attributes such as vcenter_host_name stay visible as fields, which is exactly why the inventory looks healthy.

Fix.

1. Open C:\otelcol\config.yaml and remove or comment out the stream-name line from the exporter used by metrics/vmware. Better still, split into the two exporters shown earlier.
2. Validate and restart:

C:\otelcol\otelcol-contrib.exe validate --config C:\otelcol\config.yaml
Restart-Service otelcol-contrib

3. Wait one full collection_interval, which is 2 minutes with the config above.
4. Go to Streams, filter by stream type metrics, and confirm individual vcenter_* streams now appear.

The old lumped stream stays behind and can be deleted from the Streams page once the new ones are populating.

If that is not it, the other explanation for the same symptom is that inventory metrics are arriving while performance counters are not. Inventory and capacity come from the vCenter configuration API, whereas CPU, memory, disk, and network come from performance counters. Check statistics levels, confirm VMs are powered on, and confirm hosts are connected and out of maintenance mode.

General reference

Validate any config change before restarting the service:

C:\otelcol\otelcol-contrib.exe validate --config C:\otelcol\config.yaml

Tuning for large environments

Interval versus inventory size. Each scrape enumerates every datacenter, cluster, host, resource pool, VM, and datastore. As a rough guide: under 500 VMs, 2m is fine. Between 500 and 2000 VMs, use 3m to 5m with timeout: 120s. Beyond that, 5m or more, and consider splitting per datacenter with multiple vcenter/<name> receiver instances, or one collector per vCenter.

Cardinality control. The biggest series multipliers are the object attribute, meaning per-disk and per-NIC, on the latency, throughput, and packet metrics. Disabling vcenter.vm.disk.latency.avg, vcenter.vm.network.packet.rate, and their host equivalents cuts datapoint volume dramatically if you only need capacity views.

Batching. Keep send_batch_size at 8192 or above. OpenObserve ingests OTLP efficiently in larger batches, and gzip compression on the exporter typically shrinks payloads by 8 to 10 times.

Multiple vCenters. Define one receiver per vCenter and tag each with the resource processor:

receivers:
  vcenter/dc1:
    endpoint: https://vcenter-dc1.company.local
    username: otel-monitor@vsphere.local
    password: ${env:VCENTER_DC1_PASSWORD}
    collection_interval: 3m
  vcenter/dc2:
    endpoint: https://vcenter-dc2.company.local
    username: otel-monitor@vsphere.local
    password: ${env:VCENTER_DC2_PASSWORD}
    collection_interval: 3m

service:
  pipelines:
    metrics/vmware:
      receivers: [vcenter/dc1, vcenter/dc2]
      processors: [memory_limiter, resource, batch]
      exporters: [otlphttp/openobserve_metrics]

Upgrades. Pin the collector version in your download script, read the vcenter receiver changelog before jumping versions, since metric names and attributes have shifted between releases historically, and always run validate after upgrading.

Quick reference

Binary:        C:\otelcol\otelcol-contrib.exe
Config:        C:\otelcol\config.yaml
Service:       otelcol-contrib (Automatic)
Health:        http://127.0.0.1:13133/
Self-metrics:  http://127.0.0.1:8888/metrics   (the collector's own telemetry)
Validate:      otelcol-contrib.exe validate --config C:\otelcol\config.yaml
Logs:          Windows Event Log > Application > otelcol-contrib
vCenter user:  otel-monitor@vsphere.local (Read-only, propagated)
O2 endpoint:   https://api.openobserve.ai/api/<org>  (cloud)
               http://<host>:5080/api/<org>          (self-hosted, default org is "default")
Auth header:   Authorization: Basic base64(email:token)
Metric naming: vcenter.vm.cpu.usage becomes vcenter_vm_cpu_usage in OpenObserve
stream-name:   Logs exporter only. Never on the metrics exporter.
Where to look: Metrics explorer for metrics, Logs view for syslog. The Streams
               page has a stream type filter, set it to "metrics".

Wrapping up

The VMware side of this is genuinely simple once the read-only user and statistics levels are right, and the collector side is a single YAML file. The part that costs people an afternoon is the exporter header, so if you take one thing away, take this: stream-name belongs on the logs exporter and nowhere near metrics.

OpenObserve is open source under AGPL-3.0, so you can run this whole pipeline self-hosted with no per-host licensing, which matters when you are monitoring a few thousand VMs. If you want to extend the same collector to other infrastructure, the OpenTelemetry integration guides cover the other receivers, and SNMP monitoring with OpenTelemetry is a good next step for the network gear sitting underneath your vSphere clusters.