Configuration de Database Monitoring pour MySQL 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 MySQL, en exposant des métriques de requête, des échantillons de requête, des plans d’exécution, des données sur les connexions, des métriques système et des données de télémétrie à propos du moteur de stockage InnoDB.
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 MySQL :
- Configurer l’intégration AWS
- Configurer les paramètres de base de données
- Autoriser l’Agent à accéder à la base de données
- Installer et configurer l’Agent
- Installer l’intégration RDS
Avant de commencer
- Versions de MySQL prises en charge
- 5.6, 5.7 et 8.0+
- Versions MariaDB prises en charge
- 10.5, 10.6, ou 10.11
Database Monitoring pour MariaDB est pris en charge avec des limitations connues. - 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 connection poolers
- l’Agent Datadog doit se connecter directement au host surveillé, de préférence via l’endpoint de l’instance. L’Agent ne doit pas se connecter à la base de données via un proxy, un répartiteur de charge ou un connection pooler. 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é.
Activez Standard Collection dans la section Resource Collection de votre vignette d’intégration Amazon Web Services.
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 :
| Paramètre | Valeur | Description || — | — | — || performance_schema | 1 | Obligatoire. Active le Performance Schema. || max_digest_length | 4096 | Obligatoire pour la collecte des requêtes volumineuses. Augmente la taille du texte de résumé SQL dans les tables events_statements_*. Si la valeur par défaut est conservée, les requêtes de plus de 1024 caractères ne seront pas collectées. || performance_schema_max_digest_length | 4096 | Doit correspondre à max_digest_length. || performance_schema_max_sql_text_length | 4096 | Doit correspondre à max_digest_length. |
| Paramètre | Valeur | Description || — | — | — || performance_schema | 1 | Obligatoire. Active le Performance Schema. || max_digest_length | 4096 | Obligatoire pour la collecte des requêtes volumineuses. Augmente la taille du texte de résumé SQL dans les tables events_statements_*. Si la valeur par défaut est conservée, les requêtes de plus de 1024 caractères ne seront pas collectées. || performance_schema_max_digest_length | 4096 | Doit correspondre à max_digest_length. |
Accorder un accès à l’Agent
L’Agent Datadog requiert un accès en lecture seule pour la base de données, afin de pouvoir recueillir les statistiques et requêtes.
Les instructions suivantes autorisent l’Agent à se connecter depuis n’importe quel host à l’aide de datadog@'%'. Vous pouvez restreindre l’utilisateur datadog avec datadog@'localhost', de façon à ce qu’il soit uniquement autorisé à se connecter depuis localhost. Consultez la documentation MYSQL (en anglais) pour en savoir plus.
Créez l’utilisateur datadog et accordez-lui des autorisations de base :
CREATE USER datadog@'%' IDENTIFIED by '<UNIQUEPASSWORD>';
ALTER USER datadog@'%' WITH MAX_USER_CONNECTIONS 5;
GRANT REPLICATION CLIENT ON *.* TO datadog@'%';
GRANT PROCESS ON *.* TO datadog@'%';
GRANT SELECT ON performance_schema.* TO datadog@'%';
Créez l’utilisateur datadog et accordez-lui des autorisations de base :
CREATE USER datadog@'%' IDENTIFIED BY '<UNIQUEPASSWORD>';
GRANT REPLICATION CLIENT ON *.* TO datadog@'%' WITH MAX_USER_CONNECTIONS 5;
GRANT PROCESS ON *.* TO datadog@'%';
GRANT SELECT ON performance_schema.* TO datadog@'%';
Créez le schéma suivant :
CREATE SCHEMA IF NOT EXISTS datadog;
GRANT EXECUTE ON datadog.* to datadog@'%';
Créez la procédure explain_statement afin d’activer la collecte de plans d’exécution par l’Agent :
DELIMITER $$
CREATE PROCEDURE datadog.explain_statement(IN query TEXT)
SQL SECURITY DEFINER
BEGIN
SET @explain := CONCAT('EXPLAIN FORMAT=json ', query);
PREPARE stmt FROM @explain;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
END $$
DELIMITER ;
Créez également la procédure suivante dans chaque schéma pour lesquels vous souhaitez recueillir des plans d’exécution. Remplacez <YOUR_SCHEMA> par le schéma de votre base de données :
DELIMITER $$
CREATE PROCEDURE <YOUR_SCHEMA>.explain_statement(IN query TEXT)
SQL SECURITY DEFINER
BEGIN
SET @explain := CONCAT('EXPLAIN FORMAT=json ', query);
PREPARE stmt FROM @explain;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
END $$
DELIMITER ;
GRANT EXECUTE ON PROCEDURE <YOUR_SCHEMA>.explain_statement TO datadog@'%';
Pour collecter des métriques d’index, accorder à l’utilisateur datadog une autorisation supplémentaire :
GRANT SELECT ON mysql.innodb_index_stats TO datadog@'%';
À partir de l’Agent v7.65, l’Agent Datadog peut collecter des informations de schéma depuis les bases de données MySQL. Consulter la section Collecte de schémas ci-dessous pour en savoir plus sur l’octroi des autorisations nécessaires à l’Agent pour cette collecte.
Exécution des consommateurs de configuration
Avec RDS, les consommateurs du schéma de performances ne peuvent pas être activés de façon permanente dans une configuration. Créez la procédure suivante pour permettre à l’Agent d’activer les consommateurs performance_schema.events_* à l’exécution.
DELIMITER $$
CREATE PROCEDURE datadog.enable_events_statements_consumers()
SQL SECURITY DEFINER
BEGIN
UPDATE performance_schema.setup_consumers SET enabled='YES' WHERE name LIKE 'events_statements_%';
UPDATE performance_schema.setup_consumers SET enabled='YES' WHERE name = 'events_waits_current';
END $$
DELIMITER ;
GRANT EXECUTE ON PROCEDURE datadog.enable_events_statements_consumers TO datadog@'%';
Stocker votre mot de passe en toute sécurité
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.
Pour surveiller les hosts RDS, 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 ce check 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 RDS, procédez comme suit :
Modifiez le fichier mysql.d/conf.yaml dans le dossier conf.d/ à la racine du répertoire de configuration de votre Agent pour commencer à recueillir vos métriques MySQL. Consultez le fichier d’exemple mysql.d/conf.yaml pour découvrir toutes les options de configuration disponibles, notamment pour les métriques custom.
Ajoutez ce bloc de configuration à votre fichier mysql.d/conf.yaml pour recueillir des métriques MySQL :
init_config:
instances:
- dbm: true
host: '<AWS_INSTANCE_ENDPOINT>'
port: <PORT>
username: datadog
password: 'ENC[datadog_user_database_password]' # from the CREATE USER step earlier, stored as a secret
# After adding your project and instance, configure the Datadog AWS integration to pull additional cloud data such as CPU and Memory.
aws:
instance_endpoint: '<AWS_INSTANCE_ENDPOINT>'
region: <AWS_REGION>
Pour vous authentifier avec IAM, spécifiez les paramètres region et instance_endpoint, et définissez managed_authentication.enabled sur true.
Remarque : activez managed_authentication uniquement 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: <PORT>
username: datadog
aws:
instance_endpoint: '<AWS_INSTANCE_ENDPOINT>'
region: <AWS_REGION>
managed_authentication:
enabled: true
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.
Redémarrez l’Agent pour commencer à envoyer des métriques MySQL à Datadog.
Pour configurer l’Agent Database Monitoring qui s’exécute dans un conteneur Docker, par exemple dans 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=<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.check_names='["mysql"]' \
-l com.datadoghq.ad.init_configs='[{}]' \
-l com.datadoghq.ad.instances='[{
"dbm": true,
"host": "<AWS_INSTANCE_ENDPOINT>",
"port": <PORT>,
"username": "datadog",
"password": "<UNIQUEPASSWORD>",
"aws": {
"instance_endpoint": "<AWS_INSTANCE_ENDPOINT>",
"region": "<AWS_REGION>"
}
}]' \
registry.datadoghq.com/agent:${DD_AGENT_VERSION}
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 registry.datadoghq.com/agent:<AGENT_VERSION>
LABEL "com.datadoghq.ad.check_names"='["mysql"]'
LABEL "com.datadoghq.ad.init_configs"='[{}]'
LABEL "com.datadoghq.ad.instances"='[{"dbm": true, "host": "<AWS_INSTANCE_ENDPOINT>", "port": <PORT>,"username": "datadog","password": "ENC[datadog_user_database_password]", "aws": {"instance_endpoint": "<AWS_INSTANCE_ENDPOINT>", "region": "<AWS_REGION>"}}]'
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 MySQL avec des fichiers statiques montés dans le conteneur de l’Agent de cluster, ou avec des annotations de service :
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 MySQL :
Créer ou mettre à 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:
mysql.yaml: |-
cluster_check: true
init_config:
instances:
- host: <AWS_INSTANCE_ENDPOINT>
port: <PORT>
username: datadog
password: 'ENC[datadog_user_database_password]'
dbm: true
aws:
instance_endpoint: <AWS_INSTANCE_ENDPOINT>
region: <AWS_REGION>
Appliquer les modifications à l’Operator Datadog à l’aide de la commande suivante :
kubectl apply -f datadog-agent.yaml
Helm
Suivez les instructions d’installation de l’Agent Datadog pour Helm.
Mettez à jour votre fichier de configuration YAML (datadog-values.yaml dans les instructions d’installation de l’Agent de cluster) pour y inclure les éléments suivants :
clusterAgent:
confd:
mysql.yaml: |-
cluster_check: true
init_config:
instances:
- dbm: true
host: <AWS_INSTANCE_ENDPOINT>
port: <PORT>
username: datadog
password: 'ENC[datadog_user_database_password]'
aws:
instance_endpoint: <AWS_INSTANCE_ENDPOINT>
region: <AWS_REGION>
clusterChecksRunner:
enabled: true
Déployez l’Agent avec le fichier de configuration ci-dessus depuis la ligne de commande :
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/mysql.yaml.
cluster_check: true # Make sure to include this flag
init_config:
instances:
- dbm: true
host: '<AWS_INSTANCE_ENDPOINT>'
port: <PORT>
username: datadog
password: 'ENC[datadog_user_database_password]'
aws:
instance_endpoint: <AWS_INSTANCE_ENDPOINT>
region: <AWS_REGION>
Configuration avec les annotations de service Kubernetes
Plutôt que 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éer un service avec la syntaxe suivante :
apiVersion: v1
kind: Service
metadata:
name: mysql
labels:
tags.datadoghq.com/env: '<ENV>'
tags.datadoghq.com/service: '<SERVICE>'
annotations:
ad.datadoghq.com/service.check_names: '["mysql"]'
ad.datadoghq.com/service.init_configs: '[{}]'
ad.datadoghq.com/service.instances: |
[
{
"dbm": true,
"host": "<AWS_INSTANCE_ENDPOINT>",
"port": <PORT>,
"username": "datadog",
"password": "ENC[datadog_user_database_password]",
"aws": {
"instance_endpoint": "<AWS_INSTANCE_ENDPOINT>",
"region": "<AWS_REGION>"
}
}
]
spec:
ports:
- port: <PORT>
protocol: TCP
targetPort: <PORT>
name: mysql
L’Agent de cluster enregistre automatiquement cette configuration et commence à exécuter le check MySQL.
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 cherchez mysql dans la section Checks, ou consultez la page Databases 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 MySQL 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: 3306
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: 3306
username: datadog
password: 'ENC[datadog_user_database_password]'
options:
replication: true
tags:
- 'env:prod'
- 'team:team-discovery'
- 'service:example-service'
- dbm: true
host: example-service-replica-2.example-host.com
port: 3306
username: datadog
password: 'ENC[datadog_user_database_password]'
options:
replication: true
tags:
- 'env:prod'
- 'team:team-discovery'
- 'service:example-service'
[...]
Running custom queries
To collect custom metrics, use the custom_queries option. See the sample mysql.d/conf.yaml for more details.
init_config:
instances:
- dbm: true
host: localhost
port: 3306
username: datadog
password: 'ENC[datadog_user_database_password]'
custom_queries:
- 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'
Collecting schemas
Datadog Agent v7.65+ is required for MySQL schema collection.
To enable this feature, use the collect_schemas option. See the sample mysql.d/conf.yaml for more details.
init_config:
instances:
- dbm: true
host: localhost
port: 3306
username: datadog
password: 'ENC[datadog_user_database_password]'
collect_schemas:
enabled: true
Note: For Agent v7.68 and below, use schemas_collection instead of collect_schemas.
Note: To collect schemas for a table, MySQL requires that the Datadog Agent has SELECT access for it. This is a MySQL-enforced restriction. Without SELECT access, the table will not appear in metadata queries.
The Agent does not use SELECT to access or read your table data. This permission is needed solely to retrieve schema details, due to how MySQL handles metadata visibility.
To grant SELECT permissions to a Datadog user, use one or a combination of the following commands:
- All databases:
GRANT SELECT ON *.* TO datadog@'%';
- Per database basis:
GRANT SELECT ON [database name].* TO datadog@'%';
- Per table basis:
GRANT SELECT ON [database name].[table name] TO datadog@'%';
- Per column basis:
GRANT SELECT ([column name1], [column name 2]) ON [database name].[table name] TO datadog@'%';
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.
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles: