pgMonitor added sql_exporter support

[keithf4]

Just wanted to let you know that a project that I maintain, pgMonitor, will be switching to using sql_exporter for its PostgreSQL metrics gathering. The first version with this support has been released

https://github.com/CrunchyData/pgmonitor

The query files for the PG metrics we support can be found here

https://github.com/CrunchyData/pgmonitor/tree/development/sql_exporter/common

It makes use of an extension that is installed into the database to keep as much of the query complexity out of the exporter config as possible. The goal was to make it so the only thing you need to write in the exporter is a simple SELECT to a view. Query runtime is kept to a minimum by making use of materialized views.

https://github.com/CrunchyData/pgmonitor-extension

Also wanted to say thank you for the quick support you've given when I've opened several issues over the last year or so. Specifically the pgBouncer support and scrape error suppression since those were roadblocks for us getting this working.

The project is open sourced so if you have anyone with questions about using this exporter with PostgreSQL please feel free to send them our way.

[burningalchemist]

Hey @keithf4, sounds amazing! 🎉 Glad to hear it helps achieve your goals! Starred both projects and happy to stay in touch! 👏

[burningalchemist]

@keithf4, I didn't find a better place (yet) to communicate (I sent a LinkedIn request just in case) - I plan to migrate sql_exporter to a new logging library (it's log/slog and it's a common move in the Prometheus community at the moment).

The PR is ready, but I want to promote this change with the prior announcement and few steps, so I think of v0.17 (current one is v0.15 with a new release coming soon).

Just wanted to share this info in advance. 👍

[keithf4]

I'm not really on linkedin much, so this works.

Looks like the only real user change with that log PR is a new startup flag?

Thanks!

[burningalchemist]

log/lsog package has a way to write to a file (requested by Windows users), so it will be one extra parameter.

Also, log.json will turn into the proper log.format parameter, but it's out of scope of this logging library migration and is planned for v0.16.

In fact, both parameters are optional, so startup should work as usual. 🤔

So I think, mainly it's the log format that is different - field names, some extra fields (to adopt the structured log model even for string-based logfmt). But I'll do some comparison before the release anyway.

So it's just a heads up. 👍