Proceeding with non default settings in PG monitoring with pg_stat_monitor
General
Escalation
General
Escalation
Description
The problem:
Users can change some defaults of PG_stat_monitor (pgsm) extension and add the PG server to PMM. This will lead to incorrect processing of data and presentation of them in PMM.
We don't want, as for now, to invest in covering all possible options on the PMM side so the approach is: verify the expected defaults of pgsm and warn the user that the options are NOT optimal.
Questions: How we should proceed with "unrecommended defaults"?
advise/warn users only
warn and stop adding a system to monitoring. Allow to use "–force" flag for users to still add Service to PMM
don't have official user flag to overcome this defaults verification but have some PERCONA_TEST flag to overwrite the limitation (very internal flag )
List of PGSM settings we expect to be critical as defaults:
pg_stat_monitor.pgsm_normalized_query = 0. We need examples as advantages against default extension
pg_stat_monitor.pgsm_normalized_query = 2048 . We need longer queries to be tracked then 1024
pg_stat_monitor.pgsm_bucket_time = 60 . others values will brake qan presentation
pg_stat_monitor.pgsm_histogram_min , pg_stat_monitor.pgsm_histogram_max , pg_stat_monitor.pgsm_histogram_buckets = 0, 100000, 10. = We expect 10 ranges of histograms . if this changes - it's almost impossible to do histograms right on flight.
Original report:
pg_stat_monitor.pgsm_normalized_query selects whether save query in normalized format. This is disabled by default.
We should show warning to users that once pg_stat_monitor.pgsm_normalized_query is enabled it will effect query examples - user will see "Sorry, no examples found for this query" when checking Examples tab in QAN.
The problem:
Users can change some defaults of PG_stat_monitor (pgsm) extension and add the PG server to PMM. This will lead to incorrect processing of data and presentation of them in PMM.
We don't want, as for now, to invest in covering all possible options on the PMM side so the approach is: verify the expected defaults of pgsm and warn the user that the options are NOT optimal.
Questions: How we should proceed with "unrecommended defaults"?
advise/warn users only
warn and stop adding a system to monitoring. Allow to use "–force" flag for users to still add Service to PMM
don't have official user flag to overcome this defaults verification but have some PERCONA_TEST flag to overwrite the limitation (very internal flag )
UX:
TBD
pmm-admin add postgresql --query-source=pgstatmonitor ....
List of PGSM settings we expect to be critical as defaults:
pg_stat_monitor.pgsm_normalized_query = 0. We need examples as advantages against default extension
pg_stat_monitor.pgsm_normalized_query = 2048 . We need longer queries to be tracked then 1024
pg_stat_monitor.pgsm_bucket_time = 60 . others values will brake qan presentation
pg_stat_monitor.pgsm_histogram_min , pg_stat_monitor.pgsm_histogram_max , pg_stat_monitor.pgsm_histogram_buckets = 0, 100000, 10. = We expect 10 ranges of histograms . if this changes - it's almost impossible to do histograms right on flight.
Original report:
pg_stat_monitor.pgsm_normalized_query selects whether save query in normalized format. This is disabled by default.
We should show warning to users that once pg_stat_monitor.pgsm_normalized_query is enabled it will effect query examples - user will see "Sorry, no examples found for this query" when checking Examples tab in QAN.
Add message to pmm-admin add postgresql
Add to documentation