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
