Metrics details

Cloud Service collects a wide set of metrics about Postgres instances and makes them available in your cloud provider. Most of these metrics are acquired directly from Postgres system tables, views, and functions. The Postgres documentation is the main reference for these metrics.

Some data from Postgres monitoring system views, tables, and functions is transformed to be easier to consume in Prometheus metrics format. For example, timestamp fields are generally converted to Unix epoch time and can be accompanied by a relative time-interval metric. Other metrics are aggregated into categories by label dimensions to limit the number of very specific and narrowly scoped individual metrics emitted. It isn't useful to report the inactivity period of every single backend, for example, so backend statistics are aggregated by database, user, application_name, and backend state.

The number of tables in your database affects the number of metrics in your cloud logging platform, thus affecting your cloud provider costs for storing these metrics. To ensure stability of the metrics pipeline, metrics might be dropped when the number of tables in your database exceeds 2500.

Prometheus labels are included in the exposed metrics. These will be in the $.Message.labels JSON object when consuming a metrics stream, or in a cloud-provider-specific format for metrics ingested into cloud provider monitoring platforms. Dimensions vary depending on the individual metric and are documented separately for each group of related metrics.

The available set of metrics is subject to change. Metrics might be added, removed, or renamed. Where possible, we change the metric name when changing the meaning or type of existing metrics.

cnp_backends

Backend counts from pg_stat_activity aggregated by the listed label dimensions. Useful for identifying busy applications, excessive idle backends, and so on.

Derived from the pg_stat_activity view.

The metrics in this group can have these labels:

cnp_backends_waiting

Postgres instance-level aggregate information on backends that are blocked waiting for locks. Doesn't count I/O waits or other reasons backends might wait or be blocked.

Derived from the pg_locks view.

cnp_pg_database

Per-database metrics for each database in the Postgres instance. Includes per-database vacuum progress information.

Derived from the pg_database catalog.

See also cnp_pg_stat_database.

The metrics in this group can have these labels:

cnp_pg_postmaster

Data on the Postgres instance's managing "postmaster" process.

Derived from the pg_postmaster_start_time() function.

cnp_pg_replication

Physical replication details for a standby replica postgres instance as captured from the standby replica.

Derived from the pg_last_xact_replay_timestamp() function.

Relevant only on standby replicas.

See also cnp_pg_stat_replication, cnp_pg_replication_slots.

cnp_pg_replication_slots

Details about replication slots on a Postgres instance. In most configurations, only the primary server has active replication clients, but other nodes can still have replication slots.

Logical replication slots are specific to a database, whereas physical replication slots have an empty "database" label as they apply to the Postgres instance as a whole.

Derived from the pg_replication_slots view.

See also cnp_pg_stat_replication, cnp_pg_replication.

The metrics in this group can have these labels:

cnp_pg_stat_archiver

Progress information about WAL archiving. Only the currently active primary server generally performs WAL archiving.

WAL archiving is important for backup and restore. If WAL archiving is delayed or failing for too long, the point-in-time recovery backups for a Postgres cluster won't be up to date. This condition has disaster recovery implications and can potentially also affect failover.

Occasional WAL archiving failures are normal, but pay attention to a growing delay in the time since the last successful WAL archiving operation.

The following metrics are reset when a Postgres stats reset is issued on the db server.

Derived from the pg_stat_archiver view.

cnp_pg_stat_bgwriter

Stats for the Postgres background writer and checkpointer processes, which are instance-wide and shared across all databases in a Postgres instance.

Very long delays between checkpoints on a busy system increase the time taken for it to return to read/write availability if crash recovery is required. Excessively frequent checkpoints can increase I/O load and the size of the WAL stream for backup and replication.

The Postgres documentation discusses checkpoints, dirty writeback, and checkpoint tuning in detail.

These metrics are reset when a Postgres stats reset is issued on the db server.

Derived from the pg_stat_bgwriter catalog.

cnp_pg_stat_database

This metrics group directly exposes the summary data Postgres collects in its own pg_stat_database view. It contains statistical counters maintained by Postgres for database activity.

These metrics are reset when a Postgres stats reset is issued on the db server.

Derived from the pg_stat_database catalog.

See also cnp_pg_database.

The metrics in this group can have these labels:

cnp_pg_stat_database_conflicts

These metrics provide information on conflicts between queries on a standby replica and the standby replica's replay of the change-stream from the primary. These are called recovery conflicts.

These metrics are unrelated to "INSERT ... ON CONFLICT" conflicts or multi-master replication row conflicts. They are relevant only on standby replicas.

These metrics are reset when a Postgres stats reset is issued on the db server.

Defined only on standby replicas.

Derived from the pg_stat_database_conflicts view.

The metrics in this group can have these labels:

cnp_pg_stat_user_tables

Access and usage statistics maintained by Postgres on nonsystem tables.

These metrics are reset when a Postgres stats reset is issued on the db server.

Derived from the pg_stat_user_tables view.

See also cnp_pg_statio_user_tables.

The metrics in this group can have these labels:

cnp_pg_stat_replication

Realtime information about replication connections to this Postgres instance, their progress, and their activity.

These metrics aren't reset when a Postgres stats reset is issued on the db server. The "stat" in the name is a historic artifact from Postgres development.

Derived from the pg_stat_replication view.

See also cnp_pg_replication_slots, cnp_pg_replication.

The metrics in this group can have these labels:

cnp_pg_statio_user_tables

I/O activity statistics maintained by Postgres on nonsystem tables.

These metrics are reset when a Postgres stats reset is issued on the db server.

Derived from the pg_statio_user_tables view.

See also cnp_pg_stat_user_tables.

The metrics in this group can have these labels:

cnp_pg_settings

Expose the subset of Postgres server settings that can be represented as Prometheus compatible metrics—any integer, Boolean, or real number. Text-format settings, list-valued settings, and enumeration-typed settings aren't captured or reported.

This set of metrics doesn't expose per-database settings assigned with ALTER DATABASE ... SET ..., per-user settings assigned with ALTER USER ... SET ..., or per-session values. It shows only the database systemwide global values. You can explore other settings interactively using Postgres system views.

Derived from the pg_settings view.

The metrics in this group can have these labels:

cnp_xlog_insert

Reports the postgres instance's transaction log insert position in bytes. Useful to compare one postgres instance's WAL insert position with other instances' replication replay positions in monitoring.

cnp_bdr_rep_slot_stats

Metrics from pg_catalog.pg_stat_replication_slots for each BDR replication slot. These metrics can be used to monitor logical decoding activity and performance the sending (upstream) side of a logical replication connection. See pg_stat_replication_slots for details.

The metrics in this group can have these labels:

cnp_bdr_rep_lag

Metrics based on the bdr.node_replication_rates monitoring catalog for monitoring BDR replication performance and replication lag. See Monitoring Outgoing Replication and bdr.node_replication_rates

The metrics in this group can have these labels:

cnp_bdr_node_slots

Metrics derived from the bdr.node_slots view. These metrics provide lower level insight into the progress of outbound BDR replication, including transaction ID limits and WAL retention and the connection status of replication sessions.

The metrics in this group can have these labels:

cnp_bdr_global_locking

metrics for bdr global lock acquire and hold durations for both DDL and DML lock types. Useful for detection of long global lock waits or frequent global locks that may impact performance. These metrics are not fine grained and do not expose information about individual tables, etc. Details are available in the bdr.global_locks view.

The metrics in this group can have these labels:

Disabled: cnp_bdr_raft_mon

This metric has been disabled for performance and reliability reasons. It will no longer be generated after 2023-08-16. It was used to report on the health of the Raft distributed consensus layer on PGD nodes. Please see the EDB Postgres Distributed monitoring documentation for other methods to monitor Raft health on PGD clusters.

Other metrics streams

In addition to Postgres metrics from the Cloud Native PostgreSQL operator that manages databases in BigAnimal, additional metrics on Kubernetes workload health etc are available from the BigAnimal metrics endpoints. Specific metrics exposed may vary depending on Kubernetes version, BigAnimal deployment model and more. Any such metrics are generally well-known metrics from widely used tools, documented by the upstream vendor of the component. The BigAnimal platform makes no guarantees about the availability or stability of these metrics unless explicitly documented otherwise.

See also Kubernetes cluster metrics.