fix examples queries: change idle process metric name in order not to override built-in pg_stat_activity.

[desaintmartin]

Fixes regression introduced in #435

[desaintmartin]

Tagging @wrouesnel, maybe you have time to review?

[SuperQ]

LGTM, makes sense to separate this out.

[SuperQ]

CC @mwasilew2, would you mind reviewing/testing this?

[solyard]

I've just tried this fix on my production monitoring and its working fine without any changes in other stuff. Maybe it is useful for approving this PR

[mwasilew2]

Thanks @SuperQ for the ping

I was able to reproduce the problem locally (can't test it in production at the moment) using queries.yaml from master:

level=debug ts=2021-05-09T16:58:28.484Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_stat_statements
level=debug ts=2021-05-09T16:58:28.484Z caller=postgres_exporter.go:585 msg="Overriding metric from user YAML file" metric=pg_stat_activity
level=debug ts=2021-05-09T16:58:28.484Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_replication
level=debug ts=2021-05-09T16:58:28.484Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_postmaster
level=debug ts=2021-05-09T16:58:28.484Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_stat_user_tables
level=debug ts=2021-05-09T16:58:28.484Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_statio_user_tables

and confirmed the patch gets rid of the override:

level=debug ts=2021-05-09T21:29:40.648Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_statio_user_tables
level=debug ts=2021-05-09T21:29:40.648Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_database
level=debug ts=2021-05-09T21:29:40.648Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_stat_statements
level=debug ts=2021-05-09T21:29:40.648Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_process_idle
level=debug ts=2021-05-09T21:29:40.648Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_replication
level=debug ts=2021-05-09T21:29:40.648Z caller=postgres_exporter.go:587 msg="Adding new metric from user YAML file" metric=pg_postmaster

Metrics for the idle processes added by the patch look ok:

# HELP pg_process_idle_seconds Idle time of server processes
# TYPE pg_process_idle_seconds histogram
pg_process_idle_seconds_bucket{application_name="psql",server="localhost:5432",le="1"} 0
pg_process_idle_seconds_bucket{application_name="psql",server="localhost:5432",le="2"} 0
pg_process_idle_seconds_bucket{application_name="psql",server="localhost:5432",le="5"} 0
pg_process_idle_seconds_bucket{application_name="psql",server="localhost:5432",le="15"} 0
pg_process_idle_seconds_bucket{application_name="psql",server="localhost:5432",le="30"} 0
pg_process_idle_seconds_bucket{application_name="psql",server="localhost:5432",le="60"} 0
pg_process_idle_seconds_bucket{application_name="psql",server="localhost:5432",le="90"} 0
pg_process_idle_seconds_bucket{application_name="psql",server="localhost:5432",le="120"} 1
pg_process_idle_seconds_bucket{application_name="psql",server="localhost:5432",le="300"} 1
pg_process_idle_seconds_bucket{application_name="psql",server="localhost:5432",le="+Inf"} 1
pg_process_idle_seconds_sum{application_name="psql",server="localhost:5432"} 101
pg_process_idle_seconds_count{application_name="psql",server="localhost:5432"} 1

I submitted some minor fixes to the README file: #530 and thought about adding yaml linting to CI: prometheus/prometheus#8801 . I was also thinking about adding a test that would ensure that the example config file with custom queries works as expected (a more sophisticated version of: https://github.com/prometheus-community/postgres_exporter/blob/master/cmd/postgres_exporter/postgres_exporter_integration_test.go#L145 , in addition to just checking that the endpoint can be scraped the test would capture the response and check it ), but that's a question for another issue/PR.

[SuperQ]

Thanks @mwasilew2!