We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Observability in Postgres

Formal Metadata

Title
Observability in Postgres
Subtitle
The Good, the Bad, and the Ugly
Title of Series
Number of Parts
542
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Postgres provides a plethora of performance metrics useful for monitoring tools available through SQL. However monitoring a traditional relational database using modern observability tools presents some unique challenges. Postgres's metrics can be extremely detailed and provide rich information about the relationships between the different database objects. However this requires custom SQL queries and the getting the right level of detail depends heavily on understanding style of architecture of the database schema. This kind of customization makes it difficult to deploy and maintain any dashboards, or alerts. Even on a mundane level deploying an agent to interface through SQL introduces operational difficulty requiring additional custom work to coordinate the agent and database deploy and introducing many failure modes which can result in inaccurate metrics, no metrics, or even cause database outages. I'm currently working on improving Postgres's support for modern observability tools and I have plans and challenges to talk about. Ideally I want to make things work smoothly out of the box without having each site have to write custom queries and design custom dashboards to get the right level of data for their database and adapt it to their deployment environment.