Cette page n'est pas encore disponible en français, sa traduction est en cours. Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.
Database Monitoring provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine.
The Agent collects telemetry directly from the database by logging in as a read-only user. Complete the following steps to enable Database Monitoring with your MySQL database:
MySQL on Azure VMs, Single Server, Flexible Server (Query Activity and Wait Event collection are not supported for Flexible Server)
Supported Agent versions
7.36.1+
Performance impact
The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.
Database Monitoring runs as an integration on top of the base Agent (see benchmarks).
Proxies, load balancers, and connection poolers
The Datadog Agent must connect directly to the host being monitored, preferably through the instance endpoint. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics.
Data security considerations
See Sensitive information for information about what data the Agent collects from your databases and how to ensure it is secure.
The agent also requires performance_schema.events_statements_* consumers to be set to ON to collect currently running queries. By default, Azure MySQL Database enables performance schema consumers so no additional configuration is required.
Starting from Agent v7.65, the Datadog Agent can collect schema information from MySQL databases. See the Collecting schemas section below for more info on how to grant the Agent permissions for this collection.
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.
To monitor Azure hosts, install the Datadog Agent in your infrastructure and configure it to connect to each instance endpoint remotely. The Agent does not need to run on the database, it only needs to connect to it. For additional Agent installation methods not mentioned here, see the Agent installation instructions.
To configure this check for an Agent running on a host, for example when you provision a small virtual machine for the Agent to collect from the database:
Edit the mysql.d/conf.yaml file, in the conf.d/ folder at the root of your Agent’s configuration directory to start collecting your MySQL metrics. See the sample mysql.d/conf.yaml for all available configuration options, including those for custom metrics.
Add this configuration block to your mysql.d/conf.yaml to collect MySQL metrics:
init_config:instances:- dbm:truehost:'<AZURE_INSTANCE_ENDPOINT>'port:3306username:datadogpassword:'ENC[datadog_user_database_password]'# from the CREATE USER step earlier, stored as a secret# After adding your project and instance, configure the Datadog Azure integration to pull additional cloud data such as CPU and Memory.azure:deployment_type:'<DEPLOYMENT_TYPE>'fully_qualified_domain_name:'<AZURE_INSTANCE_ENDPOINT>'
See the MySQL integration spec for additional information on setting deployment_type and name fields.
Note: Wrap your password in single quotes in case a special character is present.
To configure the Database Monitoring Agent running in a Docker container, you can set the Autodiscovery Integration Templates as Docker labels on your agent container.
Note: The Agent must have read permission on the Docker socket for Autodiscovery of labels to work.
See the MySQL integration spec for additional information on setting deployment_type and name fields.
If you have a Kubernetes cluster, use the Datadog Cluster Agent for Database Monitoring.
Follow the instructions to enable the cluster checks if not already enabled in your Kubernetes cluster. You can declare the MySQL configuration with static files mounted in the Cluster Agent container, or by using service annotations:
Complete the following steps to install the Datadog Cluster Agent on your Kubernetes cluster. Replace the values to match your account and environment.
To configure a cluster check with a mounted configuration file, mount the configuration file in the Cluster Agent container on the path /conf.d/mysql.yaml:
cluster_check:true# Make sure to include this flaginit_config:instances:- dbm:truehost:'<AZURE_INSTANCE_ENDPOINT>'port:3306username:datadogpassword:'ENC[datadog_user_database_password]'# 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>'fully_qualified_domain_name:'<AZURE_INSTANCE_ENDPOINT>'
Rather than mounting a file, you can declare the instance configuration as a Kubernetes Service. To configure this check for an Agent running on Kubernetes, create a Service in the same namespace as the Datadog Cluster Agent:
See the MySQL integration spec for additional information on setting deployment_type and name fields.
The Cluster Agent automatically registers this configuration and begins running the MySQL check.
To avoid exposing the datadog user’s password in plain text, use the Agent’s secret management package and declare the password using the ENC[] syntax.
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.
In these cases, Datadog recommends limiting the number of instances per Agent to a maximum of 10 database instances to guarantee reliable performance.
Starting from Agent v7.65, the Datadog Agent can collect schema information from MySQL databases. To enable this feature, use the schemas_collection option.
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:
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.