Configuration de Database Monitoring pour les bases de données Azure et PostgreSQL
Docs >
Database Monitoring >
Configuration de Postgres >
Configuration de Database Monitoring pour les bases de données Azure et PostgreSQL
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 :
Types de déploiements Azure PostgreSQL pris en charge
PostgreSQL sur des VM Azure, un serveur unique et un serveur flexible
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 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 ni un outil de groupement de connexions comme pgbouncer. 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é.
Requis 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 sont pas recueillies.
pg_stat_statements.track
ALL
Facultatif. Active le suivi des déclarations dans les procédures et fonctions stockées.
pg_stat_statements.max
10000
Facultatif. 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.
track_io_timing
on
Facultatif. Active la collecte des durées de lecture et d’écriture des blocs pour les requêtes.
Paramètre
Valeur
Description
azure.extensions
pg_stat_statements
Requis pour les métriques postgresql.queries.*. Active la collecte de métriques de requête à l’aide de l’extension pg_stat_statements.
track_activity_query_size
4096
Requis 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 sont pas recueillies.
pg_stat_statements.track
ALL
Facultatif. Active le suivi des déclarations dans les procédures et fonctions stockées.
pg_stat_statements.max
10000
Facultatif. 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.
track_io_timing
on
Facultatif. Active la collecte des durées de lecture et d’écriture des blocs pour les requêtes.
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 connecte 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. Il est donc recommandé 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 figurant 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 :
CREATEUSERdatadogWITHpassword'<MOT_DE_PASSE>';
Créez le schéma suivant dans chaque base de données :
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 description de la 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.
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 mydb.example.com -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 mydb.example.com -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 mydb.example.com -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 mydb.example.com -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 mydb.example.com -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 mydb.example.com -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 bases de données Azure Postgres, 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 machine virtuelle pour l’Agent afin de recueillir des données depuis une base de données Azure, procédez comme suit :
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:truehost:'<AZURE_INSTANCE_ENDPOINT>'port:5432username:'datadog@<AZURE_INSTANCE_ENDPOINT>'password:'<PASSWORD>'ssl:true## 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>'# After adding your project and instance, configure the Datadog Azure integration to pull additional cloud data such as CPU, Memory, etc.azure:deployment_type:'<DEPLOYMENT_TYPE>'name:'<YOUR_INSTANCE_NAME>'
Pour configurer l’Agent Database Monitoring qui s’exécute dans un conteneur Docker, 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
Utilisez la commande suivante pour exécuter l’Agent depuis une interface de ligne de commande. Modifiez les valeurs de façon à indiquer votre compte et votre environnement :
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 :
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.
Si vous avez un cluster Kubernetes, utilisez l’Agent Datadog Cluster pour Database Monitoring.
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 :
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# Veiller à bien inclure ce flaginit_config:instances:- dbm:truehost:'<ENDPOINT_INSTANCE_AZURE>'port:5432username:'datadog@<ENDPOINT_INSTANCE_AZURE>'password:'<MOT_DE_PASSE>'ssl:true# Une fois le projet et l'instance ajoutés, configurer l'intégration Azure Datadog afin de récupérer des données cloud supplémentaires, notamment sur le CPU, la mémoire, etc.azure:deployment_type:'<TYPE_DÉPLOIEMENT>'name:'<NOM_INSTANCE>'## Requis : pour Postgres 9.6, supprimer la mise en commentaire des lignes suivantes afin d'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 :
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[].
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).
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:truehost:example-service-primary.example-host.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'database_autodiscovery:enabled:true# Optionally, set the include field to specify# a set of databases you are interested in discoveringinclude:- 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:truehost:localhostport:5432username:datadogpassword:'ENC[datadog_user_database_password]'custom_queries:- metric_prefix:employeequery:SELECT age, salary, hours_worked, name FROM hr.employees;columns:- name:custom.employee_agetype:gauge- name:custom.employee_salarytype:gauge- name:custom.employee_hourstype:count- name:nametype:tagtags:- '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:truehost:example-service-primary.example-host.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'database_autodiscovery:enabled:trueexclude:- ^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.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'dbname:usersdbstrict:truerelations:- 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.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'dbname:inventorydbstrict:truerelations:- relation_name:products- relation_name:external_seller_products
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 tablesinstances:- dbm:truehost:example-service-primary.example-host.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'dbname:usersdbstrict:truecollect_schemas:enabled:truerelations:- products- external_seller_products# This instance detects every logical database automatically# and collects relation metrics from every table- dbm:truehost:example-service–replica-1.example-host.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'database_autodiscovery:enabled:truecollect_schemas:enabled:truerelations:- 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.
Pour recueillir des métriques de base de données plus complètes depuis Azure, installez l’intégration Azure PostgreSQL (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: