1. The observability stack
The VDURA observability feature pairs a metrics pipeline with a logs pipeline. Every node runs a set of vdura-* services that collect data and forward it to storage on the observability VM, where it is kept in VictoriaMetrics (metrics) and VictoriaLogs (logs).
VDURA does not ship Grafana, and no Grafana instance is part of a VDURA system. Grafana appears in this reference for two reasons only: it is a common way to read the stored data, and VDURA provides sample dashboards (Chapter 4) that you can import into a Grafana instance that you run yourself. The Grafana instance used while compiling this reference was a test setup (version 13.0.1) with a VictoriaMetrics data source pointed at the test realm.
This reference catalogs the time series stored in the VictoriaMetrics database behind that stack: what each metric family measures, which labels it carries, how it is collected, and how the sample Grafana dashboards use it. It was compiled from a snapshot of a test realm (3 directors and 12 storage nodes on cloud virtual machines, PanFS release 2026.35.0) that held 1,501 metric names and about 102,000 active series. Rows marked “I” in the confidence column are inferred from names and observed values and should be confirmed with engineering.
| Component | Where | Role |
|---|---|---|
| VictoriaMetrics cluster (vmselect) | http://<director-ip>:8481/select/0/prometheus | Metrics query endpoint. Cluster edition, tenant 0. Prometheus compatible API plus MetricsQL. |
| VictoriaLogs | http://<director-ip>:9471 | Log storage and LogsQL query endpoint for file and journald logs from every node. |
| vmalert | on the observability VM (not reachable from a Grafana data source) | Evaluates rule groups panfs.alerts and panfs.processes and writes ALERTS/ALERTS_FOR_STATE series. |
| vdura-metrics-agent | every realm node | Telegraf style host collection (cpu, mem, disk, net, procstat…) plus the PanFS management agent statistics tree (magent_*). |
| Realm collector | director nodes (host <director-ip>, the master) | Reads realm state from the management database and emits the panfs_* inventory, alert catalog and event metrics. |
In this guide, <director-ip> stands for the management IP address of a director node, and <realm-name> for the name of your realm. Replace each with the value for your own realm.
1.1 Realm topology in the data
Every series carries a common set of labels that identify the emitting node. These make it possible to slice any metric by node or by node role without joins.
| Label | Example | Meaning |
|---|---|---|
| host | <realm-name>-director-0, <realm-name>-osd-7 | Linux hostname of the node (the cloud instance name in the test realm). |
| host_id | fdbe4872-bf8a-a74a-… | Stable node UUID assigned by the VDURA node identity service. |
| ip_address | <director-ip> (directors), the storage network range (storage) | Management IP of the node. |
| node_name | VCH-1,1 … VCH-15,1 | PanFS realm name of the node in enclosure,slot form. In this realm VCH-1, VCH-8 and VCH-15 are the directors and the other twelve are storage nodes. Realm level panfs_* inventory metrics carry only this label. |
| node_type | director_l or vpod | Node role: director_l = director (Linux), vpod = virtual storage node hosting one OSD. |
Node counts by role: count by (node_type) (system_uptime) returns director_l = 3, vpod = 12. The magent_* families split cleanly on role: 3 series per metric means director only (File Manager, caches, keys), 12 means storage only (iopath), 15 means every node.
1.2 Collection cadence and retention
Measured from the data: Management agent (magent_*) and realm (panfs_*) metrics arrive every 20 seconds (30 samples per 10 minutes). Host metrics are denser; system_uptime shows 180 samples per 10 minutes, which suggests the host collector runs at 10 seconds or less with duplicate delivery. The realm was built about 22 hours before this snapshot, so the retention period could not be measured; check the VictoriaMetrics -retentionPeriod flag on the observability VM.