Description
The built-in Grafana panel Replication lag (byte) does not display any data because it expects a field that is never collected by the replication metric.
The dashboard query is:
select
$__timeGroup(time, $agg_interval),
tag_data->>'application_name'::text as client_info,
avg((data->>'total_lag')::bigint) as " "
from replication
where dbname in ($dbname)
and $__timeFilter(time)
and (data->>'total_lag')::bigint > 0
group by 1, 2
order by 1
However, the replication metric stores:
{
"sent_lag_b": 0,
"write_lag_b": 0,
"flush_lag_b": 0,
"replay_lag_b": 0,
...
}
There is no total_lag field.
Example row:
select data
from replication
limit 1;
returns
{
"state": "streaming",
"sent_lag_b": 0,
"write_lag_b": 0,
"flush_lag_b": 0,
"replay_lag_b": 0,
"write_lag_ms": 1,
"flush_lag_ms": 1,
"replay_lag_ms": 2
}
As a result,
(data->>'total_lag')::bigint
always evaluates to NULL and the panel shows No data.
Environment
pgwatch 5.2
PostgreSQL 16.14
Possible solutions
Either:
Update the dashboard to use one of the existing fields (replay_lag_b or GREATEST(sent_lag_b, write_lag_b, flush_lag_b, replay_lag_b)),
or
Add a total_lag field to the replication metric so that it matches the dashboard expectations.
At the moment the dashboard and the collected metric are inconsistent.
Description
The built-in Grafana panel Replication lag (byte) does not display any data because it expects a field that is never collected by the
replicationmetric.The dashboard query is:
However, the replication metric stores:
There is no total_lag field.
Example row:
returns
As a result,
(data->>'total_lag')::bigintalways evaluates to NULL and the panel shows No data.
Environment
pgwatch 5.2
PostgreSQL 16.14
Possible solutions
Either:
Update the dashboard to use one of the existing fields (replay_lag_b or GREATEST(sent_lag_b, write_lag_b, flush_lag_b, replay_lag_b)),
or
Add a total_lag field to the replication metric so that it matches the dashboard expectations.
At the moment the dashboard and the collected metric are inconsistent.