[!] remove obsolete db_stats_aurora metric - #930
Conversation
The `db_stats_aurora` metric was created as a workaround for early AWS Aurora PostgreSQL limitations that prevented using certain PostgreSQL functions like pg_backup_start_time() and complex subqueries for invalid index detection. Modern Aurora PostgreSQL versions (13+) now support virtually all standard PostgreSQL administration functions, making this Aurora-specific variant unnecessary. Users can simply use the standard `db_stats` metric instead, which provides the same functionality plus additional features like backup duration tracking and invalid index monitoring. This removal reduces maintenance overhead and eliminates confusing
db_stats_aurora metricdb_stats_aurora metric
Pull Request Test Coverage Report for Build 17397399850Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
馃挍 - Coveralls |
|
Hi @pashagolub , Thanks for the cleanup! However, I'm running into an issue after the removal of the Since the preset was removed, I started using the
It seems that while Aurora 13+ supports most standard admin functions, standard WAL functions are still not supported due to its custom storage engine. I did some digging to see if we could bypass this in the SQL using a wal:
description: >
This metric collects information about the Write-Ahead Logging (WAL) system in PostgreSQL.
It provides insights into WAL activity, including the current WAL location, replay lag, and other related metrics.
sqls:
11: |-
select /* pgwatch_generated */
(extract(epoch from now()) * 1e9)::int8 as epoch_ns,
case
when exists (select 1 from pg_settings where name like 'aurora%') then null
when pg_is_in_recovery() = false then
pg_wal_lsn_diff(pg_current_wal_lsn(), '0/0')::int8
else
pg_wal_lsn_diff(pg_last_wal_replay_lsn(), '0/0')::int8
end as xlog_location_b,
case when pg_is_in_recovery() then 1 else 0 end as in_recovery_int,
extract(epoch from (now() - pg_postmaster_start_time()))::int8 as postmaster_uptime_s,
system_identifier::text as tag_sys_id,
case
when exists (select 1 from pg_settings where name like 'aurora%') then null
when pg_is_in_recovery() = false then
('x'||substr(pg_walfile_name(pg_current_wal_lsn()), 1, 8))::bit(32)::int
else
(select min_recovery_end_timeline::int from pg_control_recovery())
end as timeline
from pg_control_system()
gauges:
- '*'
is_instance_level: true
wal_receiver:
description: >
This metric collects information about the WAL receiver process in PostgreSQL.
It provides insights into the status of the WAL receiver, including replay lag and last replay timestamp.
sqls:
11: |-
select /* pgwatch_generated */
(extract(epoch from now()) * 1e9)::int8 as epoch_ns,
case
when exists (select 1 from pg_settings where name like 'aurora%') then null
else pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn())::int8
end as replay_lag_b,
case
when exists (select 1 from pg_settings where name like 'aurora%') then null
else extract(epoch from (now() - pg_last_xact_replay_timestamp()))::int8
end as last_replay_s
node_status: standby
gauges:
- '*'
is_instance_level: true |
|
I guess it's better to leave the metrics as they are, so it's clearer to new users that the But I will revert this and recreate an aurora preset that doesn't include |
The
db_stats_aurorametric was created as a workaround for early AWS Aurora PostgreSQL limitations that prevented using certain PostgreSQL functions like pg_backup_start_time() and complex subqueries for invalid index detection.Modern Aurora PostgreSQL versions (13+) now support virtually all standard PostgreSQL administration functions, making this Aurora-specific variant unnecessary. Users can simply use the standard
db_statsmetric instead, which provides the same functionality plus additional features like backup duration tracking and invalid index monitoring.This removal reduces maintenance overhead and eliminates confusing