Exporting PCD metrics
Integrate Private Cloud Director metrics into your existing observability stack by scraping directly from each host or querying the aggregated metrics on the UI
Overview
Private Cloud Director exposes infrastructure metrics via Victoria metrics compatible exporters running on each hypervisor host. If you have an existing observability stack, you can consume these metrics directly without replacing the built-in monitoring setup.
This page explains how the metrics pipeline works and the options available for integrating it into your environment. For the full list of available metrics and their labels, see PCD metrics reference.
How metrics are collected
Metric collection starts automatically when the hypervisor role is assigned to a host. Each host runs two exporters as system services:
node-exporter: Collects host-level metrics such as CPU, memory, disk, and network usage.
libvirt-exporter: Collects VM-level metrics for each virtual machine running on the host.
Each host operates a Victoria metrics agent as a systemctl service. This agent gathers metrics locally from the node-exporter and libvirt-exporter, both of which are set up as systemctl services. These collected metrics are then sent remotely to a Victoria metrics instance running on PCD.
All metrics are retained for 15 days.
Options for consuming metrics
There are two ways to export PCD metrics to your own observability stack.
[Recommended] Scrape from each host
Full raw metrics from every host
Integration with your own observability stack
Remote write from PCD
Processed metrics pushed from PCD
Centralised ingestion into an existing endpoint
Option 1: [Recommended] Scrape directly from each host
Your observability stack scrapes metrics directly from the exporters running on each host.
Add the following endpoints for each host to your scrape configuration:
node-exporter
<host-ip>:9388/metrics
libvirt-exporter
<host-ip>:9177/metrics
Metrics are exposed in the standard Victoria metrics format and can be consumed by any compatible scraper.
Why is this the recommended approach?
Full metric access. The raw exporters expose the complete set of host and VM metrics. The Victoria metrics agent applies recording rules before forwarding to PCD, so PCD holds a reduced set. Scraping per-host gives you access to all underlying data.
Your stack stays in your network. Exporters operate within your network, allowing your observability stack to function internally without external endpoints.
Independent configuration. You can define your own labels, filters, and alerting rules without requiring any changes on the PCD side.
Less load on PCD. PCD already handles remote writes from every host. Adding additional scrape load against it increases pressure on a shared component.
Option 2: Remote write from PCD
Victoria metrics on PCD holds aggregated, processed metrics for your entire deployment and can be configured to remote-write to your observability stack endpoint.
Limitations to consider before choosing this option:
Reduced metric set. The Victoria metrics agent applies recording rules on each host before remote writing to PCD. Metrics that are aggregated or dropped by those rules are not available at the PCD level. If you need full metric fidelity, scrape from each host instead.
Endpoint exposure required. If PCD is deployed in SaaS mode, Victoria metrics on PCD is outside your network. Your observability stack endpoint must be reachable from PCD.
No UI-based configuration. Remote write configuration on PCD is not managed through the PCD UI and must be applied manually.
Remote write configuration on PCD must be applied manually and verified after each upgrade. Contact Platform9 support before making changes to PCD-level configuration.
Next steps
Review PCD metrics reference for the complete list of host and VM metrics available from the exporters.
For the built-in dashboards and Grafana access, see Accessing Grafana Dashboards
Last updated
Was this helpful?