MonPG Documentation

Set up MonPG against your PostgreSQL in minutes, understand every page the product ships, and get the tuning recommendations we publish for each managed provider.

Quickstart

New installations take about five minutes. The collector runs as a small Docker container (or systemd unit) inside your network, connects to PostgreSQL with a read-only role, and streams metrics to MonPG over an outbound TLS connection — no inbound firewall changes, no SSH access required. The quickstart guides walk through creating the role, enabling the required extensions, and verifying the first ingest end-to-end.

Provider-specific setup

Each managed PostgreSQL provider has its own quirks: parameter groups on AWS RDS and Aurora, server parameters on Azure Flexible Server, database flags on Google Cloud SQL and AlloyDB, plug-in restrictions on Heroku, and provider-specific extension lists on Aiven and Crunchy. Self-hosted deployments give you full control over postgresql.conf. We keep a per-provider page that lists exactly which extensions, GUCs, and IAM roles MonPG needs so you don't have to translate generic instructions to your environment.

Tuning recommendations

Beyond raw metrics, MonPG publishes opinionated tuning guidance — index advisor outputs, vacuum/autovacuum tuning, work_mem and shared_buffers sizing for typical workloads, and query rewrite suggestions surfaced from pg_stat_statements. The tuning pages explain the reasoning behind each recommendation so you can apply judgment rather than rubber-stamping changes in production.

Troubleshooting and alerts

When something goes wrong — collector silent, gaps in metrics, missing slow queries, unexpected connection counts — start with the troubleshooting section. It maps each common failure mode to the configuration check or log line that diagnoses it. Alert configuration, threshold tuning, notification routing (Slack, email, webhook), and on-call escalation are documented under Alerts & Notifications.