Add a couple of of options to the `stat_statements` collector that
allow excluding certain database names or user names from metrics.
This is useful if you don't care about certain preconfigured databases
with admin activity.
Signed-off-by: Cristian Greco <cristian@regolo.cc>
When there are no long running transactions, the oldest timestamp will be NULL. This sets the metrics value to 0 (age). Also adds a test for this behavior.
Fixes#1223
Signed-off-by: Joe Adams <github@joeadams.io>
Add `.limit` CLI flag to `stat_statements` collector to allow
setting a custom number of queries to be returned.
Signed-off-by: Cristian Greco <cristian@regolo.cc>
In `pgStatWalReceiverQueryTemplate`, the order of the columns (when `hasFlushedLSN == true`) is:
- ...
- `receive_start_lsn`
- `flushed_lsn`
- `receive_start_tli`
- ...
However, columns were scanned in this order:
- ...
- `receive_start_lsn` -> `receiveStartLsn`
- `receive_start_tli` -> `flushedLsn` (!)
- `flushed_lsn` -> `receiveStartTli` (!)
- ...
This incorrect hydration of variables also manifests as swapped values for the
`pg_stat_wal_receiver_flushed_lsn` and `pg_stat_wal_receiver_receive_start_tli` metrics.
This seems to be a bug that has existed since the initial implementation:
- 2d7e152751
- https://github.com/prometheus-community/postgres_exporter/pull/844
In this patch, I'm:
- fixing the `.Scan()`, so that it hydrates variables in the correct order
- adjusting the order in which metrics are pushed out to the channel,
to follow the order we consume them in
(.., `receive_start_lsn`, `flushed_lsn`, `receive_start_tli`, ..)
- adjusting the walreceiver tests, to follow the new order (which matches .`Scan()`)
- fixing a small identation issue in `pgStatWalReceiverQueryTemplate`
Signed-off-by: Slavi Pantaleev <slavi@devture.com>
To reduce the observer effect, filter out pg_stat_activity rows of the
postgres_exporter session from all SA queries, based on pid / procpid.
A bit annoying to see idling DBs showing pg_stat_activity_count "active"
count of 1
Signed-off-by: Kaarel Moppel <kaarel.moppel@gmail.com>
Minor fixes as I was skimming through:
- fix typo in `stat_statements`
- drop custom `sliceContains` in `database`
Signed-off-by: Cristian Greco <cristian@regolo.cc>
* Add a collector for pg_buffercache_summary()
* Requires PostgreSQL >= 16.
---------
Signed-off-by: Peter Nuttall <peter.nuttall@snowflake.com>
Co-authored-by: Ben Kochie <superq@gmail.com>
* Export query itself together with queryId in stat_statement metrics
* The feature must be enabled via flag.
* Limit length of selected query.
The query is not added to every metrics, but instead of new metric stat_statement_query_id is introduced that contains mapping between queryId and query.
Fixes: #813
---------
Signed-off-by: Jakub Štiller <stiller@2n.cz>
Signed-off-by: Jakub Štiller <jakstiller@atlas.cz>
The exported replication lag does not handle all failure modes, and can
report 0 for replicas that are out of sync and incapable of recovery.
A proper replacement for that metric would require a different approach
(see e.g. #1007), but for a lot of folks, simply exporting the age of
the last replay can provide a pretty strong signal for something being
amiss.
I think this solution might be preferable to #977, though the lag
metric needs to be fixed or abandoned eventually.
Signed-off-by: Conrad Hoffmann <ch@bitfehler.net>
To extract time in seconds for pg_long_running_transactions_oldest_timestamp_seconds query which currently return epoch time.
Signed-off-by: Jyothi Kiran Thammana <147131742+jyothikirant-sayukth@users.noreply.github.com>
In a streaming replication setup that was created without replication
manager (`repmgr`), the `stat_wal_receiver` collector does not return
any metrics, because one value it wants to export is not present.
This is rather overly opinionated. The missing metric is comparatively
uninteresting and does not justify discarding all the others. And
replication setups created without `repmgr` are not exactly rare.
This commit makes the one relevant metric optional and simply skips it
if the respective value cannot be determined.
Signed-off-by: Conrad Hoffmann <ch@bitfehler.net>
* Fix bugs mentioned in #908
These collectors are disabled by default, so unless enabled, they are not tested regularly.
Signed-off-by: Joe Adams <github@joeadams.io>
---------
Signed-off-by: Joe Adams <github@joeadams.io>
* Long running transactions collector and test
---------
Signed-off-by: Felix Yuan <felix.yuan@reddit.com>
Co-authored-by: Ben Kochie <superq@gmail.com>
* Stats_reset as null seems to actually be legitimate for new databases,
so don't fail for it
---------
Signed-off-by: Felix Yuan <felix.yuan@reddit.com>
Co-authored-by: Ben Kochie <superq@gmail.com>
This no longer returns an error when creating a collector.instance when the database cannot be reached for the version query. This will resolve the entire postgresCollector not being registered for metrics collection when a database is not available. If the version query fails, the scrape will fail.
Resolves#880
Signed-off-by: Joe Adams <github@joeadams.io>
go-sqlmock's Rows.AddRow() takes values which have a type alias of
"any", and appear to default to untyped ints if not explicitly cast.
When large values are passed which would overflow int32, tests fail.
Signed-off-by: Daniel Swarbrick <daniel.swarbrick@gmail.com>
