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. On AWS and GCP, Ryvn collects those host-level series for RDS and Cloud SQL instances whose module emits the cloud_metrics output — see Cloud datastore metrics for what’s collected and the per-installation collection status. On Azure, use your cloud console (Azure Monitor) for host-level series. Built-in Metrics-tab cards have a per-provider query arm: the IOPS card is AWS-only today — GCP emits ops metrics as native stackdriver_* series (e.g. cloudsql.googleapis.com/database/disk/read_ops/write_ops when you select them) that you query directly in the environment’s Grafana; they do not populate the built-in card.

​
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.