Configuration de la surveillance de bases de données pour Postgres avec un gestion sur Aurora

La solution Database Monitoring vous permet de bénéficier d’une visibilité complète sur vos bases de données Postgres, en exposant des métriques de requête, des échantillons de requête, des plans d’exécution, des états, des failovers et des événements de base de données.

L’Agent recueille les données de télémétrie directement depuis la base de données, en se connectant en tant qu’utilisateur en lecture seule. Effectuez la configuration suivante pour activer la surveillance de la base de données avec votre base de données Postgres :

  1. Configurer les paramètres de la base de données
  2. Accorder l’accès à l’Agent à la base de données
  3. Installer et configurer l’Agent
  4. Installer l’intégration RDS

Avant de commencer

Versions PostgreSQL prises en charge
9.6, 10, 11, 12, 13, 14, 15, 16, 17
Versions de l’Agent prises en charge
7.36.1+
Impact sur la performance
La configuration par défaut de l’Agent pour la surveillance de la base de données est conservatrice, mais vous pouvez ajuster des paramètres tels que l’intervalle de collecte et le taux d’échantillonnage des requêtes pour mieux répondre à vos besoins. Pour la plupart des charges de travail, l’Agent représente moins d’un pour cent du temps d’exécution des requêtes sur la base de données et moins d’un pour cent du CPU.

La surveillance de la base de données fonctionne comme une intégration au-dessus de l’Agent de base (voir les benchmarks).
Proxies, équilibreurs de charge et gestionnaires de connexions
L’Agent Datadog doit se connecter directement à l’hôte surveillé. Pour les bases de données auto-hébergées, utilisez 127.0.0.1 ou le socket. L’Agent ne doit pas se connecter à la base de données via un proxy, un équilibreur de charge, un gestionnaire de connexions tel que pgbouncer, ou le point de terminaison du cluster Aurora. S’il est connecté au point de terminaison du cluster, l’Agent collecte des données d’une réplique aléatoire et ne fournit de visibilité que sur cette réplique. Si l’Agent se connecte à différents hôtes pendant son fonctionnement (comme dans le cas d’un basculement, de l’équilibrage de charge, etc.), l’Agent calcule la différence de statistiques entre deux hôtes, ce qui entraîne des métriques inexactes.
Considérations relatives à la sécurité des données
Voir Informations sensibles pour des informations sur les données que l’Agent collecte de vos bases de données et comment s’assurer qu’elles sont sécurisées.

Configurer les paramètres Postgres

Configurez les paramètres suivants dans le groupe de paramètres DB puis redémarrez le serveur pour que les paramètres prennent effet. Pour plus d’informations sur ces paramètres, consultez la documentation Postgres.

Paramètres requis

ParamètreValeurDescription
shared_preload_librariespg_stat_statementsRequis pour postgresql.queries.* les métriques. Active la collecte des métriques de requête à l’aide de l’extension pg_stat_statements. Activé par défaut dans Aurora.
track_activity_query_size4096Requis pour la collecte de requêtes plus volumineuses. Augmente la taille du texte SQL dans pg_stat_activity. Si la valeur par défaut est utilisée, les requêtes de plus de 1024 caractères ne seront pas collectées.

Paramètres optionnels

ParamètreValeurDescription
pg_stat_statements.trackALLActive le suivi des instructions dans les procédures stockées et les fonctions.
pg_stat_statements.max10000Augmente le nombre de requêtes normalisées suivies dans pg_stat_statements. Recommandé pour les bases de données à fort volume qui reçoivent de nombreux types de requêtes en provenance de divers clients.
pg_stat_statements.track_utilityoffDésactive les commandes utilitaires comme PREPARE et EXPLAIN. Définir cette valeur à off signifie que seules les requêtes comme SELECT, UPDATE et DELETE sont suivies.
track_io_timingonPermet de collecter les temps de lecture et d’écriture des blocs pour les requêtes.

Accordez à l’Agent l’accès

L’Agent Datadog requiert un accès en lecture seule pour le serveur de la base de données, afin de pouvoir recueillir les statistiques et requêtes.

Exécutez les commandes SQL suivantes sur le serveur de base de données principal (le writer) dans le cluster si Postgres est répliqué. L’Agent peut collecter des télémétries de toutes les bases de données sur le serveur, peu importe à laquelle il se connecte. Utilisez la base de données par défaut postgres à moins que vous n’ayez besoin que l’Agent exécute des requêtes personnalisées sur des données uniques à une autre base de données.

Connectez-vous à votre base de données choisie en tant que superutilisateur (ou un autre utilisateur avec des autorisations suffisantes). Par exemple, pour se connecter à la base de données postgres en utilisant psql :

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

Créez l’utilisateur datadog :

CREATE USER datadog WITH password '<PASSWORD>';

Remarque : L’authentification IAM est également prise en charge. Consultez le guide sur la façon de configurer cela pour votre instance Aurora.

Créez le schéma suivant dans chaque base de données :

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;

Créez le schéma suivant dans chaque base de données :

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;

Créez des fonctions dans chaque base de données pour permettre à l’Agent de lire le contenu complet de pg_stat_activity et 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;
Pour la collecte de données ou pour des métriques personnalisées nécessitant des requêtes sur des tables supplémentaires, vous devrez peut-être accorder l'autorisation sur ces tables à l'utilisateur. SELECT permission sur ces tables au datadog utilisateur. Exemple : grant SELECT on <TABLE_NAME> to datadog;Voir la collecte de métriques personnalisées PostgreSQL pour plus d'informations.

Créez la fonction de plan d’explication

Créez la fonction suivante dans chaque base de données pour permettre à l’Agent de collecter des plans d’explication :

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

BEGIN
   SET TRANSACTION READ ONLY;

   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;

Stockez votre mot de passe de manière sécurisée

Store your password using secret management software such as Vault. You can then reference this password as ENC[<SECRET_NAME>] in your Agent configuration files: for example, ENC[datadog_user_database_password]. See Secrets Management for more information.

The examples on this page use datadog_user_database_password to refer to the name of the secret where your password is stored. It is possible to reference your password in plain text, but this is not recommended.

Vérifiez les autorisations de la base de données

Pour vérifier que les permissions sont correctes, exécutez les commandes suivantes pour confirmer que l’utilisateur Agent est capable de se connecter à la base de données et lire les tables principales :

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

Lorsqu’il vous demande un mot de passe, utilisez le mot de passe que vous avez saisi lors de la création de l’utilisateur datadog.

Installez et configurez l’Agent

Pour surveiller les hôtes Aurora, installez l’Agent Datadog dans votre infrastructure et configurez-le pour se connecter à chaque point de terminaison d’instance à distance. L’Agent n’a pas besoin de s’exécuter sur la base de données, il doit seulement se connecter à celle-ci. Pour des méthodes d’installation supplémentaires de l’Agent non mentionnées ici, consultez les instructions d’installation de l’Agent.

L’Agent Datadog prend en charge l’autodécouverte pour tous les points de terminaison Aurora au sein d’un cluster.

Si vous avez besoin de configurations différentes pour des instances spécifiques, ou si vous préférez spécifier manuellement les points de terminaison Aurora, suivez la section de configuration manuelle ci-dessous. Sinon, Datadog recommande d’utiliser les instructions de configuration de l’autodécouverte pour les clusters de bases de données Aurora.

Pour configurer la collecte des métriques de surveillance de la base de données pour un Agent s’exécutant sur un hôte, par exemple lorsque vous provisionnez une petite instance EC2 pour que l’Agent collecte des données d’une base de données Aurora :

  1. Modifiez le fichier postgres.d/conf.yaml pour pointer vers votre host / port et définissez les maîtres à surveiller. Consultez le fichier exemple postgres.d/conf.yaml pour toutes les options de configuration disponibles.

    init_config:
    instances:
      - dbm: true
        host: '<AWS_INSTANCE_ENDPOINT>'
        port: 5432
        username: datadog
        password: 'ENC[datadog_user_database_password]'
        aws:
          instance_endpoint: '<AWS_INSTANCE_ENDPOINT>'
          region: '<REGION>'
    
        ## Optional: Connect to a different database if needed for `custom_queries`
        # dbname: '<DB_NAME>'
    
Utilisez le point de terminaison de l'instance Aurora ici, pas le point de terminaison du cluster.
  1. Redémarrez l’Agent.

Pour configurer une intégration pour un Agent s’exécutant dans un conteneur Docker tel que dans ECS ou Fargate, vous disposez de plusieurs méthodes, toutes couvertes en détail dans la documentation de configuration Docker.

Les exemples ci-dessous montrent comment utiliser les étiquettes Docker et les modèles d’autodécouverte pour configurer l’intégration Postgres.

Remarque : L’Agent doit avoir l’autorisation de lecture sur le socket Docker pour que l’autodécouverte des étiquettes fonctionne.

Ligne de commande

Exécutez la commande suivante depuis votre ligne de commande pour démarrer l’Agent. Remplacez les valeurs de remplacement par celles de votre compte et de votre environnement.

export DD_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
export DD_AGENT_VERSION=<AGENT_VERSION>

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>",
       "aws": {
         "instance_endpoint": "<AWS_INSTANCE_ENDPOINT>",
         "region": "<REGION>"
       },
      "tags": ["dbinstanceidentifier:<DB_INSTANCE_NAME>"]
    }]
  }}' \
  registry.datadoghq.com/agent:${DD_AGENT_VERSION}

Pour Postgres 9.6, ajoutez les paramètres suivants à la configuration d’instance où l’hôte et le port sont spécifiés :

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

Dockerfile

Vous pouvez également spécifier des étiquettes dans un Dockerfile, vous permettant de créer et de déployer un Agent personnalisé sans modifier la configuration de votre infrastructure :

FROM registry.datadoghq.com/agent:<AGENT_VERSION>

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]","aws": {"instance_endpoint": "<AWS_INSTANCE_ENDPOINT>", "region": "<REGION>"}, "tags": ["dbinstanceidentifier:<DB_INSTANCE_NAME>"]}]'

Pour Postgres 9.6, ajoutez les paramètres suivants à la configuration d’instance où l’hôte et le port sont spécifiés :

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

Pour éviter d’exposer le mot de passe de l’utilisateur datadog en texte clair, utilisez le package de gestion des secrets de l’Agent et déclarez le mot de passe en utilisant la syntaxe ENC[]. Alternativement, consultez la documentation des variables de modèle d’autodécouverte pour fournir le mot de passe en tant que variable d’environnement.

Si vous exécutez un cluster Kubernetes, utilisez le Datadog Cluster Agent pour activer la surveillance de la base de données.

Remarque : Assurez-vous que les vérifications de cluster sont activées pour votre Datadog Cluster Agent avant de continuer.

Voici des instructions étape par étape pour configurer l’intégration Postgres en utilisant différentes méthodes de déploiement du Datadog Cluster Agent.

Opérateur

En utilisant les instructions de l’Opérateur dans Kubernetes et Intégrations comme référence, suivez les étapes ci-dessous pour configurer l’intégration Postgres :

  1. Créez ou mettez à jour le fichier datadog-agent.yaml avec la configuration suivante :

    apiVersion: datadoghq.com/v2alpha1
    kind: DatadogAgent
    metadata:
      name: datadog
    spec:
      global:
        clusterName: <CLUSTER_NAME>
        site: <DD_SITE>
        credentials:
          apiSecret:
            secretName: datadog-agent-secret
            keyName: api-key
    
      features:
        clusterChecks:
          enabled: true
    
      override:
        nodeAgent:
          image:
            name: agent
            tag: <AGENT_VERSION>
    
        clusterAgent:
          extraConfd:
            configDataMap:
              postgres.yaml: |-
                cluster_check: true
                init_config:
                instances:
                - host: <AWS_INSTANCE_ENDPOINT>
                  port: 5432
                  username: datadog
                  password: 'ENC[datadog_user_database_password]'
                  dbm: true
                  aws:
                    instance_endpoint: <AWS_INSTANCE_ENDPOINT>
                    region: <REGION>
                  tags:
                  - "dbinstanceidentifier:<DB_INSTANCE_NAME>"
    

    Note: For Postgres 9.6, add the following lines 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()
    
  2. Appliquez les modifications à l’Opérateur Datadog en utilisant la commande suivante :

    kubectl apply -f datadog-agent.yaml
    

Helm

En utilisant les instructions Helm dans Kubernetes et Intégrations comme référence, suivez les étapes ci-dessous pour configurer l’intégration Postgres :

  1. Mettez à jour votre fichier datadog-values.yaml (utilisé dans les instructions d’installation du Cluster Agent) avec la configuration suivante :

    datadog:
      clusterChecks:
        enabled: true
    
    clusterChecksRunner:
      enabled: true
    
    clusterAgent:
      enabled: true
      confd:
        postgres.yaml: |-
          cluster_check: true
          init_config:
          instances:
          - dbm: true
            host: <AWS_INSTANCE_ENDPOINT>
            port: 5432
            username: datadog
            password: 'ENC[datadog_user_database_password]'
            aws:
              instance_endpoint: <AWS_INSTANCE_ENDPOINT>
              region: <REGION>
            tags:
            - "dbinstanceidentifier:<DB_INSTANCE_NAME>"
    

    Note: For Postgres 9.6, add the following lines 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()
    
  2. Déployez l’Agent avec le fichier de configuration ci-dessus en utilisant la commande suivante :

    helm install datadog-agent -f datadog-values.yaml datadog/datadog
    
Pour Windows, ajoutez --set targetSystem=windows au helm install commande.

Configurez avec des fichiers montés

Pour configurer un cluster avec un fichier de configuration monté, montez le fichier de configuration dans le conteneur Cluster Agent à l’emplacement : /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]'
    aws:
      instance_endpoint: <AWS_INSTANCE_ENDPOINT>
      region: <REGION>
    tags:
    - "dbinstanceidentifier:<DB_INSTANCE_NAME>"

Configurez avec les annotations de service Kubernetes

Au lieu de monter un fichier, vous pouvez déclarer la configuration de l’instance en tant que service Kubernetes. Pour configurer cette vérification pour un Agent fonctionnant sur Kubernetes, créez un service en utilisant la syntaxe suivante :

Annotations d’autodécouverte v2

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

Pour plus d’informations, voir Annotations d’autodécouverte.

Si vous utilisez Postgres 9.6, ajoutez ce qui suit à la configuration de l’instance :

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

L’Agent de cluster enregistre automatiquement cette configuration et commence à exécuter le check Postgres.

Pour éviter d’exposer le mot de passe de l’utilisateur datadog en texte clair, utilisez le package de gestion des secrets de l’Agent et déclarez le mot de passe en utilisant la syntaxe ENC[].

Vérifiez la configuration de l’Agent

Exécutez la sous-commande d’état de l’Agent et recherchez postgres dans la section Vérifications. Ou visitez la page Bases de données pour commencer!

Exemples de configurations d’Agent

One agent connecting to multiple hosts

It is common to configure a single Agent host to connect to multiple remote database instances (see Agent installation architectures for DBM). To connect to multiple hosts, create an entry for each host in the Postgres integration config.

Datadog recommends using one Agent to monitor no more than 30 database instances.

Benchmarks show that one Agent running on a t4g.medium EC2 instance (2 CPUs and 4GB of RAM) can successfully monitor 30 RDS db.t3.medium instances (2 CPUs and 4GB of RAM).
init_config:
instances:
  - dbm: true
    host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:example-service'
  - dbm: true
    host: example-service–replica-1.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:example-service'
  - dbm: true
    host: example-service–replica-2.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:example-service'
    [...]

Monitoring multiple databases on a database host

Use the database_autodiscovery option to permit the Agent to discover all databases on your host to monitor. You can specify include or exclude fields to narrow the scope of databases discovered. See the sample postgres.d/conf.yaml for more details.

init_config:
instances:
  - dbm: true
    host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    database_autodiscovery:
      enabled: true
      # Optionally, set the include field to specify
      # a set of databases you are interested in discovering
      include:
        - mydb.*
        - example.*
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:example-service'

Running custom queries

To collect custom metrics, use the custom_queries option. See the sample postgres.d/conf.yaml for more details.

init_config:
instances:
  - dbm: true
    host: localhost
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    custom_queries:
    - metric_prefix: employee
      query: SELECT age, salary, hours_worked, name FROM hr.employees;
      columns:
        - name: custom.employee_age
          type: gauge
        - name: custom.employee_salary
           type: gauge
        - name: custom.employee_hours
           type: count
        - name: name
           type: tag
      tags:
        - 'table:employees'

Monitoring relation metrics for multiple databases

In order to collect relation metrics (such as postgresql.seq_scans, postgresql.dead_rows, postgresql.index_rows_read, and postgresql.table_size), the Agent must be configured to connect to each database (by default, the Agent only connects to the postgres database).

Specify a single “DBM” instance to collect DBM telemetry from all databases. Use the database_autodiscovery option to avoid specifying each database name.

init_config:
instances:
  # This instance is the "DBM" instance. It will connect to the
  # all logical databases, and send DBM telemetry from all databases
  - dbm: true
    host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    database_autodiscovery:
      enabled: true
      exclude:
        - ^users$
        - ^inventory$
    relations:
      - relation_regex: .*
  # This instance only collects data from the `users` database
  # and collects relation metrics from tables prefixed by "2022_"
  - host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    dbname: users
    dbstrict: true
    relations:
      - relation_regex: 2022_.*
        relkind:
          - r
          - i
  # This instance only collects data from the `inventory` database
  # and collects relation metrics only from the specified tables
  - host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    dbname: inventory
    dbstrict: true
    relations:
      - relation_name: products
      - relation_name: external_seller_products

Collecting schemas

To enable this feature, use the collect_schemas option. You must also configure the Agent to connect to each logical database.

Use the database_autodiscovery option to avoid specifying each logical database. See the sample postgres.d/conf.yaml for more details.

init_config:
# This instance only collects data from the `users` database
# and collects relation metrics only from the specified tables
instances:
  - dbm: true
    host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    dbname: users
    dbstrict: true
    collect_schemas:
      enabled: true
    relations:
      - products
      - external_seller_products
  # This instance detects every logical database automatically
  # and collects relation metrics from every table
  - dbm: true
    host: example-service–replica-1.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    database_autodiscovery:
      enabled: true
    collect_schemas:
      enabled: true
    relations:
      - relation_regex: .*

Working with hosts through a proxy

If the Agent must connect through a proxy such as the Cloud SQL Auth proxy, all telemetry is tagged with the hostname of the proxy rather than the database instance. Use the reported_hostname option to set a custom override of the hostname detected by the Agent.

init_config:
instances:
  - dbm: true
    host: localhost
    port: 5000
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    reported_hostname: example-service-primary
  - dbm: true
    host: localhost
    port: 5001
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    reported_hostname: example-service-replica-1

Installez l’intégration RDS

Pour voir les métriques d’infrastructure d’AWS, telles que le CPU, aux côtés de la télémétrie de la base de données directement dans DBM, installez l’intégration RDS (optionnel).

Dépannage

Si vous avez installé et configuré les intégrations et l’Agent comme décrit et que cela ne fonctionne pas comme prévu, consultez Dépannage.

Lectures complémentaires