Skip to content

Latest commit

 

History

History
502 lines (388 loc) · 20 KB

_index.md

File metadata and controls

502 lines (388 loc) · 20 KB
title description further_reading
Setting Up Database Monitoring for Amazon RDS managed Postgres
Install and configure Database Monitoring for Postgres on Amazon RDS.
link tag text
/integrations/postgres/
Documentation
Basic Postgres Integration

Database Monitoring provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events.

The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your Postgres database:

  1. Configure the AWS integration
  2. Configure database parameters
  3. Grant the Agent access to the database
  4. Install and configure the Agent
  5. Install the RDS integration
RDS Quick Install is the recommended method for monitoring individual RDS Postgres instances.

Before you begin

Supported PostgreSQL versions : 9.6, 10, 11, 12, 13, 14, 15, 16

Supported Agent versions : 7.36.1+

Performance impact : The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

Database Monitoring runs as an integration on top of the base Agent (see benchmarks).

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.

Data security considerations : See Sensitive information for information about what data the Agent collects from your databases and how to ensure it is secure.

Configure the AWS integration

Enable Standard Collection in the Resource Collection section of your Amazon Web Services integration tile.

Configure Postgres settings

Configure the following parameters in the DB parameter group and then restart the server for the settings to take effect. For more information about these parameters, see the Postgres documentation.

Parameter Value Description
shared_preload_libraries pg_stat_statements Required for postgresql.queries.* metrics. Enables collection of query metrics using the pg_stat_statements 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.

Grant the Agent access

The Datadog Agent requires read-only access to the database server in order 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 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.

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 by running:

psql -h mydb.example.com -d postgres -U postgres

Create the datadog user:

CREATE USER datadog WITH password '<PASSWORD>';

Note: IAM authentication is also supported. Please see the guide on how to configure this for your RDS instance.

{{< tabs >}} {{% tab "Postgres ≥ 15" %}}

Give the datadog user permission to relevant tables:

ALTER ROLE datadog INHERIT;

Create the following schema in every database:

CREATE SCHEMA datadog;
GRANT USAGE ON SCHEMA datadog TO datadog;
GRANT USAGE ON SCHEMA public TO datadog;
GRANT pg_monitor TO datadog;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements schema public;

{{% /tab %}}

{{% tab "Postgres ≥ 10" %}}

Create the following schema in every database:

CREATE SCHEMA datadog;
GRANT USAGE ON SCHEMA datadog TO datadog;
GRANT USAGE ON SCHEMA public TO datadog;
GRANT pg_monitor TO datadog;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements schema public;

{{% /tab %}} {{% tab "Postgres 9.6" %}}

Create the following schema in every database:

CREATE SCHEMA datadog;
GRANT USAGE ON SCHEMA datadog TO datadog;
GRANT USAGE ON SCHEMA public TO datadog;
GRANT SELECT ON pg_stat_database TO datadog;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Create functions in every database to enable the Agent to read the full contents of pg_stat_activity and pg_stat_statements:

CREATE OR REPLACE FUNCTION datadog.pg_stat_activity() RETURNS SETOF pg_stat_activity AS
  $$ SELECT * FROM pg_catalog.pg_stat_activity; $$
LANGUAGE sql
SECURITY DEFINER;
CREATE OR REPLACE FUNCTION datadog.pg_stat_statements() RETURNS SETOF pg_stat_statements AS
    $$ SELECT * FROM pg_stat_statements; $$
LANGUAGE sql
SECURITY DEFINER;

{{% /tab %}} {{< /tabs >}}

For data collection or custom metrics that require querying additional tables, you may need to grant the 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.

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

CREATE OR REPLACE FUNCTION datadog.explain_statement(
   l_query TEXT,
   OUT explain JSON
)
RETURNS SETOF JSON AS
$$
DECLARE
curs REFCURSOR;
plan JSON;

BEGIN
   OPEN curs FOR EXECUTE pg_catalog.concat('EXPLAIN (FORMAT JSON) ', l_query);
   FETCH curs INTO plan;
   CLOSE curs;
   RETURN QUERY SELECT plan;
END;
$$
LANGUAGE 'plpgsql'
RETURNS NULL ON NULL INPUT
SECURITY DEFINER;

Securely store your password

{{% dbm-secret %}}

Verify

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: {{< tabs >}} {{% tab "Postgres ≥ 10" %}}

psql -h localhost -U datadog postgres -A \
  -c "select * from pg_stat_database limit 1;" \
  && 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;" \
  && 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;" \
  && echo -e "\e[0;32mPostgres pg_stat_statements read OK\e[0m" \
  || echo -e "\e[0;31mCannot read from pg_stat_statements\e[0m"

{{% /tab %}} {{% tab "Postgres 9.6" %}}

psql -h localhost -U datadog postgres -A \
  -c "select * from pg_stat_database limit 1;" \
  && 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;" \
  && 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;" \
  && echo -e "\e[0;32mPostgres pg_stat_statements read OK\e[0m" \
  || echo -e "\e[0;31mCannot read from pg_stat_statements\e[0m"

{{% /tab %}} {{< /tabs >}}

When it prompts for a password, use the password you entered when you created the datadog user.

Install and configure the Agent

To monitor RDS hosts, install the Datadog Agent in your infrastructure and configure it to connect to each instance endpoint remotely. The Agent does not need to run on the database, it only needs to connect to it. For additional Agent installation methods not mentioned here, see the Agent installation instructions.

{{< tabs >}} {{% tab "Host" %}}

To configure collecting Database Monitoring metrics for an Agent running on a host, for example when you provision a small EC2 instance for the Agent to collect from an RDS database:

  1. Edit the postgres.d/conf.yaml file to point to your host / port and set the masters to monitor. See the sample postgres.d/conf.yaml for all available configuration options.

    init_config:
instances:
  - dbm: true
    host: '<AWS_INSTANCE_ENDPOINT>'
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    tags:
      - "dbinstanceidentifier:<DB_INSTANCE_NAME>"
    ## Required for Postgres 9.6: Uncomment these lines to use the functions created in the setup
    # pg_stat_statements_view: datadog.pg_stat_statements()
    # pg_stat_activity_view: datadog.pg_stat_activity()
    ## Optional: Connect to a different database if needed for `custom_queries`
    # dbname: '<DB_NAME>'

    For Agent versions ≤ 7.49, add the following setting to the instance config where host and port are specified:

    ssl: allow

    If you want to authenticate with IAM, specify the region and instance_endpoint parameters, and set managed_authentication.enabled to true.

    Note: only enable managed_authentication if you want to use IAM authentication. IAM authentication takes precedence over the password field.

    init_config:
instances:
  - dbm: true
    host: '<AWS_INSTANCE_ENDPOINT>'
    port: 5432
    username: datadog
    aws:
      instance_endpoint: '<AWS_INSTANCE_ENDPOINT>'
      region: '<REGION>'
      managed_authentication:
        enabled: true
    tags:
      - "dbinstanceidentifier:<DB_INSTANCE_NAME>"
    ## Required for Postgres 9.6: Uncomment these lines to use the functions created in the setup
    # pg_stat_statements_view: datadog.pg_stat_statements()
    # pg_stat_activity_view: datadog.pg_stat_activity()
    ## Optional: Connect to a different database if needed for `custom_queries`
    # dbname: '<DB_NAME>'

    For information on configuring IAM authentication on your RDS instance, see Connecting with Managed Authentication.

  2. Restart the Agent.

{{% /tab %}} {{% tab "Docker" %}}

To configure the Database Monitoring Agent running in a Docker container such as in ECS or Fargate, you can set the Autodiscovery Integration Templates as Docker labels on your agent container.

Note: The Agent must have read permission on the Docker socket for Autodiscovery of labels to work.

Command line

Get up and running quickly by executing the following command to run the agent from your command line. Replace the values to match your account and environment:

export DD_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
export DD_AGENT_VERSION=7.36.1

docker run -e "DD_API_KEY=${DD_API_KEY}" \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -l com.datadoghq.ad.checks='{"postgres": {
    "init_config": {},
    "instances": [{
      "dbm": true,
      "host": "<AWS_INSTANCE_ENDPOINT>",
      "port": 5432,
      "username": "datadog",
      "password": "<UNIQUEPASSWORD>",
      "tags": ["dbinstanceidentifier:<DB_INSTANCE_NAME>"]
    }]
  }}' \
  gcr.io/datadoghq/agent:${DD_AGENT_VERSION}

For Postgres 9.6, add the following settings to the instance config where host and port are specified:

pg_stat_statements_view: datadog.pg_stat_statements()
pg_stat_activity_view: datadog.pg_stat_activity()

Dockerfile

Labels can also be specified in a Dockerfile, so you can build and deploy a custom agent without changing any infrastructure configuration:

FROM gcr.io/datadoghq/agent:7.36.1

LABEL "com.datadoghq.ad.check_names"='["postgres"]'
LABEL "com.datadoghq.ad.init_configs"='[{}]'
LABEL "com.datadoghq.ad.instances"='[{"dbm": true, "host": "<AWS_INSTANCE_ENDPOINT>", "port": 5432,"username": "datadog","password": "ENC[datadog_user_database_password]","tags": ["dbinstanceidentifier:<DB_INSTANCE_NAME>"]}]'

For Postgres 9.6, add the following settings to the instance config where host and port are specified:

pg_stat_statements_view: datadog.pg_stat_statements()
pg_stat_activity_view: datadog.pg_stat_activity()

To avoid exposing the datadog user's password in plain text, use the Agent's secret management package and declare the password using the ENC[] syntax, or see the Autodiscovery template variables documentation to learn how to pass the password as an environment variable.

{{% /tab %}} {{% tab "Kubernetes" %}}

If you have a Kubernetes cluster, use the Datadog Cluster Agent for Database Monitoring.

Follow the instructions to enable the cluster checks if not already enabled in your Kubernetes cluster. You can declare the Postgres configuration either with static files mounted in the Cluster Agent container or using service annotations:

Helm

Complete the following steps to install the Datadog Cluster Agent on your Kubernetes cluster. Replace the values to match your account and environment.

  1. Complete the Datadog Agent installation instructions for Helm.

  2. Update your YAML configuration file (datadog-values.yaml in the Cluster Agent installation instructions) to include the following:

    clusterAgent:
  confd:
    postgres.yaml: |-
      cluster_check: true
      init_config:
      instances:
      - dbm: true
        host: <INSTANCE_ADDRESS>
        port: 5432
        username: datadog
        password: 'ENC[datadog_user_database_password]'
        tags:
          - 'dbinstanceidentifier:<DB_INSTANCE_NAME>'

clusterChecksRunner:
  enabled: true

    For Postgres 9.6, add the following settings to the instance config where host and port are specified:

    pg_stat_statements_view: datadog.pg_stat_statements()
pg_stat_activity_view: datadog.pg_stat_activity()

  3. Deploy the Agent with the above configuration file from the command line:

    helm install datadog-agent -f datadog-values.yaml datadog/datadog
For Windows, append --set targetSystem=windows to the helm install command.

Configure with mounted files

To configure a cluster check with a mounted configuration file, mount the configuration file in the Cluster Agent container on the path: /conf.d/postgres.yaml:

cluster_check: true  # Make sure to include this flag
init_config:
instances:
  - dbm: true
    host: '<AWS_INSTANCE_ENDPOINT>'
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    tags:
      - dbinstanceidentifier:<DB_INSTANCE_NAME>
    ## Required: For Postgres 9.6, uncomment these lines to use the functions created in the setup
    # pg_stat_statements_view: datadog.pg_stat_statements()
    # pg_stat_activity_view: datadog.pg_stat_activity()

Configure with Kubernetes service annotations

Rather than mounting a file, you can declare the instance configuration as a Kubernetes Service. To configure this check for an Agent running on Kubernetes, create a Service in the same namespace as the Datadog Cluster Agent:

apiVersion: v1
kind: Service
metadata:
  name: postgres
  labels:
    tags.datadoghq.com/env: '<ENV>'
    tags.datadoghq.com/service: '<SERVICE>'
  annotations:
    ad.datadoghq.com/service.check_names: '["postgres"]'
    ad.datadoghq.com/service.init_configs: '[{}]'
    ad.datadoghq.com/service.instances: |
      [
        {
          "dbm": true,
          "host": "<AWS_INSTANCE_ENDPOINT>",
          "port": 5432,
          "username": "datadog",
          "password": "ENC[datadog_user_database_password]",
          "tags": [
            "dbinstanceidentifier:<DB_INSTANCE_NAME>"
          ]
        }
      ]
spec:
  ports:
  - port: 5432
    protocol: TCP
    targetPort: 5432
    name: postgres

For Postgres 9.6, add the following settings to the instance config where host and port are specified:

pg_stat_statements_view: datadog.pg_stat_statements()
pg_stat_activity_view: datadog.pg_stat_activity()

The Cluster Agent automatically registers this configuration and begin running the Postgres check.

To avoid exposing the datadog user's password in plain text, use the Agent's secret management package and declare the password using the ENC[] syntax.

{{% /tab %}} {{< /tabs >}}

Validate

Run the Agent's status subcommand and look for postgres under the Checks section. Or visit the Databases page to get started!

Example Agent Configurations

{{% dbm-postgres-agent-config-examples %}}

Install the RDS Integration

To see infrastructure metrics from AWS, such as CPU, alongside the database telemetry in DBM, install the RDS integration (optional).

Troubleshooting

If you have installed and configured the integrations and Agent as described and it is not working as expected, see Troubleshooting

Further reading

{{< partial name="whats-next/whats-next.html" >}}