Skip to main content
Ryvn-provisioned Postgres databases can emit engine metrics alongside the metrics Ryvn already collects for Kubernetes workloads. The metrics come from the database itself (pg_stat_* views), so they are identical whether the database runs on Amazon RDS, Google Cloud SQL, or Azure Database for PostgreSQL Flexible Server.

​
Enabling metrics

Enable Metrics (input enableMetrics) is on by default on the Postgres blueprint installation. Metrics collection:
  1. Provisions a dedicated monitoring role in the database, granted pg_monitor and nothing else. The role can read Postgres statistics — never your data.
  2. Runs a small exporter pod (about 50m CPU / 64Mi memory) in your cluster that connects to the database over TLS and exposes its statistics for collection.
Metrics appear on the installation’s Metrics tab and in Grafana within a few minutes. Turning the input off drops the monitoring role and stops collection, on an existing database as well as a new one; the exporter installation is reported for uninstall rather than removed automatically, so uninstall it once metrics are no longer wanted. The database itself is never modified.

​
What is collected

Collection is deliberately coarse: metrics are scraped once a minute and per-table and per-index statistics are not collected, which keeps a database’s footprint at roughly 250 time series regardless of how many tables it has. Query-level statistics (pg_stat_statements) are not collected, so query load is measured as active backends and row throughput rather than as per-statement counts.

​
Host-level metrics

CPU, IOPS, storage headroom, and failover events are reported by the cloud provider rather than by Postgres, so they are not part of this set. Use your cloud console (CloudWatch, Cloud Monitoring, Azure Monitor) for those until Ryvn collects them directly.

​
Per-cloud notes

The monitoring role is created by the database’s master user (rds_superuser) and granted pg_monitor. All metrics in the table above are available.
The monitoring role is created by the master user (cloudsqlsuperuser) and granted pg_monitor. All metrics in the table above are available.
The monitoring role is created by the master user (azure_pg_admin) and granted pg_monitor. All metrics in the table above are available.
Replication lag is not reported for any of the three: on a managed high-availability instance the standby replicates below the engine, so Postgres has no replica to report on.

​
Querying the metrics yourself

Every series carries the environment label and an installation label set to the database installation, not to the exporter that produced it. To chart connections for a database named orders-db in Grafana:
The metric names are those of postgres_exporter, so community dashboards work with the addition of an installation filter.