Monitoring
This page describes the Pigsty monitoring architecture, including metrics, logs, and target management. It also explains how to monitor existing PostgreSQL clusters and remote RDS services.
Monitoring Overview
Pigsty uses these observability components for PostgreSQL monitoring:
- Grafana displays metrics and provides PostgreSQL data sources.
- VictoriaMetrics collects PostgreSQL, Pgbouncer, Patroni, HAProxy, and node metrics.
- VictoriaLogs stores PostgreSQL, Pgbouncer, Patroni, pgBackRest, and host component logs.
- Included Grafana dashboards cover all PostgreSQL operations. The set changes with each release. Use the live demo and this page’s dashboard links.
Metrics
The pg_exporter configuration defines all PostgreSQL monitoring metrics: roles/pg_monitor/templates/pg_exporter.yml.
VictoriaMetrics and vmalert recording and alerting rules process them further: files/victoria/rules/pgsql.yml.
Pigsty attaches three identity labels to all metrics and logs: cls, ins, and ip.
It also uses metrics from Pgbouncer, host nodes (NODE), and load balancers.
Where possible, these metrics use the same labels so you can compare related data.
Logs
Vector collects PostgreSQL-related logs and sends them to VictoriaLogs on infrastructure nodes for storage and queries.
pg_log_dir: postgres log directory, defaults to/pg/log/postgrespgbouncer_log_dir: pgbouncer log directory, defaults to/pg/log/pgbouncerpatroni_log_dir: patroni log directory, defaults to/pg/log/patronipgbackrest_log_dir: pgbackrest log directory, defaults to/pg/log/pgbackrest
Target Management
Each VictoriaMetrics monitoring target instance has a static file in /infra/targets/pgsql/.
This example defines pg-meta-1:
If patroni_ssl_enabled is enabled globally, Patroni uses HTTPS scrape endpoints.
Pigsty writes these targets separately to /infra/targets/patroni/<ins>.yml.
For RDS monitoring, targets are in /infra/targets/pgrds/ and are managed by cluster.
bin/pgsql-rm and pgsql-rm.yml remove the corresponding monitoring targets when they remove a cluster.
You can also run:
pgsql-monitor.yml and bin/pgmon-add create remote RDS targets in /infra/targets/pgrds/<cls>.yml.
Monitoring Modes
Pigsty provides three monitoring modes to suit different monitoring needs.
| Item \ Level | L1 | L2 | L3 |
|---|---|---|---|
| Name | Basic | Managed | Standard |
| Abbr | RDS | MANAGED | FULL |
| Scenario | Connection string only, e.g., RDS | Existing DB, nodes manageable | Instances created by Pigsty |
| PGCAT Features | ✅ Fully Available | ✅ Fully Available | ✅ Fully Available |
| PGSQL Features | ✅ PG metrics only | ✅ PG & node metrics only | ✅ Full Features |
| Connection Pool Metrics | ❌ Not Available | ⚠️ Optional | ✅ Pre-installed |
| Load Balancer Metrics | ❌ Not Available | ⚠️ Optional | ✅ Pre-installed |
| PGLOG Features | ❌ Not Available | ⚠️ Optional | ✅ Pre-installed |
| PG Exporter | ⚠️ On infra nodes | ✅ On DB nodes | ✅ On DB nodes |
| Node Exporter | ❌ Not deployed | ✅ On DB nodes | ✅ On DB nodes |
| Intrusiveness | ✅ Non-intrusive | ⚠️ Install Exporter | ⚠️ Fully managed by Pigsty |
| Monitor Existing Instances | ✅ Supported | ✅ Supported | ❌ For Pigsty-managed only |
| Monitoring Users & Views | Manual setup | Manual setup | Auto-created by Pigsty |
| Deployment Playbook | bin/pgmon-add <cls> | Partial pgsql.yml/node.yml | pgsql.yml |
| Required Permissions | Connectable PGURL from infra | SSH & sudo on DB nodes | SSH & sudo on DB nodes |
| Feature Summary | PGCAT + PGRDS | Most features | Full features |
Pigsty automatically monitors fully managed databases with all supported features. They usually need no extra configuration. For existing PostgreSQL clusters or RDS services, use managed deployment if Pigsty can access the nodes through SSH and sudo. This gives monitoring similar to a native Pigsty deployment. If you have only a PGURL connection string, use basic mode.
Monitor Existing Cluster
If Pigsty can manage the target database nodes, deploy monitoring components there with the pg_exporter task in pgsql.yml.
This requires ssh access and sudo privileges.
Use pgbouncer and pgbouncer_exporter from the same playbook to deploy connection pools and pool monitoring.
Use node_exporter, haproxy, and vector from node.yml for host monitoring, load balancing, and log collection.
These components provide the same monitoring features as native Pigsty database instances.
Define existing clusters in the same way as Pigsty-managed clusters.
Run only the required pgsql.yml tasks, rather than the complete playbook.
For an existing cluster, manually create monitoring users, schemas, and extensions in the target database.
Monitor RDS
If you have only a PGURL connection string, follow this section. Pigsty deploys PG Exporters on INFRA nodes to collect remote database metrics:
This mode provides database metrics and current status from the data catalog. It does not provide host, connection pool, load balancer, or high-availability component metrics. Pigsty provides two dashboards for PostgreSQL metrics: PGRDS Cluster and PGRDS Instance. Overview and database monitoring use the existing dashboards. Because Pigsty cannot manage RDS, configure monitoring objects on the target database first.
- PgBouncer connection pool metrics are not available
- Patroni high availability component metrics are not available
- Host node monitoring metrics are not available, including node HAProxy and Keepalived metrics
- Log collection and log-derived metrics are not available
The following example uses the sandbox.
Treat pg-meta as the RDS instance pg-foo-1, and pg-test as the RDS cluster pg-bar.
Create monitoring schemas, users, and permissions on the target. Refer to Monitor Setup for details
Declare the cluster in the configuration inventory. For example, if we want to monitor “remote”
pg-meta&pg-testclusters:Pigsty registers databases from
pg_databasesas PostgreSQL data sources in Grafana for PGCAT dashboards. If you do not need PGCAT or Grafana registration, setpg_databasesto an empty array or leave it blank.
Execute the add monitoring command:
bin/pgmon-add <clsname>To remove remote cluster monitoring targets, use
bin/pgmon-rm <clsname>
Use additional parameters to override default pg_exporter options.
This example monitors Aliyun RDS for PostgreSQL and PolarDB:
Example: Monitoring Aliyun RDS for PostgreSQL and PolarDB
For details, refer to: remote.yml
Monitor Setup
Before you monitor an existing RDS or self-managed PostgreSQL instance, configure the target database for Pigsty access.
To monitor an external PostgreSQL instance, provide a connection string that can access the instance or cluster. A business user or superuser connection string can work. However, use a dedicated monitoring user to avoid exposing other privileges.
- Monitor User: The default username is
dbuser_monitor, which should belong to thepg_monitorrole group or have access to relevant views - Monitor Authentication: Default password authentication is used; ensure HBA policies allow the monitoring user to access databases from the admin node or DB node locally
- Monitor Schema: Fixed schema name
monitoris used for installing additional monitoring views and extension plugins; optional but recommended - Monitor Extension: Strongly recommended to enable the built-in monitoring extension
pg_stat_statements - Monitor Views: Monitoring views are optional but can provide additional metric support
Monitor User
Using the default monitoring user dbuser_monitor as an example, create the following user on the target database cluster.
The monitoring username and password must match pg_monitor_username and pg_monitor_password.
Monitor Authentication
Add these rules to pg_hba.conf.
They allow the monitoring user to access all databases from localhost and the administration node with password authentication:
If RDS does not allow HBA configuration, allow the internal IP address of the machine that runs Pigsty.
Monitor Schema
The monitoring schema is optional. Core Pigsty monitoring works without it. However, creating this schema is strongly recommended.
Monitor Extension
The monitoring extension is optional.
However, enabling pg_stat_statements is strongly recommended because it supplies important query performance data.
Add this extension to shared_preload_libraries to enable it.
Changing this parameter requires a database restart.
Install this extension in the default administration database, postgres.
Some RDS services do not allow a monitoring schema in postgres.
In this case, install pg_stat_statements in the default public schema.
Configure the monitoring user search_path as shown above so it can find the pg_stat_statements view.
Monitor Views
Monitoring views provide common preprocessed query results. They also control access to metrics that need high privileges, such as shared memory allocation. This makes these metrics easier to query and use. Creating the views in every monitored database is strongly recommended.
Monitoring schema and monitoring view definitions
The SQL below is provided to explain the monitored objects. The complete definitions rendered by current Pigsty are authoritative in
roles/pgsql/templates/pg-init-template.sql, which also includes additional hardening for secure search paths and privilege boundaries.
Function for viewing shared memory allocation (PG13 and above)
Was this page helpful?
Thanks—your feedback helps us improve this page.
What got in the way? (optional)