Configuration de Database Monitoring pour Postgres avec une gestion sur Amazon RDS

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 la télémétrie directement depuis la base de données, en se connectant en tant qu’utilisateur en lecture seule. Suivez les étapes ci-dessous pour activer la solution Database Monitoring avec votre base de données Postgres :

  1. Configurer l’intégration AWS
  2. Configurer les paramètres de base de données
  3. Autoriser l’Agent à accéder à la base de données
  4. Installer et configurer l’Agent Datadog
  5. Installer l’intégration RDS
RDS Quick Install est notre méthode d'installation recommandée pour les environnements de petite taille (par exemple, 20 hosts de base de données) ou pour ceux qui découvrent DBM et souhaitent l'essayer rapidement. Pour ceux qui gèrent de grands parcs de bases de données pour lesquels le déploiement de l'Agent via l'interface utilisateur n'est pas aussi adapté, nous recommandons l'installation standard, afin de gérer l'Agent manuellement ou de l'intégrer à vos pratiques d'automatisation.

Avant de commencer

Versions de PostgreSQL prises en charge
9.6, 10, 11, 12, 13, 14, 15, 16, 17
Versions de l’Agent prises en charge
7.36.1 et versions ultérieures
Incidence sur les performances
La configuration par défaut de l’Agent pour Database Monitoring est relativement souple. Néanmoins, vous pouvez ajuster certains paramètres comme l’intervalle de collecte et le taux d’échantillonnage des requêtes pour mieux répondre à vos besoins. Pour la plupart des workloads, l’Agent monopolise 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 solution Database Monitoring de Datadog fonctionne comme une intégration et vient compléter l’Agent de base (voir les benchmarks).
Proxies, répartiteurs de charge et poolers de connexion
L’Agent Datadog doit se connecter directement au host surveillé. Pour les bases de données auto-hébergées, 127.0.0.1 ou le socket est préférable. L’Agent ne doit pas se connecter à la base de données via un proxy, un répartiteur de charge ou un pooler de connexion tel que pgbouncer. Si l’Agent se connecte à différents hosts pendant son exécution (comme dans le cas d’un basculement, d’un équilibrage de charge, etc.), il calcule la différence de statistiques entre deux hosts, ce qui produit des métriques inexactes.
Considérations relatives à la sécurité des données
Consultez la rubrique Informations sensibles pour découvrir les données recueillies par l’Agent à partir de vos bases de données et la méthode à suivre pour garantir leur sécurité.

Configurer l’intégration AWS

Activez Resource Collection dans la section Resource Collection de votre carré d’intégration Amazon Web Services.

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 en savoir plus sur ces paramètres, consultez la documentation Postgres.

ParamètreValeurDescription
shared_preload_librariespg_stat_statementsObligatoire pour les métriques postgresql.queries.*. Active la collecte de métriques de requêtes à l’aide de l’extension pg_stat_statements.
track_activity_query_size4096Obligatoire pour la collecte des requêtes plus longues. Augmente la taille du texte SQL dans pg_stat_activity. Si la valeur par défaut est conservée, les requêtes de plus de 1024 caractères ne seront pas collectées.
pg_stat_statements.trackALLFacultatif. Active le suivi des déclarations dans les procédures et fonctions stockées.
pg_stat_statements.max10000Facultatif. Augmente le nombre de requêtes normalisées suivies dans pg_stat_statements. Ce paramètre est recommandé pour les bases de données générant d’importants volumes ainsi que de nombreux types de requêtes à partir d’un grand nombre de clients.
pg_stat_statements.track_utilityoffFacultatif. Désactive les commandes utilitaires telles que PREPARE et EXPLAIN. Définir cette valeur sur off signifie que seules les requêtes de type SELECT, UPDATE et DELETE sont suivies.
track_io_timingonFacultatif. Active la collecte des durées de lecture et d’écriture des blocs pour les requêtes.

Activer auto_explain (facultatif)

Par défaut, l’Agent ne collecte des plans EXPLAIN que pour un échantillon de requêtes en cours d’exécution. Ces plans sont de nature plus générale, notamment lorsque le code de l’application utilise des prepared statements.

Pour collecter des plans EXPLAIN ANALYZE complets issus de toutes les requêtes, vous devez utiliser auto_explain, une extension native fournie avec PostgreSQL et disponible chez tous les principaux fournisseurs. La collecte de logs est un prérequis à la collecte auto_explain. Veillez donc à l’activer avant de continuer.

Important : auto_explain génère des lignes de log susceptibles de contenir des données d'application sensibles, similaires aux valeurs brutes dans du SQL non obfusqué. Utilisez l'autorisation dbm_parameterized_queries_read pour contrôler l'accès aux plans générés. Pour restreindre la visibilité des lignes de log elles-mêmes — visibles par défaut par tous les utilisateurs de votre organisation Datadog —, configurez également le RBAC pour les logs. Datadog recommande d'utiliser les deux autorisations pour protéger efficacement les informations sensibles.
  1. Configurez les paramètres auto_explain. Le format de log doit être json, mais les autres paramètres peuvent varier selon votre application. Cet exemple enregistre un plan EXPLAIN ANALYZE pour toutes les requêtes dépassant une seconde, en incluant les informations sur les buffers mais en omettant le timing (qui peut engendrer une surcharge).
ParamètreValeurDescription
shared_preload_librariespg_stat_statements,auto_explainActive EXPLAIN ANALYZE automatiquement
auto_explain.log_formatjsonGénère des plans lisibles par machine
auto_explain.log_min_duration1000Enregistre les plans lorsque les requêtes dépassent une seconde
auto_explain.log_analyzeonUtilise la forme ANALYZE de EXPLAIN
auto_explain.log_buffersonInclut l’utilisation des buffers dans les plans
auto_explain.log_timingoffN’inclut pas le timing (surcharge élevée)
auto_explain.log_triggersonInclut les plans pour les instructions de déclencheur
auto_explain.log_verboseonUtilise le type de plan verbose
auto_explain.log_nested_statementsonInclut les instructions imbriquées
auto_explain.sample_rate1Explique toutes les requêtes dépassant la durée
  1. Modifiez le log_line_prefix pour permettre une corrélation d’événements plus riche. Pour en savoir plus, consultez la documentation sur les groupes de paramètres DB RDS. L’ingestion auto_explain requiert que cette valeur soit définie sur %m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a.

  2. Pour vous assurer que vos instances RDS transfèrent les logs vers CloudWatch et Datadog, suivez les instructions relatives à la collecte de logs Amazon RDS.

Accorder un accès à l’Agent

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

Les commandes SQL suivantes doivent être exécutées sur le serveur de base de données primaire (le writer) dans le cluster si Postgres est répliqué. Choisissez une base de données PostgreSQL sur le serveur à laquelle l’Agent doit se connecter. L’Agent peut collecter des données de télémétrie depuis toutes les bases de données du serveur de base de données, quelle que soit celle à laquelle il se connecte. Il est donc conseillé d’utiliser la base de données postgres par défaut. Ne choisissez une autre base de données que si vous avez besoin que l’Agent exécute des requêtes custom sur des données propres à cette base de données.

Connectez-vous à la base de données choisie en tant que superutilisateur (ou un autre utilisateur disposant d’autorisations suffisantes). Par exemple, si la base de données choisie est postgres, connectez-vous en tant qu’utilisateur postgres à l’aide de psql en exécutant :

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 pour savoir comment la configurer pour votre instance RDS.

Accordez à l’utilisateur datadog l’autorisation d’accéder aux tables concernées :

ALTER ROLE datadog INHERIT;

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 schema public;

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 schema public;

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 tout le contenu 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 les métriques custom nécessitant d'interroger des tables supplémentaires, vous devrez peut-être accorder l'autorisation SELECT sur ces tables à l'utilisateur datadog. Exemple : grant SELECT on <TABLE_NAME> to datadog;. Consultez la page Collecte de métriques custom PostgreSQL pour en savoir plus.

Créez la fonction dans chaque base de données pour permettre à l’Agent de recueillir les plans d’exécution.

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;

Stocker 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érification

Pour vérifier que l’utilisateur de l’Agent possède les autorisations adéquates et qu’il parvient à se connecter à la base de données et à lire les principales tables, exécutez ce qui suit :

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

Lorsque vous êtes invité à saisir un mot de passe, indiquez celui que vous avez défini lors de la création de l’utilisateur datadog.

Installer et configurer l’Agent

Pour surveiller les hosts RDS, installez l’Agent Datadog dans votre infrastructure et configurez-le pour qu’il se connecte à distance à chaque endpoint d’instance. L’Agent n’a pas besoin de s’exécuter sur la base de données, il doit uniquement s’y connecter. Pour d’autres méthodes d’installation de l’Agent non mentionnées ici, consultez les instructions d’installation de l’Agent.

Pour configurer la collecte de métriques Database Monitoring pour un Agent s’exécutant sur un host, par exemple lorsque vous provisionnez une petite instance EC2 pour que l’Agent collecte des données depuis une base de données RDS :

  1. Modifiez le fichier postgres.d/conf.yaml afin de spécifier votre host / port et de définir les masters à surveiller. Consultez le fichier d’exemple postgres.d/conf.yaml pour découvrir 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>'
        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>'
    

    Pour les versions de l’Agent ≤ 7.49, ajoutez le paramètre suivant à la configuration de l’instance où host et port sont spécifiés :

    ssl: allow
    

    Si vous souhaitez vous authentifier avec IAM, spécifiez les paramètres region et instance_endpoint, et définissez managed_authentication.enabled sur true.

    Remarque : n’activez managed_authentication que si vous souhaitez utiliser l’authentification IAM. L’authentification IAM est prioritaire sur le champ password.

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

    Pour en savoir plus sur la configuration de l’authentification IAM sur votre instance RDS, consultez la section Connexion avec l’authentification gérée.

  2. Redémarrez l’Agent.

Pour configurer une intégration pour un Agent s’exécutant dans un conteneur Docker, par exemple dans ECS ou Fargate, plusieurs méthodes sont disponibles, toutes décrites en détail dans la documentation sur la configuration Docker.

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

Remarque : pour que le processus de découverte automatique des étiquettes fonctionne, l’Agent doit être autorisé à lire le socket Docker.

Ligne de commande

Exécutez la commande suivante depuis votre ligne de commande pour démarrer l’Agent. Remplacez les valeurs fictives par celles correspondant à votre compte et à 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 de l’instance spécifiant le host et le port :

"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, ce qui vous permet 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 de l’instance spécifiant le host et le port :

"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 clair, utilisez le package de gestion des secrets de l’Agent et déclarez le mot de passe à l’aide de la syntaxe ENC[]. Vous pouvez également consulter la documentation sur les template variables Autodiscovery pour fournir le mot de passe en tant que variable d’environnement.

Si vous exécutez un cluster Kubernetes, utilisez l’Agent de cluster Datadog pour activer Database Monitoring.

Remarque : vérifiez que les checks de cluster sont activés pour votre Agent de cluster Datadog avant de continuer.

Vous trouverez ci-dessous des instructions détaillées pour configurer l’intégration Postgres à l’aide de différentes méthodes de déploiement de l’Agent de cluster Datadog.

Operator

En vous référant aux instructions relatives à l’Operator dans Kubernetes et les intégrations, suivre 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 : Pour Postgres 9.6, ajoutez les lignes suivantes à la configuration de l’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()
    
  2. Appliquer les modifications à l’Operator Datadog à l’aide de la commande suivante :

    kubectl apply -f datadog-agent.yaml
    

Helm

En vous référant aux instructions relatives à Helm dans Kubernetes et les intégrations, suivre les étapes ci-dessous pour configurer l’intégration Postgres :

  1. Mettez à jour votre fichier datadog-values.yaml (utilisé dans les instructions d’installation de l’Agent de cluster) 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 : Pour Postgres 9.6, ajoutez les lignes suivantes à la configuration de l’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()
    
  2. Déployez l’Agent avec le fichier de configuration ci-dessus à l’aide de la commande suivante :

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

Configuration avec des fichiers montés

Pour configurer un check de cluster avec un fichier de configuration monté, montez le fichier de configuration dans le conteneur de l’Agent de cluster à l’emplacement suivant : /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>"

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

Configuration avec les annotations de service Kubernetes

Plutôt que de monter un fichier, vous pouvez déclarer la configuration de l’instance en tant que service Kubernetes. Pour configurer ce check pour un Agent s’exécutant sur Kubernetes, créez un service avec la syntaxe suivante :

Annotations Autodiscovery 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 en savoir plus, consultez la section Annotations Autodiscovery.

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 avec la syntaxe ENC[].

Validation

Exécutez la sous-commande status de l’Agent et recherchez postgres dans la section Checks. Ou consultez la page Bases de données pour commencer !

Exemples de configuration de l’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

Installer l’intégration RDS

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

Dépannage

Si vous avez respecté les instructions d’installation et de configuration des intégrations et de l’Agent, mais que vous rencontrez un problème, consultez la section Dépannage de la surveillance de bases de données.

Pour aller plus loin