Open machine424 opened 2 years ago
We're migrating away from queries.yaml in favor of having new features added to the collector package
Thanks for the issue. These look to me like they would be valuable to implement. Having all of these queries and help descriptions will be useful for the person that actually implements these in that collector package.
We're migrating away from queries.yaml in favor of having new features added to the collector package
@SuperQ this is just plain silly. You're just not going to want to take on the implementation of everything that anyone might want/currently has implemented and not everything that anyone currently implements through custom queries is going to be relevant to most users which is the bar that you'd probably want to set for implementing a new collector.
I can understand doing this for the standard query stuff but you still need a way to allow for extensibility otherwise you basically make it useless to anyone currently using custom queries and force those users to find a way around the limitation.
I'll give an example of a custom query that you don't want to implement as a collector. A query that returns metrics for the auth session table of the company that I work for's proprietary software. That's something that's specific to us and it's not something anyone else has and it's something because of that you're never going to want to write a collector for. My only options are, to fork and then maintain the fork for this project with a custom go collector that I write or use the old version (hopefully only until such a time as you - the team - come to your - also the team collectively - senses and realise your error here).
Nice to have https://www.postgresql.org/docs/current/pgstattuple.html I dont see collector for this. means queries.yaml is still relevant at least for me
I'll give an example of a custom query that you don't want to implement as a collector. A query that returns metrics for the auth session table of the company that I work for's proprietary software.
This is better suited for a generic SQL exporter. This is not related to postgres server metrics. This exporter is specifically for server metrics, not generic business metrics.
@garry-t, would you mind opening a separate issue as a feature request to add that as a new collector. Please also describe what you want to get out of it.
Looks like the idea now is to use this for anything custom
Proposal
Hello,
Here are some custom metrics that are/were very useful for us:
pg_sizes_*
different sizes on tables inpg_stat_all_tables
pg_stat_progress_vacuum_*
exposepg_stat_progress_vacuum
content (can be used to get graphs like below (I can share the Grafana Dashboard))pg_stat_all_tables_*
that extendspg_stat_user_tables_*
(in queries.yaml) to Toast tables.Pleas tell me if you find them relevant so we can adjust them (maybe correct them haha) and add them to queries.yaml.