Which privileges are required?

As the RDS master user (a member of rds_superuser): GRANT pg_monitor TO clustereye, plus CONNECT on each monitored database. Without pg_monitor PostgreSQL redacts the per-query and per-session catalogs, so that one grant unlocks most of the coverage.

← All databases

AW

AWS RDS for PostgreSQL monitoring

Amazon RDS for PostgreSQL is monitored agentlessly in ClusterEye: the connection is made over TLS from the ClusterEye API server and nothing is installed on the RDS instance. Because a managed service puts the host out of reach, ClusterEye combines two sources — in-database catalog views and host metrics from CloudWatch — so you can tell a slow query apart from an undersized instance class.

AgentlessDefault port: 5432Versions: RDS

What we read

pg_stat_activity — sessions, wait events and blocking chains

pg_stat_statements — per-query timing and call statistics (once enabled through the parameter group)

pg_stat_user_tables / user_indexes — dead tuple accumulation, vacuum history and index usage

pg_stat_replication — read replica lag and replication state

transaction ID age — distance to wraparound and whether autovacuum is keeping up

database and table sizes — storage consumption and the growth curve

CloudWatch — CPU, memory, disk and network metrics, keyed on the DB instance identifier

the RDS instance class — vCPU and memory ceiling, for capacity assessment

What it does specifically for AWS RDS

Query and host metrics on one timeline

The in-database wait profile and the CloudWatch host series share an axis, so hitting a CPU ceiling and a query generating load are distinguishable at a glance.

Instance class awareness

Headroom is computed against the vCPU and memory ceiling of the instance class actually in use, so a scale-up decision rests on remaining margin rather than a guess.

Storage growth forecasting

Storage consumption is tracked over time and the date of reaching the configured limit is projected.

Autovacuum and wraparound tracking

Dead tuple ratio, whether autovacuum is keeping up, and distance to transaction ID wraparound are tracked, with early warning because manual intervention is limited on a managed service.

Minimum privileges required

The baseline is read-only and safe to grant in production.

sql

-- Run as the RDS master user (a member of rds_superuser)
CREATE ROLE clustereye LOGIN PASSWORD '<strong-password>';
GRANT pg_monitor TO clustereye;

-- repeat for every monitored database
GRANT CONNECT ON DATABASE <db> TO clustereye;

Prerequisites

·Agentless: the connection is made from the ClusterEye API server; nothing is installed on the RDS instance.

·The RDS security group must allow access from the ClusterEye API server.

·TLS defaults to verify-full — the AWS global root bundle ships with ClusterEye, so there is nothing to upload.

·For query intelligence: add pg_stat_statements to shared_preload_libraries in the DB parameter group (a reboot is required), then run CREATE EXTENSION pg_stat_statements in each database.

·Host metrics (CPU, memory, disk) come from CloudWatch and need an AWS access key/secret, a region and the DB instance identifier. Without them in-database monitoring is unaffected; only the host series stays empty.

Install and privilege details →

Frequently asked questions

Nothing. The connection is made from the ClusterEye API server over 5432/tcp with TLS; you only allow that server in the RDS security group. TLS defaults to verify-full, and because the AWS global root bundle ships with ClusterEye there is no certificate to upload.

Start monitoring your AWS RDS for PostgreSQL estate in five minutes.

One command to install. Talk to us if you have questions.

Book a live demo Install and privilege details