Align metric names with Prometheus naming conventions

Use base units, export cumulative values as _total counters, update docs, dashboards and rules.

docs/architecture.md

@@ -58,15 +58,18 @@ type PveMetricsCollector interface {
 ```
 
 Successful execution time is recorded in
-`pve_metrics_collection_latency_ms`. A collector error is logged and the
+`pve_metrics_collection_duration_seconds`. A collector error is logged and the
 manager continues with the next collector.
 
 ## TTL metrics
 
-Most project metrics use `TTLGaugeVec`, a wrapper around Prometheus `GaugeVec`.
-Every label set records its last update. `TTLRegistry` checks registered metrics
-every five seconds and removes series that have not been updated for five
-minutes.
+Gauges use `TTLGaugeVec`, a wrapper around Prometheus `GaugeVec`. Cumulative
+values use `TTLCounterVec`, which exports the absolute value reported by the PVE
+API as a Prometheus counter (`GaugeVec` cannot be used because a counter name
+must carry a `_total` suffix, and `CounterVec` cannot be used because it only
+supports `Inc`/`Add`). Every label set records its last update. `TTLRegistry`
+checks registered metrics every five seconds and removes series that have not
+been updated for five minutes.
 
 This prevents deleted guests or storage resources from remaining indefinitely,
 while allowing short API failures to preserve the last known values.
@@ -75,14 +78,19 @@ while allowing short API failures to preserve the last known values.
 
 1. Add typed response models and API methods under `proxmox`.
 2. Add a collector implementing `PveMetricsCollector` under `metrics`.
-3. Create metrics with `NewTTLGaugeVec`, choose stable labels, and register each
-   metric with the shared `TTLRegistry`.
+3. Create metrics with `NewTTLGaugeVec` or, for cumulative values, with
+   `NewTTLCounterVec`, choose stable labels, and register each metric with the
+   shared `TTLRegistry`.
 4. Add a boolean switch to `PveMetricsConfiguration` and `config.example.yaml`.
 5. Register the collector in `NewPveMetricsManager`.
 6. Add parsing, state-mapping, and topology tests as appropriate.
 7. Document the switch, labels, units, and state values in
    [configuration.md](configuration.md) and [metrics.md](metrics.md).
 
+Metric names must follow the Prometheus naming conventions; they are verified by
+`TestPveMetricNamesFollowPrometheusConventions`, which lints every registered
+metric with `promlint`.
+
 Avoid labels containing changing messages, timestamps, or other unbounded
 values. For recursive resources such as ZFS, include a stable path so repeated
 component names remain distinguishable.