![]() NB! Note that there might not be an exact Postgres version match for helper definitions - then replace $pgver with the previousĪvailable version number below your server’s Postgres version number. Psql -f /etc/pgwatch2/metrics/00_helpers/get_sequences/$pgver/metric.sql mydb Psql -f /etc/pgwatch2/metrics/00_helpers/get_stat_statements/$pgver/metric.sql mydb Psql -f /etc/pgwatch2/metrics/00_helpers/get_wal_size/$pgver/metric.sql mydb Psql -f /etc/pgwatch2/metrics/00_helpers/get_stat_replication/$pgver/metric.sql mydb Psql -f /etc/pgwatch2/metrics/00_helpers/get_stat_activity/$pgver/metric.sql mydb NB! When monitoring v10+ servers then the built-in pg_monitor system role is recommended for the monitoring user, whichĪlmost substitutes superuser privileges for monitoring purposes in a safe way.įor completely unprivileged monitoring users the following helpers are recommended to make good use of the default ![]() For that use case there’s also a preset config Without these additional steps, you lose though aboutġ0-15% of built-in metrics, which might not be too tragical nevertheless. ![]() For local (push) setups as of pgwatch2 versionġ.8.4 the most typical OS metrics are covered by the “–direct-os-stats” flag, explained below.įor unprivileged monitoring users it is highly recommended to take these additional steps on the “to be monitored”ĭatabase to get maximum value out of pgwatch2 in the long run. If using a superuser login (recommended only for local “push” setups) you have full access toĪll Postgres metrics and would need helpers only for OS remote statistics. Metrics (like active session details, “per query” statistics) or even OS-level metrics, to normal unprivileged users, like the pgwatch2 Via such wrapper functions one can do controlled privilege escalation - i.e. Helper functions in pgwatch2 context are standard Postgres stored procedures, running under SECURITY DEFINER privileges.
0 Comments
Leave a Reply. |