diff --git a/content/en/database_monitoring/setup_postgres/selfhosted.md b/content/en/database_monitoring/setup_postgres/selfhosted.md index ab5159dfe64..1331d22a6b2 100644 --- a/content/en/database_monitoring/setup_postgres/selfhosted.md +++ b/content/en/database_monitoring/setup_postgres/selfhosted.md @@ -1,5 +1,5 @@ --- -title: Setting Up Database Monitoring for self hosted Postgres +title: Setting Up Database Monitoring for Self-Hosted Postgres description: Install and configure Database Monitoring for self-hosted Postgres. further_reading: - link: "/integrations/postgres/" @@ -37,7 +37,7 @@ Performance impact Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][2]). Proxies, load balancers, and connection poolers -: The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, `127.0.0.1` or the socket is preferred. The Agent should not connect to the database through a proxy, load balancer, or connection pooler such as `pgbouncer`. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. +: The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, use `127.0.0.1` or the socket. The Agent should not connect to the database through a proxy, load balancer, or connection pooler such as `pgbouncer`. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. Data security considerations : See [Sensitive information][3] for information about what data the Agent collects from your databases and how to ensure it is secure. @@ -46,22 +46,29 @@ Data security considerations Configure the following [parameters][4] in the `postgresql.conf` file and then **restart the server** for the settings to take effect. For more information about these parameters, see the [Postgres documentation][5]. +**Required parameters** + | Parameter | Value | Description | | --- | --- | --- | | `shared_preload_libraries` | `pg_stat_statements` | Required for `postgresql.queries.*` metrics. Enables collection of query metrics using the [pg_stat_statements][5] extension. | | `track_activity_query_size` | `4096` | Required for collection of larger queries. Increases the size of SQL text in `pg_stat_activity`. If left at the default value then queries longer than `1024` characters will not be collected. | -| `pg_stat_statements.track` | `ALL` | Optional. Enables tracking of statements within stored procedures and functions. | -| `pg_stat_statements.max` | `10000` | Optional. Increases the number of normalized queries tracked in `pg_stat_statements`. This setting is recommended for high-volume databases that see many different types of queries from many different clients. | -| `pg_stat_statements.track_utility` | `off` | Optional. Disables utility commands like PREPARE and EXPLAIN. Setting this value to `off` means only queries like SELECT, UPDATE, and DELETE are tracked. | -| `track_io_timing` | `on` | Optional. Enables collection of block read and write times for queries. | + +**Optional parameters** + +| Parameter | Value | Description | +| --- | --- | --- | +| `pg_stat_statements.track` | `ALL` | Enables tracking of statements within stored procedures and functions. | +| `pg_stat_statements.max` | `10000` | Increases the number of normalized queries tracked in `pg_stat_statements`. Recommended for high-volume databases that see many different types of queries from many different clients. | +| `pg_stat_statements.track_utility` | `off` | Disables utility commands like PREPARE and EXPLAIN. Setting this value to `off` means only queries like SELECT, UPDATE, and DELETE are tracked. | +| `track_io_timing` | `on` | Enables collection of block read and write times for queries. | ## Grant the Agent access -The Datadog Agent requires read-only access to the database server in order to collect statistics and queries. +The Datadog Agent requires read-only access to the database server to collect statistics and queries. -The following SQL commands should be executed on the **primary** database server (the writer) in the cluster if Postgres is replicated. Choose a PostgreSQL database on the database server for the Agent to connect to. The Agent can collect telemetry from all databases on the database server regardless of which one it connects to, so a good option is to use the default `postgres` database. Choose a different database only if you need the Agent to run [custom queries against data unique to that database][6]. +Run the following SQL commands on the **primary** database server (the writer) in the cluster if Postgres is replicated. The Agent can collect telemetry from all databases on the server regardless of which database it connects to. Use the default `postgres` database unless you need the Agent to run [custom queries against data unique to a different database][6]. -Connect to the chosen database as a superuser (or another user with sufficient permissions). For example, if your chosen database is `postgres`, connect as the `postgres` user using [psql][7] by running: +Connect to your chosen database as a superuser (or another user with sufficient permissions). For example, to connect to the `postgres` database using [psql][7]: ```bash psql -h mydb.example.com -d postgres -U postgres @@ -138,7 +145,9 @@ SECURITY DEFINER;
SELECT permission on those tables to the datadog user. Example: grant SELECT on <TABLE_NAME> to datadog;. See PostgreSQL custom metric collection for more information. auto_explain produces logs lines that may contain sensitive information from your application, similar to the raw values that appear in non-obfuscated SQL. You can use the dbm_parameterized_queries_read permission to control who can see the resulting plans, but the log lines themselves are visible to all users within your Datadog org. Using RBAC for Logs helps ensure these logs are only visible to the right users.
@@ -316,7 +326,7 @@ After you enable logging collection:
4. [Restart the Agent][10].
-### Validate
+### Verify Agent setup
[Run the Agent's status subcommand][13] and look for `postgres` under the Checks section. Or visit the [Databases][14] page to get started!
@@ -325,7 +335,7 @@ After you enable logging collection:
## Troubleshooting
-If you have installed and configured the integrations and Agent as described and it is not working as expected, see [Troubleshooting][15]
+If you have installed and configured the integrations and Agent as described and it is not working as expected, see [Troubleshooting][15].
## Further reading
@@ -346,6 +356,5 @@ If you have installed and configured the integrations and Agent as described and
[13]: /agent/configuration/agent-commands/#agent-status-and-information
[14]: https://app.datadoghq.com/databases
[15]: /database_monitoring/troubleshooting/?tab=postgres
-[16]: /agent/configuration/agent-commands/#restart-the-agent
[17]: https://www.postgresql.org/docs/current/sql-explain.html
[18]: https://www.postgresql.org/docs/current/auto-explain.html