When you area monitoring server from cloud providers the exporter
IP/hostname is not the server IP, so add some constant labels is useful
on dashboards and alerts.
And is very important to use with `--disable-default-metrics` to add
info like `datname` and figure out the database name that you are
monitoring
This did in fact turn out to be an oversight in the error handling. Now, any
error in the initial connection path will always trip pg_up to be 0.
Fixes#160
This commit implements a massive refactor of the repository, and
moves the build system over to use Mage (magefile.org) which should
allow seamless building across multiple platforms.
Adds the following environment variables for overriding defaults:
* `PG_EXPORTER_WEB_LISTEN_ADDRESS`
* `PG_EXPORTER_WEB_TELEMETRY_PATH`
* `PG_EXPORTER_EXTEND_QUERY_PATH`
Closes#150.
Revamp the build system to be more inline with other Prometheus exporters.
Notably add Darwin and Windows build targets, and add support for releases
using tar files.
At some point in the past we find/replaced "this" to "cu" in the source code
and it's been like that ever since, including leaking into some of the metric
descriptions. Clean it up.
On advice from @SuperQ this is inline with the convention used in similar
exporters (example being the mysqld exporter). The full metric name is thus
`pg_up`.
Closes#135
When using queries.yaml, extra columns in the output would be detected as
unknown metrics (correctly) but the labels in the current mapping would not be
applied to the output.
This explains the rash of crashes due to inconsistent label cardinality. The
specific creation is when the name given to a column does not match the mapping
you intended, and so the metric shows up as unknown.
Closes#98
In PostgreSQL, views run as the defining user, meaning you don't
need a view wrapping a function (you can just have a view). This
improves readability, maintainability, performance, and clarity.
