- Essentials
- In The App
- Infrastructure
- Application Performance
- Log Management
- Security Platform
- UX Monitoring
- Administration
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. Do the following setup to enable Database Monitoring with your MySQL database:
Configure the following Database Flags and then restart the server for the settings to take effect:
Parameter | Value | Description |
---|---|---|
performance_schema | on | Required. Enables the Performance Schema. |
max_digest_length | 4096 | Required for collection of larger queries. Increases the size of SQL digest text in events_statements_* tables. If left at the default value then queries longer than 1024 characters will not be collected. |
| 4096 | Must match max_digest_length . |
Parameter | Value | Description |
---|---|---|
performance_schema | on | Required. Enables the Performance Schema. |
max_digest_length | 4096 | Required for collection of larger queries. Increases the size of SQL digest text in events_statements_* tables. If left at the default value then queries longer than 1024 characters will not be collected. |
| 4096 | Must match max_digest_length . |
| 4096 | Must match max_digest_length . |
The Datadog Agent requires read-only access to the database in order to collect statistics and queries.
The following instructions grant the Agent permission to login from any host using datadog@'%'
. You can restrict the datadog
user to be allowed to login only from localhost by using datadog@'localhost'
. See the MySQL documentation for more info.
Create the datadog
user and grant basic permissions:
CREATE USER datadog@'%' IDENTIFIED WITH mysql_native_password 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@'%';
Create the datadog
user and grant basic permissions:
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@'%';
Create the following schema:
CREATE SCHEMA IF NOT EXISTS datadog;
GRANT EXECUTE ON datadog.* to datadog@'%';
GRANT CREATE TEMPORARY TABLES ON datadog.* TO datadog@'%';
Create the the explain_statement
procedure to enable the Agent to collect explain plans:
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 ;
Additionally, create this procedure in every schema from which you want to collect explain plans. Replace <YOUR_SCHEMA>
with your database schema:
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@'%';
Datadog recommends that you create the following procedure to give the Agent the ability to enable performance_schema.events_*
consumers at runtime.
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@'%';
Verify the user was created successfully using the following commands, replacing <UNIQUEPASSWORD>
with the password you created above:
mysql -u datadog --password=<UNIQUEPASSWORD> -e "show status" | \
grep Uptime && echo -e "\033[0;32mMySQL user - OK\033[0m" || \
echo -e "\033[0;31mCannot connect to MySQL\033[0m"
mysql -u datadog --password=<UNIQUEPASSWORD> -e "show slave status" && \
echo -e "\033[0;32mMySQL grant - OK\033[0m" || \
echo -e "\033[0;31mMissing REPLICATION CLIENT grant\033[0m"
To monitor Cloud SQL hosts, install the Datadog Agent in your infrastructure and configure it to connect to each instance 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 GCE instance for the Agent to collect from a Google Cloud SQL database:
Edit the mysql.d/conf.yaml
file, in the conf.d/
folder at the root of your Agent’s configuration directory. 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: true
host: '<INSTANCE_ADDRESS>'
port: 3306
username: datadog
password: '<UNIQUEPASSWORD>' # from the CREATE USER step earlier
# After adding your project and instance, configure the Datadog GCP integration to pull additional cloud data such as CPU, Memory, etc.
gcp:
project_id: '<PROJECT_ID>'
instance_id: '<INSTANCE_ID>'
Note: Wrap your password in single quotes in case a special character is present.
See the MySQL integration spec for additional information on setting project_id
and instance_id
fields.
Restart the Agent to start sending MySQL metrics to Datadog.
To configure the Database Monitoring Agent running in a Docker container such as in Google Cloud Run, 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.
Get up and running quickly by executing the following command to run the agent from your command line. Replace the values to match your account and environment:
export DD_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
export DD_AGENT_VERSION=7.36.1
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": "<INSTANCE_ADDRESS>",
"port": 3306,
"username": "datadog",
"password": "<UNIQUEPASSWORD>",
"gcp": {
"project_id": "<PROJECT_ID>",
"instance_id": "<INSTANCE_ID>"
}
}]' \
gcr.io/datadoghq/agent:${DD_AGENT_VERSION}
Labels can also be specified in a Dockerfile
, so you can build and deploy a custom agent without changing any infrastructure configuration:
FROM gcr.io/datadoghq/agent:7.36.1
LABEL "com.datadoghq.ad.check_names"='["mysql"]'
LABEL "com.datadoghq.ad.init_configs"='[{}]'
LABEL "com.datadoghq.ad.instances"='[{"dbm": true, "host": "<INSTANCE_ADDRESS>", "port": 5432,"username": "datadog","password": "<UNIQUEPASSWORD>", "gcp": {"project_id": "<PROJECT_ID>", "instance_id": "<INSTANCE_ID>"}}]'
See the MySQL integration spec for additional information on setting project_id
and instance_id
fields.
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, or see the Autodiscovery template variables documentation on how to pass in the password as an environment variable.
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 either with static files mounted in the Cluster Agent container or using service annotations:
Execute the following Helm command to install the Datadog Cluster Agent on your Kubernetes cluster. Replace the values to match your account and environment:
helm repo add datadog https://helm.datadoghq.com
helm repo update
helm install <RELEASE_NAME> \
--set 'datadog.apiKey=<DATADOG_API_KEY>' \
--set 'clusterAgent.enabled=true' \
--set "clusterAgent.confd.mysql\.yaml=cluster_check: true
init_config:
instances:
- dbm: true
host: <INSTANCE_ADDRESS>
port: 3306
username: datadog
password: "<UNIQUEPASSWORD>"
gcp:
project_id: "<PROJECT_ID>"
instance_id: "<INSTANCE_ID>" \
datadog/datadog
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 flag
init_config:
instances:
- dbm: true
host: '<INSTANCE_ADDRESS>'
port: 3306
username: datadog
password: '<UNIQUEPASSWORD>'
# After adding your project and instance, configure the Datadog GCP integration to pull additional cloud data such as CPU, Memory, etc.
gcp:
project_id: '<PROJECT_ID>'
instance_id: '<INSTANCE_ID>'
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:
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": "<INSTANCE_ADDRESS>",
"port": 3306,
"username": "datadog",
"password": "<UNIQUEPASSWORD>",
"gcp": {
"project_id": "<PROJECT_ID>",
"instance_id": "<INSTANCE_ID>"
}
}
]
spec:
ports:
- port: 3306
protocol: TCP
targetPort: 3306
name: mysql
See the MySQL integration spec for additional information on setting project_id
and instance_id
fields.
The Cluster Agent automatically registers this configuration and begin 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.
Run the Agent’s status subcommand and look for mysql
under the Checks section. Or visit the Databases page to get started!
To collect more comprehensive database metrics from GCP, install the Cloud SQL integration (optional).
If you have installed and configured the integrations and Agent as described and it is not working as expected, see Troubleshooting
Additional helpful documentation, links, and articles: