Configuration de Database Monitoring pour Postgres avec une gestion sur Aurora

La solution Database Monitoring n'est pas prise en charge pour ce site.

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êtes et des plans d’exécution, ainsi que 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 Database Monitoring pour votre base de données Postgres :

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

Avant de commencer

Versions de PostgresSQL prises en charge
9.6, 10, 11, 12, 13
Versions de l’Agent prises en charge
7.33.0+
Incidence sur les performances
La configuration par défaut de l’Agent Datadog 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 fonctionne comme une intégration et vient compléter l’Agent de base (voir les benchmarks).
Proxies, répartiteurs de charge et outils de regroupement de connexions
L’Agent doit se connecter directement au host surveillé. Pour les bases de données auto-hébergées, il est préférable d’utiliser 127.0.0.1 ou le socket. L’Agent ne doit pas se connecter aux bases de données via un proxy, un répartiteur de charge, un outil de regroupement de connexions comme pgbouncer ni l’endpoint du cluster Aurora. Bien qu’il puisse s’agir d’un antipattern pour des applications client, chaque Agent doit connaître le hostname sous-jacent et rester sur un seul host pendant toute sa durée de vie, même en cas de failover. Si l’Agent Datadog se connecte à plusieurs hosts pendant son exécution, les valeurs des métriques seront incorrectes.
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 les paramètres Postgres

Configurez les paramètres suivants dans le groupe de paramètres de base de données. Redémarrez ensuite le serveur pour appliquer la configuration. Pour en savoir plus sur ces paramètres, consultez la documentation Postgres (en anglais).

ParamètreValeurDescription
shared_preload_librariespg_stat_statementsRequis pour les métriques postgresql.queries.*. Active la collecte de métriques de requête via l’extension pg_stat_statements. Activé par défaut dans Aurora.
track_activity_query_size4096Requis pour la collecte de requêtes volumineuses. Augmente la taille du texte SQL dans pg_stat_activity et pg_stat_statements. Si vous conservez la valeur par défaut, les requêtes comportant plus de 1024 caractères ne seront pas recueillies.
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.

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.

Choisissez la base de données PostgresSQL à laquelle l’Agent se connectera sur le serveur dédié. L’Agent peut recueillir la télémétrie de toutes les bases de données sur ce serveur, peu importe celle à laquelle il se connecte. Datadog vous conseille donc d’utiliser la base de données postgres par défaut. Choisissez une autre base de données uniquement si l’Agent doit exécuter des requêtes personnalisées sur des données stockées uniquement dans cette base de données.

Connectez-vous à la base de données en tant que super-utilisateur (ou en tant qu’un autre utilisateur avec les autorisations nécessaires). Par exemple, pour la base de données postgres, exécutez ce qui suit pour vous connecter en tant qu’utilisateur postgres avec psql :

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

Créez l’utilisateur datadog :

CREATE USER datadog WITH password '<MOT_DE_PASSE>';

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

Remarque : pour créer des métriques custom nécessitant d’interroger des tables supplémentaires, vous devrez peut-être accorder à l’utilisateur datadog l’autorisation SELECT pour ces tables. Exemple de commande : grant SELECT on <NOM_TABLE> to datadog;. Pour en savoir plus, consultez la section Collecte de métriques custom Postgres.

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

Vérifier la configuration

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 l’Agent

Pour surveiller les hosts Aurora, installez l’Agent Datadog dans votre infrastructure et configurez-le de façon à ce 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 simplement s’y connecter. Pour obtenir d’autres méthodes d’installation de l’Agent, 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 si vous provisionnez une petite instance EC2 pour l’Agent afin de recueillir des données depuis une base de données Aurora, procédez comme suit :

  1. Modifiez le fichier postgres.d/conf.yaml afin de pointer vers 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: '<ENDPOINT_INSTANCE_AWS>'
        port: 5432
        username: datadog
        password: '<MOT_DE_PASSE>'
        ## Requis : pour Postgres 9.6, supprimer la mise en commentaire de ces lignes pour utiliser les fonctions créées dans la configuration
        # pg_stat_statements_view: datadog.pg_stat_statements()
        # pg_stat_activity_view: datadog.pg_stat_activity()
        ## Facultatif : connexion à une autre base de données si nécessaire pour `custom_queries`
        # dbname: '<NOM_BASE_DE_DONNÉES>'
    
Important : utilisez l'endpoint de l'instance Aurora ici, mais pas l'endpoint du cluster.
  1. Redémarrez l’Agent.

Pour configurer l’Agent Database Monitoring qui s’exécute dans un conteneur Docker, par exemple pour ECS ou Fargate, vous pouvez définir des modèles d’intégration Autodiscovery en tant qu’étiquettes Docker sur le conteneur de votre Agent.

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

Ligne de commande

Pour exécuter rapidement l’Agent depuis une interface de ligne de commande, utilisez la commande suivante. Modifiez les valeurs de façon à indiquer votre compte et votre environnement :

export DD_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
export DD_AGENT_VERSION=7.32.0

docker run -e "DD_API_KEY=${DD_API_KEY}" \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -l com.datadoghq.ad.check_names='["postgres"]' \
  -l com.datadoghq.ad.init_configs='[{}]' \
  -l com.datadoghq.ad.instances='[{
    "dbm": true,
    "host": "<ENDPOINT_INSTANCE_AWS>",
    "port": 5432,
    "username": "datadog",
    "password": "<MOT_DE_PASSE_UNIQUE>"
  }]' \
  gcr.io/datadoghq/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. Cette approche vous permet de concevoir et de déployer un Agent personnalisé sans avoir à modifier la configuration de l’infrastructure :

FROM gcr.io/datadoghq/agent:7.32.0

LABEL "com.datadoghq.ad.check_names"='["postgres"]'
LABEL "com.datadoghq.ad.init_configs"='[{}]'
LABEL "com.datadoghq.ad.instances"='[{"dbm": true, "host": "<ENDPOINT_INSTANCE_AWS>", "port": 5432,"username": "datadog","password": "<MOT_DE_PASSE_UNIQUE>"}]'
Important : utilisez l'endpoint de l'instance Aurora en tant que host, mais pas l'endpoint du cluster.

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[]. Sinon, consultez la section Template variables Autodiscovery pour découvrir comment transmettre le mot de passe en tant que variable d’environnement.

Pour surveiller des bases de données sur un cluster Kubernetes, utilisez l’Agent de cluster Datadog.

Si vous n’avez pas encore activé les checks de cluster dans votre cluster Kubernetes, suivez ces instructions. Vous pouvez déclarer la configuration Postgres avec des fichiers statiques montés dans le conteneur de l’Agent de cluster, ou avec des annotations de service :

Ligne de commande avec Helm

Exécutez la commande Helm suivante pour installer l’Agent de cluster Datadog sur votre cluster Kubernetes. Modifiez les valeurs de façon à indiquer votre compte et votre environnement :

helm repo add datadog https://helm.datadoghq.com
helm repo update

helm install <NOM_VERSION> \
  --set 'datadog.apiKey=<CLÉ_API_DATADOG>' \
  --set 'clusterAgent.enabled=true' \
  --set "clusterAgent.confd.postgres\.yaml=cluster_check: true
init_config:
instances:
  - dbm: true
    host: <ADRESSE_INSTANCE>
    port: 5432
    username: datadog
    password: <MOT_DE_PASSE_UNIQUE" \
  datadog/datadog

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

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  # Bien inclure ce flag
init_config:
instances:
  - dbm: true
    host: '<ADRESSE_INSTANCE>'
    port: 5432
    username: datadog
    password: '<MOT_DE_PASSE>'
    ## Requis : pour Postgres 9.6, supprimer la mise en commentaire de ces lignes pour utiliser les fonctions créées dans la configuration
    # pg_stat_statements_view: datadog.pg_stat_statements()
    # pg_stat_activity_view: datadog.pg_stat_activity()

Configuration avec les annotations de service Kubernetes

Au lieu de monter un fichier, vous pouvez déclarer la configuration d’instance en tant que service Kubernetes. Pour configurer ce check pour un Agent s’exécutant sur Kubernetes, créez un service dans le même espace de nommage que l’Agent de cluster Datadog :

apiVersion: v1
kind: Service
metadata:
  name: postgres
  labels:
    tags.datadoghq.com/env: '<ENVIRONNEMENT>'
    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": "<ENDPOINT_INSTANCE_AWS>",
          "port": 5432,
          "username": "datadog",
          "password": "<MOT_DE_PASSE_UNIQUE>"
        }
      ]      
spec:
  ports:
  - port: 5432
    protocol: TCP
    targetPort: 5432
    name: postgres
Important : utilisez l'endpoint de l'instance Aurora ici, mais pas l'endpoint du cluster Aurora.

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

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 clair, utilisez le package de gestion des secrets de l’Agent et déclarez le mot de passe à l’aide de la syntaxe ENC[].

Validation

Lancez la sous-commande status de l’Agent et cherchez postgres dans la section Checks. Vous pouvez également consulter la page Databases pour commencer à surveiller vos bases de données.

Installer l’intégration RDS

Pour recueillir des métriques de base de données plus complètes depuis AWS, 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.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles: