On 2/15/22 07:30, Dave Page wrote:
On Mon, 14 Feb 2022 at 20:16, Greg Stark <st...@mit.edu
<mailto:st...@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
