+
+ clusterChecksRunner:
+ enabled: true
+ ```
+
+3. Deploy the Agent with the above configuration file from the command line:
+
+ ```shell
+ helm install datadog-agent -f datadog-values.yaml datadog/datadog
+ ```
+
+
+For Windows, append --set targetSystem=windows to the helm install command.
+
+
+### Configure with mounted files
+
+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`:
+
+```yaml
+cluster_check: true # Make sure to include this flag
+init_config:
+instances:
+ - dbm: true
+ host: ''
+ port:
+ username: datadog
+ password: 'ENC[datadog_user_database_password]'
+ aws:
+ instance_endpoint:
+ region:
+```
+
+### Configure with Kubernetes service annotations
+
+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 using the following syntax:
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: mysql
+ labels:
+ tags.datadoghq.com/env: ''
+ tags.datadoghq.com/service: ''
+ annotations:
+ ad.datadoghq.com/service.check_names: '["mysql"]'
+ ad.datadoghq.com/service.init_configs: '[{}]'
+ ad.datadoghq.com/service.instances: |
+ [
+ {
+ "dbm": true,
+ "host": "",
+ "port": ,
+ "username": "datadog",
+ "password": "ENC[datadog_user_database_password]",
+ "aws": {
+ "instance_endpoint": "",
+ "region": ""
+ }
+ }
+ ]
+spec:
+ ports:
+ - port:
+ protocol: TCP
+ targetPort:
+ name: mysql
+```
+
+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][6] and declare the password using the `ENC[]` syntax.
+
+[1]: /containers/cluster_agent/setup/
+[2]: /containers/cluster_agent/clusterchecks/
+[3]: /containers/kubernetes/integrations/?tab=datadogoperator
+[4]: /containers/kubernetes/integrations/?tab=helm
+[5]: /containers/kubernetes/integrations/?tab=annotations#configuration
+[6]: /agent/configuration/secrets-management
+
+{{% /tab %}}
+{{< /tabs >}}
+
+### Validate
+
+[Run the Agent's status subcommand][6] and look for `mysql` under the Checks section, or see the [Databases][7] page to get started!
+
+## Example Agent Configurations
+{{% dbm-mysql-agent-config-examples %}}
+
+## Install the RDS Integration
+
+To see infrastructure metrics from AWS, such as CPU, alongside the database telemetry in DBM, install the [RDS integration][8] (optional).
+
+## Troubleshooting
+
+If you have installed and configured the integrations and Agent as described and it is not working as expected, see [Troubleshooting][9].
+
+## Further reading
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /database_monitoring/agent_integration_overhead/?tab=mysql
+[2]: /database_monitoring/data_collected/#sensitive-information
+[3]: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html
+[4]: https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/migrating-to-mariadb/migrating-to-mariadb-from-sql-server/mariadb-authorization-and-permissions-for-sql-server-users#permissions
+[5]: https://app.datadoghq.com/account/settings/agent/latest
+[6]: /agent/configuration/agent-commands/#agent-status-and-information
+[7]: https://app.datadoghq.com/databases
+[8]: /integrations/amazon_rds
+[9]: /database_monitoring/troubleshooting/?tab=mysql
+[10]: https://app.datadoghq.com/integrations/amazon-web-services
+[11]: /database_monitoring/setup_mariadb/troubleshooting/#mariadb-known-limitations
diff --git a/hugo/content/en/database_monitoring/setup_mariadb/selfhosted.md b/hugo/content/en/database_monitoring/setup_mariadb/selfhosted.md
new file mode 100644
index 00000000000..92066d3603f
--- /dev/null
+++ b/hugo/content/en/database_monitoring/setup_mariadb/selfhosted.md
@@ -0,0 +1,277 @@
+---
+title: Setting Up Database Monitoring for self hosted MariaDB
+description: Install and configure Database Monitoring for self-hosted MariaDB.
+further_reading:
+- link: "/integrations/mysql/"
+ tag: "Documentation"
+ text: "Basic MySQL Integration"
+
+---
+
+Database Monitoring provides deep visibility into your MariaDB 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 MariaDB database:
+
+1. [Configure database parameters](#configure-mariadb-settings)
+1. [Grant the Agent access to the database](#grant-the-agent-access)
+1. [Install the Agent](#install-the-agent)
+
+## Before you begin
+
+Supported MariaDB versions
+: 10.5, 10.6, 10.11, or 11.4
+Database Monitoring for MariaDB is supported with [known limitations][13].
+
+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 1% of query execution time on the database and less than 1% of CPU.
+Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]).
+
+Proxies, load balancers, and connection poolers
+: The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, `127.0.0.1` or the socket is preferred. 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][2] for information about what data the Agent collects from your databases and how to keep it secure.
+
+## Configure MariaDB settings
+
+To collect query metrics, samples, and explain plans, enable the [MariaDB performance schema][3] and configure the following [performance schema options][4], either on the command line or in configuration files (for example, `mysql.conf`):
+
+**Note**: Unlike MySQL, MariaDB ships with `performance_schema` turned off by default. You must explicitly enable it.
+
+| Parameter | Value | Description |
+| --- | --- | --- |
+| `performance_schema` | `ON` | Required. Enables the performance schema. MariaDB does not enable this by default. |
+| `max_digest_length` | `4096` | Required for collection of larger queries. If left at the default value, queries longer than `1024` characters aren't collected. |
+| `performance_schema_max_digest_length` | `4096` | Must match `max_digest_length`. |
+| `performance_schema_max_sql_text_length` | `4096` | Must match `max_digest_length`. |
+| `performance-schema-consumer-events-statements-current` | `ON` | Required. Enables monitoring of running queries. |
+| `performance-schema-consumer-events-waits-current` | `ON` | Required. Enables the collection of wait events. |
+| `performance-schema-consumer-events-statements-history-long` | `ON` | Recommended. Enables tracking of a larger number of recent queries across all threads. If enabled it increases the likelihood of capturing execution details from infrequent queries. |
+| `performance-schema-consumer-events-statements-history` | `ON` | Optional. Enables tracking recent query history per thread. If enabled it increases the likelihood of capturing execution details from infrequent queries. |
+
+**Note**: A recommended practice is to allow the agent to enable the `performance-schema-consumer-*` settings dynamically at runtime, as part of granting the Agent access. See [Runtime setup consumers](#runtime-setup-consumers).
+
+## Grant the Agent access
+
+The Datadog Agent requires read-only access to the database 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 [MariaDB documentation][5] for more info.
+
+Create the `datadog` user and grant basic permissions:
+
+```sql
+CREATE USER datadog@'%' IDENTIFIED by '';
+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@'%';
+```
+
+To collect blocking query and foreign-key information on MariaDB 10.5 and later, also grant the `REFERENCES` privilege:
+
+```sql
+GRANT REFERENCES ON *.* TO datadog@'%';
+```
+
+Create the following schema:
+
+```sql
+CREATE SCHEMA IF NOT EXISTS datadog;
+GRANT EXECUTE ON datadog.* to datadog@'%';
+```
+
+Create the `explain_statement` procedure to enable the Agent to collect explain plans:
+
+```sql
+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 `` with your database schema:
+
+```sql
+DELIMITER $$
+CREATE PROCEDURE .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 .explain_statement TO datadog@'%';
+```
+
+To collect index metrics, grant the `datadog` user an additional privilege:
+
+```sql
+GRANT SELECT ON mysql.innodb_index_stats TO datadog@'%';
+```
+
+### Runtime setup consumers
+Datadog recommends that you create the following procedure to give the Agent the ability to enable `performance_schema.events_*` consumers at runtime.
+
+```SQL
+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@'%';
+```
+
+### Securely store your password
+{{% dbm-secret %}}
+
+## Install the Agent
+
+Installing the Datadog Agent also installs the MySQL check, which is used to monitor MariaDB and is required for Database Monitoring on MariaDB. If you haven't already installed the Agent for your MariaDB database host, see the [Agent installation instructions][6].
+
+To configure this check for an Agent running on a host:
+
+Edit the `mysql.d/conf.yaml` file, in the `conf.d/` folder at the root of your [Agent's configuration directory][7] to start collecting your MariaDB [metrics](#metric-collection) and [logs](#log-collection-optional). See the [sample mysql.d/conf.yaml][8] for all available configuration options, including those for custom metrics.
+
+### Metric collection
+
+Add this configuration block to your `mysql.d/conf.yaml` to collect MariaDB metrics:
+
+```yaml
+init_config:
+
+instances:
+ - dbm: true
+ host: 127.0.0.1
+ port: 3306
+ username: datadog
+ password: 'ENC[datadog_user_database_password]' # from the CREATE USER step earlier
+```
+
+**Note**: The `datadog` user should be set up in the MySQL integration configuration as `host: 127.0.0.1` instead of `localhost`. Alternatively, you may also use `sock`.
+
+Metrics and events are tagged with `dbms_flavor:mariadb` so you can distinguish MariaDB data from MySQL data.
+
+[Restart the Agent][9] to start sending MariaDB metrics to Datadog.
+
+### Log collection (optional)
+
+In addition to telemetry collected from the database by the Agent, you can also choose to send your database logs directly to Datadog.
+
+1. By default MariaDB logs everything in `/var/log/syslog` which requires root access to read. To make the logs more accessible, follow these steps:
+
+ 1. Edit `/etc/mysql/conf.d/mysqld_safe_syslog.cnf` and comment out all lines.
+ 2. Edit `/etc/mysql/my.cnf` to enable the desired logging settings. For example, to enable general, error, and slow query logs, use the following configuration:
+
+ ```conf
+ [mysqld_safe]
+ log_error = /var/log/mysql/mysql_error.log
+
+ [mysqld]
+ general_log = on
+ general_log_file = /var/log/mysql/mysql.log
+ log_error = /var/log/mysql/mysql_error.log
+ slow_query_log = on
+ slow_query_log_file = /var/log/mysql/mysql_slow.log
+ long_query_time = 3
+ ```
+
+ 3. Save the file and restart MariaDB.
+ 4. Make sure the Agent has read access to the `/var/log/mysql` directory and all of the files within. Double-check your `logrotate` configuration to make sure these files are taken into account and that the permissions are correctly set.
+ In `/etc/logrotate.d/mysql-server` there should be something similar to:
+
+ ```text
+ /var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql_slow.log {
+ daily
+ rotate 7
+ missingok
+ create 644 mysql adm
+ Compress
+ }
+ ```
+
+2. Collecting logs is disabled by default in the Datadog Agent, enable it in your `datadog.yaml` file:
+
+ ```yaml
+ logs_enabled: true
+ ```
+
+3. Add this configuration block to your `mysql.d/conf.yaml` file to start collecting your MariaDB logs:
+
+ ```yaml
+ logs:
+ - type: file
+ path: ""
+ source: mysql
+ service: ""
+
+ - type: file
+ path: ""
+ source: mysql
+ service: ""
+ log_processing_rules:
+ - type: multi_line
+ name: new_slow_query_log_entry
+ pattern: "# Time:"
+ # If mysqld was started with `--log-short-format`, use:
+ # pattern: "# Query_time:"
+
+ - type: file
+ path: ""
+ source: mysql
+ service: ""
+ # For multiline logs, if they start by the date with the format yyyy-mm-dd uncomment the following processing rule
+ # log_processing_rules:
+ # - type: multi_line
+ # name: new_log_start_with_date
+ # pattern: \d{4}\-(0?[1-9]|1[012])\-(0?[1-9]|[12][0-9]|3[01])
+ # If the logs start with a date with the format yymmdd but include a timestamp with each new second, rather than with each log, uncomment the following processing rule
+ # log_processing_rules:
+ # - type: multi_line
+ # name: new_logs_do_not_always_start_with_timestamp
+ # pattern: \t\t\s*\d+\s+|\d{6}\s+\d{,2}:\d{2}:\d{2}\t\s*\d+\s+
+ ```
+
+4. [Restart the Agent][9].
+
+## Validate
+
+[Run the Agent's status subcommand][10] and look for `mysql` under the Checks section, or see the [Databases][11] page to get started!
+
+## Example Agent Configurations
+{{% dbm-mysql-agent-config-examples %}}
+
+## Troubleshooting
+
+If you have installed and configured the integrations and Agent as described and it is not working as expected, see [Troubleshooting][12].
+
+## Further reading
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /database_monitoring/agent_integration_overhead/?tab=mysql
+[2]: /database_monitoring/data_collected/#sensitive-information
+[3]: https://mariadb.com/kb/en/performance-schema-overview/
+[4]: https://mariadb.com/kb/en/performance-schema-instance-tables/
+[5]: https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/migrating-to-mariadb/migrating-to-mariadb-from-sql-server/mariadb-authorization-and-permissions-for-sql-server-users#permissions
+[6]: https://app.datadoghq.com/account/settings/agent/latest
+[7]: /agent/configuration/agent-configuration-files/#agent-configuration-directory
+[8]: https://github.com/DataDog/integrations-core/blob/master/mysql/datadog_checks/mysql/data/conf.yaml.example
+[9]: /agent/configuration/agent-commands/#start-stop-and-restart-the-agent
+[10]: /agent/configuration/agent-commands/#agent-status-and-information
+[11]: https://app.datadoghq.com/databases
+[12]: /database_monitoring/troubleshooting/?tab=mysql
+[13]: /database_monitoring/setup_mariadb/troubleshooting/#mariadb-known-limitations
diff --git a/hugo/content/en/database_monitoring/setup_mariadb/troubleshooting.md b/hugo/content/en/database_monitoring/setup_mariadb/troubleshooting.md
new file mode 100644
index 00000000000..c1a4d5ccd6c
--- /dev/null
+++ b/hugo/content/en/database_monitoring/setup_mariadb/troubleshooting.md
@@ -0,0 +1,290 @@
+---
+title: Troubleshoot Database Monitoring setup for MariaDB
+description: Troubleshoot Database Monitoring setup
+---
+
+This page details common issues with setting up and using Database Monitoring with MariaDB, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases.
+
+## Diagnosing common problems
+
+### No data is showing after configuring Database Monitoring
+
+If you do not see any data after following the [setup instructions][1] and configuring the Agent, there is most likely an issue with the Agent configuration or API key. Follow the [troubleshooting guide][2], which helps confirm you are receiving data from the Agent.
+
+If you are receiving other data such as system metrics, but not Database Monitoring data (such as query metrics and query samples), there is probably an issue with the Agent or database configuration. Compare your Agent configuration to the example in the [setup instructions][1] to check that it matches, and double-check the location of the configuration files.
+
+To debug, start by running the [Agent status command][3] to collect debugging information about data collected and sent to Datadog.
+
+Check the `Config Errors` section to confirm the configuration file is valid. For instance, the following indicates a missing instance configuration or invalid file:
+
+```
+ Config Errors
+ ==============
+ mysql
+ -----
+ Configuration file contains no valid instances
+```
+
+If the configuration is valid, the output looks like this:
+
+```
+=========
+Collector
+=========
+
+ Running Checks
+ ==============
+
+ mysql (5.0.4)
+ -------------
+ Instance ID: mysql:505a0dd620ccaa2a
+ Configuration Source: file:/etc/datadog-agent/conf.d/mysql.d/conf.yaml
+ Total Runs: 32,439
+ Metric Samples: Last Run: 175, Total: 5,833,916
+ Events: Last Run: 0, Total: 0
+ Database Monitoring Query Metrics: Last Run: 2, Total: 51,074
+ Database Monitoring Query Samples: Last Run: 1, Total: 74,451
+ Service Checks: Last Run: 3, Total: 95,993
+ Average Execution Time : 1.798s
+ Last Execution Date : 2021-07-29 19:28:21 UTC (1627586901000)
+ Last Successful Execution Date : 2021-07-29 19:28:21 UTC (1627586901000)
+ metadata:
+ flavor: MariaDB
+ version.build: unspecified
+ version.major: 10
+ version.minor: 11
+ version.patch: 6
+ version.raw: 10.11.6-MariaDB
+ version.scheme: semver
+```
+
+Check that these lines are in the output and have values greater than zero:
+
+```
+Database Monitoring Query Metrics: Last Run: 2, Total: 51,074
+Database Monitoring Query Samples: Last Run: 1, Total: 74,451
+```
+
+When you are confident the Agent configuration is correct, [check the Agent logs][4] for warnings or errors attempting to run the database integrations.
+
+You can also explicitly execute a check by running the `check` CLI command on the Datadog Agent and inspecting the output for errors:
+
+```bash
+# For self-hosted installations of the Agent
+DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true datadog-agent check mysql -t 2
+
+# For container-based installations of the Agent
+DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true agent check mysql -t 2
+```
+
+### Queries are missing explain plans
+
+Some or all queries may not have plans available. This can be due to unsupported query commands, queries made by unsupported client applications, an outdated Agent, or incomplete database setup. Below are possible causes for missing explain plans.
+
+#### Missing event statements consumer {#events-statements-consumer-missing}
+To capture explain plans, you must enable an event statements consumer. You can do this by adding the following option to your configuration files (for example, `mysql.conf`):
+```
+performance-schema-consumer-events-statements-current=ON
+```
+
+Datadog additionally recommends enabling the following:
+```
+performance-schema-consumer-events-statements-history-long=ON
+```
+This option enables the tracking of a larger number of recent queries across all threads. Turning it on increases the likelihood of capturing execution details from infrequent queries.
+
+#### Missing explain plan procedure {#explain-plan-procedure-missing}
+The Agent requires the procedure `datadog.explain_statement(...)` to exist in the `datadog` schema. Read the [setup instructions][1] for details on the creation of the `datadog` schema.
+
+Create the `explain_statement` procedure to enable the Agent to collect explain plans:
+
+```sql
+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 ;
+```
+#### Missing full qualified explain plan procedure {#explain-plan-fq-procedure-missing}
+The Agent requires the procedure `explain_statement(...)` to exist in **all schemas** the Agent can collect samples from.
+
+Create this procedure **in every schema** from which you want to collect explain plans. Replace `` with your database schema:
+
+```sql
+DELIMITER $$
+CREATE PROCEDURE .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 .explain_statement TO datadog@'%';
+```
+
+#### Agent is running an unsupported version
+
+Check that the Agent is running version 7.36.1 or newer. Datadog recommends regular updates of the Agent to take advantage of new features, performance improvements, and security updates.
+
+#### Queries are truncated
+
+See the section on [truncated query samples](#query-samples-are-truncated) for instructions on how to increase the size of sample query text.
+
+#### Query cannot be explained
+
+Some queries such as BEGIN, COMMIT, SHOW, USE, and ALTER queries cannot yield a valid explain plan from the database. Only SELECT, UPDATE, INSERT, DELETE, and REPLACE queries have support for explain plans.
+
+#### Query is relatively infrequent or executes fast
+
+The query may not have been sampled for selection because it does not represent a significant proportion of the database's total execution time. Try [raising the sampling rates][5] to capture the query.
+
+### Query metrics are missing
+
+Before following these steps to diagnose missing query metric data, check that the Agent is running successfully and you have followed [the steps to diagnose missing agent data](#no-data-is-showing-after-configuring-database-monitoring). Below are possible causes for missing query metrics.
+
+Query metrics and prepared statement metrics require MariaDB 10.5.2 or later. On earlier versions, this data isn't collected.
+
+### Index metrics are missing
+
+If the Agent displays this error:
+```
+Error querying mysql.innodb_index_stats: (1142, "SELECT command denied to user 'datadog'@'172.20.0.5' for table 'innodb_index_stats'")
+```
+Resolve the error by granting the `datadog` user the SELECT privilege to collect index metrics:
+
+```sql
+GRANT SELECT ON mysql.innodb_index_stats TO datadog@'%';
+```
+
+#### `performance_schema` is not enabled {#performance-schema-not-enabled}
+The Agent requires the `performance_schema` option to be enabled. **Unlike MySQL, MariaDB does not enable `performance_schema` by default.** Follow the [setup instructions][1] for enabling it.
+
+### Blocking queries are missing or incomplete
+
+#### Missing `REFERENCES` privilege {#references-privilege-missing}
+Starting with MariaDB 10.5, collecting blocking query and foreign-key information requires the `REFERENCES` privilege in addition to the base grants. Grant it to the `datadog` user:
+
+```sql
+GRANT REFERENCES ON *.* TO datadog@'%';
+```
+
+#### Fewer blocking-query columns than MySQL 8.0
+
+MariaDB always uses the same, simpler set of blocking-query columns and joins that MySQL 5.7 uses, even on the newest MariaDB versions. The richer blocking-query columns available on MySQL 8.0 aren't available on MariaDB.
+
+#### Deadlock counts appear flat
+
+Deadlock counts aren't updated on MariaDB. The deadlock metric can remain at zero regardless of actual deadlocks occurring on the database.
+
+### Certain queries are missing
+
+If you have data from some queries, but are expecting to see a particular query or set of queries in Database Monitoring, follow this guide.
+
+
+| Possible cause | Solution |
+|----------------------------------------|-------------------------------------------|
+| The query is not a "top query," meaning the sum of its total execution time is not in the top 200 normalized queries at any point in the selected time frame. | It may be grouped into the "Other Queries" row. For more information on which queries are tracked, see [Data Collected][7]. The number of top queries tracked can be raised by contacting Datadog Support. |
+| The `events_statements_summary_by_digest` may be full. | The MariaDB table `events_statements_summary_by_digest` in `performance_schema` has a maximum limit on the number of digests (normalized queries) it stores. Regular truncation of this table as a maintenance task helps track all queries over time. See [Advanced configuration][5] for more information. |
+| The query has been executed a single time since the agent last restarted. | Query metrics are only emitted after having been executed at least once over two separate ten second intervals since the Agent was restarted. |
+
+### Query samples are truncated
+
+Longer queries may not show their full SQL text due to database configuration. Some tuning is necessary to adjust for your workload.
+
+The MariaDB SQL text length visible to the Datadog Agent is determined by the following [system variables][8]:
+
+```
+max_digest_length=4096
+performance_schema_max_digest_length=4096
+performance_schema_max_sql_text_length=4096
+```
+
+### Query activity is missing
+
+Before following these steps to diagnose missing query activity, check that the Agent is running successfully and you have followed [the steps to diagnose missing agent data](#no-data-is-showing-after-configuring-database-monitoring). Below are possible causes for missing query activity.
+
+#### `performance-schema-consumer-events-waits-current` is not enabled {#events-waits-current-not-enabled}
+The Agent requires the `performance-schema-consumer-events-waits-current` option to be enabled. It is disabled by default. Follow the [setup instructions][1] for enabling it. Alternatively, to avoid bouncing your database, consider setting up a runtime setup consumer. Create the following procedure to give the Agent the ability to enable `performance_schema.events_*` consumers at runtime.
+
+
+```SQL
+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@'%';
+```
+
+**Note:** This option additionally requires `performance_schema` to be enabled.
+
+### Schema or Database missing on MariaDB Query Metrics & Samples
+
+The `schema` tag (also known as "database") is present on MariaDB Query Metrics and Samples only when a Default Database is set on the connection that made the query. The Default Database is configured by the application by specifying the "schema" in the database connection parameters, or by executing the [USE Statement][9] on an already existing connection.
+
+If there is no default database configured for a connection, then none of the queries made by that connection have the `schema` tag on them.
+
+## MariaDB known limitations
+
+MariaDB is monitored using the same MySQL integration, and metrics and events are tagged with `dbms_flavor:mariadb` to distinguish them from MySQL data. The following features differ from MySQL or aren't supported on MariaDB.
+
+### Incompatible InnoDB metrics
+
+The following InnoDB metrics are not available for certain MariaDB versions:
+
+| Metric Name | MariaDB Versions |
+| --------------------------------------- | ----------------------- |
+| `mysql.innodb.hash_index_cells_total` | 10.5, 10.6, 10.11, 11.4 |
+| `mysql.innodb.hash_index_cells_used` | 10.5, 10.6, 10.11, 11.4 |
+| `mysql.innodb.os_log_fsyncs` | 10.11, 11.4 |
+| `mysql.innodb.os_log_pending_fsyncs` | 10.11, 11.4 |
+| `mysql.innodb.os_log_pending_writes` | 10.11, 11.4 |
+| `mysql.innodb.pending_log_flushes` | 10.11, 11.4 |
+| `mysql.innodb.pending_log_writes` | 10.5, 10.6, 10.11, 11.4 |
+| `mysql.innodb.pending_normal_aio_reads` | 10.5, 10.6, 10.11, 11.4 |
+| `mysql.innodb.pending_normal_aio_writes`| 10.5, 10.6, 10.11, 11.4 |
+| `mysql.innodb.rows_deleted` | 10.11, 11.4 |
+| `mysql.innodb.rows_inserted` | 10.11, 11.4 |
+| `mysql.innodb.rows_updated` | 10.11, 11.4 |
+| `mysql.innodb.rows_read` | 10.11, 11.4 |
+| `mysql.innodb.s_lock_os_waits` | 10.6, 10.11, 11.4 |
+| `mysql.innodb.s_lock_spin_rounds` | 10.6, 10.11, 11.4 |
+| `mysql.innodb.s_lock_spin_waits` | 10.6, 10.11, 11.4 |
+| `mysql.innodb.x_lock_os_waits` | 10.6, 10.11, 11.4 |
+| `mysql.innodb.x_lock_spin_rounds` | 10.6, 10.11, 11.4 |
+| `mysql.innodb.x_lock_spin_waits` | 10.6, 10.11, 11.4 |
+
+### MariaDB explain plan
+
+MariaDB does not produce the same JSON format as MySQL for explain plans. Certain explain plan fields may be missing from MariaDB explain plans, including `cost_info`, `rows_examined_per_scan`, `rows_produced_per_join`, and `used_columns`. Explain plan collection itself works the same way as on MySQL, but plan visualizations that rely on these fields may show less detail for MariaDB queries.
+
+### `mysql.performance.errors_raised` is not collected
+
+This metric is collected only for MySQL 8.0 and later, and isn't available for MariaDB.
+
+### Functional indexes aren't reflected in schema metadata
+
+MariaDB doesn't support functional indexes. Index metadata collection always uses the plain index query, without the extra expression information available for MySQL 8.0.13 and later.
+
+### Cluster tags aren't supported
+
+Cluster tags aren't collected for MariaDB.
+
+[1]: /database_monitoring/setup_mariadb/
+[2]: /agent/troubleshooting/
+[3]: /agent/configuration/agent-commands/?tab=agentv6v7#agent-status-and-information
+[4]: /agent/configuration/agent-log-files
+[5]: /database_monitoring/setup_mariadb/advanced_configuration/
+[7]: /database_monitoring/data_collected/#which-queries-are-tracked
+[8]: https://mariadb.com/kb/en/server-system-variables/#max_digest_length
+[9]: https://mariadb.com/kb/en/use/
diff --git a/hugo/layouts/partials/dbm/dbm-setup-mariadb.html b/hugo/layouts/partials/dbm/dbm-setup-mariadb.html
new file mode 100644
index 00000000000..b69e4a2db46
--- /dev/null
+++ b/hugo/layouts/partials/dbm/dbm-setup-mariadb.html
@@ -0,0 +1,22 @@
+{{ $dot := . }}
+