Re: Observability in Postgres

On 2/15/22 07:30, Dave Page wrote:
> On Mon, 14 Feb 2022 at 20:16, Greg Stark <stark@mit.edu 
> <mailto:stark@mit.edu>> wrote:
> 
>     So I've been dealing a lot with building and maintaining dashboards
>     for (fleets of) Postgres servers. And it's a pain. I have a few
>     strongly held ideas about where the pain points are and what the right
>     ways to tackle them are. Some of which are going to be controversial I
>     think...

<snip>

>     This work is being funded by Aiven which is really interested in
>     improving observability and integration between Postgres and other
>     open source cloud software.
> 
> 
> I agree with pretty much everything above, bar a couple of points:
> 
> - Does it really matter if metrics are exposed on a separate port from 
> the postmaster? I actually think doing that is a good thing as it allows 
> use of alternative listen addresses and firewalling rules; you could 
> then confine the monitoring traffic to a management VLAN for example.
> 
> - I strongly dislike the idea of building this around the 
> prometheus exporter format. Whilst that is certainly a useful format if 
> you're using prom (as many do), it does have limitations and quirks that 
> would make it painful for other systems to use; for example, the need to 
> encode non-numeric data into labels rather than the metrics themselves 
> (e.g. server version strings or LSNs). I would much prefer to see a 
> common format such as JSON used by default, and perhaps offer a hook to 
> allow alternate formatters to replace that. The prometheus format is 
> also pretty inefficient, as you have to repeat all the key data (labels) 
> for each individual metric.


+1 to Dave's points

Joe
---
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development