influxdata / influxdata/telegraf
Add support for `SHOW TOTALS` metrics in the PgBouncer input plugin
- Dominant language
- Go
- Stars
- 17.8k
- Forks
- 5.8k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 161
Description
### Use Case
I use the Telegraf PgBouncer plugin to collect connection pool statistics. In environments with many pools/databases configured in PgBouncer, it becomes difficult to manage and analyze the metrics per-database. Having aggregated metrics would help monitor overall PgBouncer performance more efficiently and reduce metric cardinality in the output backend.
PgBouncer provides such aggregated stats via the `SHOW TOTALS` command. These totals are very useful, especially in large-scale setups.
### Expected behavior
Telegraf should collect PgBouncer totals (aggregated stats across all pools) by executing `SHOW TOTALS` and expose them in a new measurement, e.g., pgbouncer_totals. The fields would be similar to the existing pgbouncer measurement, but without the db tag.
Alternatively, this could be implemented by keeping the same pgbouncer measurement but using a special tag such as `db=__totals__ `or `db=TOTALS`.
### Actual behavior
Currently, the Telegraf PgBouncer plugin only collects per-database statistics using `SHOW STATS`. There is no way to collect aggregated totals directly. Computing global values manually is not accurate, especially for `avg_*_time` fields, which cannot be averaged across databases meaningfully.
### Additional info
PgBouncer reference: https://www.pgbouncer.org/usage.html#show-totals
Telegraf PgBouncer plugin: https://github.com/influxdata/telegraf/blob/master/plugins/inputs/pgbouncer/README.md
Contributor guide
Research direction
Start by inspecting the PgBouncer input plugin and its documentation in plugins/inputs/pgbouncer/README.md, then trace the existing SHOW STATS collection path. Define whether totals use a new measurement or a special db tag, implement collection of SHOW TOTALS fields, and verify that aggregated metrics omit or distinguish the database tag.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- observability-sre
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100