The Future of Observability in Postgres
summary
Current Postgres monitoring uses external postgres_exporter processes that connect over SQL to PG stats views, causing operational complexity, connection exhaustion, locks and precision loss. The alternative reads the new shared-memory stats from a background worker in C and serves OpenMetrics/Prometheus text via a tiny webserver on a separate port, eliminating per-database exporter processes and reducing contention. A proof‑of‑concept exists, produces Grafana graphs and avoids missed metrics windows, but lacks object-name annotations and full parity with all PG stat views.
AI-written summary · about
chapters (15)
- 0:00Introduction and goals
- 1:10What are metrics in Postgres
- 3:43Modern monitoring systems
- 6:52Postgres exporter limitations
- 10:52Resource contention issues
- 13:03Data fidelity problems
- 20:08Better architecture proposal
- 25:06Ideal monitoring setup
- 30:32Standardized metrics for dashboards
- 34:01Postgres 15 shared memory stats
- 37:57Background worker implementation
- 41:26Auto-discovery and challenges
- 45:17Custom queries and application monitoring
- 48:29Future of observability pillars
- 50:36Q&A and implementation status
related talks
49mUnified Observability: Monitoring Postgres Anywhere with OpenTelemetry
49mProfessional PostgreSQL monitoring made easy
51mHow to improve PostgreSQL Monitoring and ...
42mProfessional PostgreSQL monitoring made easy
50mHow To Improve PostgreSQL Monitoring and Observability With PMM - Part 2
51mWhen Postgres Can't, You Can!
50mHow To Improve PostgreSQL Monitoring and Observability With PMM
30mPostgreSQL Network Filter for EnvoyProxy