Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 32 additions & 23 deletions content/en/database_monitoring/setup_postgres/selfhosted.md
Original file line number Diff line number Diff line change
@@ -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/"
Expand Down Expand Up @@ -37,7 +37,7 @@
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.

Check notice on line 40 in content/en/database_monitoring/setup_postgres/selfhosted.md

View workflow job for this annotation

GitHub Actions / vale

Datadog.sentencelength

Suggestion: Try to keep your sentence length to 25 words or fewer.

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.
Expand All @@ -46,22 +46,29 @@

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
Expand Down Expand Up @@ -138,7 +145,9 @@

<div class="alert alert-info">For data collection or custom metrics that require querying additional tables, you may need to grant the <code>SELECT</code> permission on those tables to the <code>datadog</code> user. Example: <code>grant SELECT on &lt;TABLE_NAME&gt; to datadog;</code>. See <a href="https://docs.datadoghq.com/integrations/faq/postgres-custom-metric-collection-explained/">PostgreSQL custom metric collection</a> for more information. </div>

Create the function **in every database** to enable the Agent to collect explain plans.
### Create the explain plan function

Create the following function **in every database** to enable the Agent to collect explain plans:

```SQL
CREATE OR REPLACE FUNCTION datadog.explain_statement(
Expand Down Expand Up @@ -168,7 +177,7 @@
### Securely store your password
{{% dbm-secret %}}

### Verify
### Verify database permissions

To verify the permissions are correct, run the following commands to confirm the Agent user is able to connect to the database and read the core tables:

Expand Down Expand Up @@ -199,11 +208,11 @@
&& echo -e "\e[0;32mPostgres connection - OK\e[0m" \
|| echo -e "\e[0;31mCannot connect to Postgres\e[0m"
psql -h localhost -U datadog postgres -A \
-c "select * from pg_stat_activity limit 1;" \
-c "select * from datadog.pg_stat_activity() limit 1;" \
&& echo -e "\e[0;32mPostgres pg_stat_activity read OK\e[0m" \
|| echo -e "\e[0;31mCannot read from pg_stat_activity\e[0m"
psql -h localhost -U datadog postgres -A \
-c "select * from pg_stat_statements limit 1;" \
-c "select * from datadog.pg_stat_statements() limit 1;" \
&& echo -e "\e[0;32mPostgres pg_stat_statements read OK\e[0m" \
|| echo -e "\e[0;31mCannot read from pg_stat_statements\e[0m"
```
Expand All @@ -216,7 +225,7 @@
## Install the Agent

Installing the Datadog Agent also installs the Postgres check, which is required for Database Monitoring on Postgres.
If you haven't installed the Agent, see the [Agent installation instructions][8]. Then, return here to continue with the instructions for your installation method.
If you haven't installed the Agent, see the [Agent installation instructions][8]. Then, continue with the instructions for your installation method.

Edit the Agent's `conf.d/postgres.d/conf.yaml` file to point to the Postgres instance you want to monitor. For a complete list of configuration options, see the [sample postgres.d/conf.yaml][9].

Expand All @@ -235,11 +244,11 @@

**Note**: If your password includes special characters, wrap it in single quotes.

[Restart the Agent][16] to apply the changes.
[Restart the Agent][10] to apply the changes.

### Collecting logs (optional)

PostgreSQL default logging is to `stderr`, and logs do not include detailed information. It is recommended to log into a file with additional details specified in the log line prefix. Refer to the PostgreSQL [documentation][11] on this topic for additional details.
PostgreSQL default logging is to `stderr`, and logs do not include detailed information. Log into a file with additional details specified in the log line prefix. See the PostgreSQL [documentation][11] for details.

Check warning on line 251 in content/en/database_monitoring/setup_postgres/selfhosted.md

View workflow job for this annotation

GitHub Actions / vale

Datadog.words_case_insensitive

Use 'log in to' instead of 'Log into'.

1. Logging is configured within the file `/etc/postgresql/<VERSION>/main/postgresql.conf`. For regular log results, including statement outputs, set the following parameters in the log section:
```conf
Expand All @@ -250,9 +259,10 @@
## For Windows
#log_destination = 'eventlog'
```
2. To gather detailed duration metrics and make them searchable in the Datadog interface, they should be configured inline with the statement themselves. See below for the recommended configuration differences from above and note that both `log_statement` and `log_duration` options are commented out. See discussion on this topic [here][12].
2. To gather detailed duration metrics and make them searchable in the Datadog interface, configure them inline with the statement. The recommended configuration below logs all statements and their durations. To reduce output to statements above a certain duration, set `log_min_duration_statement` to the desired minimum in milliseconds. Check that logging the full SQL statement complies with your organization's privacy requirements.

**Note**: Both `log_statement` and `log_duration` options are commented out. See discussion on this topic [here][12].

This config logs all statements, but to reduce the output to those which have a certain duration, set the `log_min_duration_statement` value to the desired minimum duration in milliseconds (check that logging the full SQL statement complies with your organization's privacy requirements):
```conf
log_min_duration_statement = 0 # -1 is disabled, 0 logs all statements
# and their durations, > 0 logs only
Expand All @@ -261,7 +271,7 @@
#log_statement = 'all'
#log_duration = on
```
3. Collecting logs is disabled by default in the Datadog Agent, enable it in your `datadog.yaml` file:
3. Collecting logs is disabled by default in the Datadog Agent. Enable it in your `datadog.yaml` file:
```yaml
logs_enabled: true
```
Expand All @@ -285,7 +295,7 @@

By default, the agent only gathers [`EXPLAIN`][17] plans for a sampling of in-flight queries. These plans are of a more general nature, especially when application code uses prepared statements.

To collect full `EXPLAIN ANALYZE` plans taken from all queries, you need to use [`auto_explain`][18], a first-party extension bundled with PostgreSQL available in all major providers. _Logging collection is a prerequisite to `auto_explain` collection_, so be sure to enable it before continuing.
To collect full `EXPLAIN ANALYZE` plans taken from all queries, you need to use [`auto_explain`][18], a first-party extension bundled with PostgreSQL available in all major providers. _Logging collection is a prerequisite to `auto_explain` collection_, so enable it before continuing.

<div class="alert alert-danger">
<strong>Important:</strong> <code>auto_explain</code> 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 <a href="/account_management/rbac/permissions/#database-monitoring"><code>dbm_parameterized_queries_read</code></a> permission to control who can see the resulting plans, but the log lines themselves <i>are</i> visible to all users within your Datadog org. Using <a href="/logs/guide/logs-rbac">RBAC for Logs</a> helps ensure these logs are only visible to the right users.
Expand Down Expand Up @@ -316,7 +326,7 @@

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!

Expand All @@ -325,7 +335,7 @@

## 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

Expand All @@ -346,6 +356,5 @@
[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
Loading