Documentation Grafana Cloud Monitor applications Database Observability Set up MySQL Azure Flexible Server

Set up Azure Database for MySQL

Set up Database Observability with Grafana Cloud to collect telemetry from Azure Database for MySQL Flexible Server using Grafana Alloy. You configure your Azure MySQL server and Alloy to forward telemetry to Grafana Cloud.

If you already use the MySQL integration, Database Observability extends it with query-level telemetry collected by the database_observability.mysql Alloy component.

What you’ll achieve

In this article, you:

• Configure Azure MySQL server parameters for monitoring.
• Create monitoring users with required privileges.
• Configure Grafana Alloy with the Database Observability components.
• Forward telemetry to Grafana Cloud.
• Verify that telemetry appears in Database Observability.

Setup steps

Setting up Database Observability for Azure MySQL has three steps:

1. Set up your database: Prepare your Azure MySQL server so Alloy can collect from it.
2. Configure Grafana Alloy: Configure how Alloy collects telemetry and sends it to Grafana Cloud. Azure MySQL supports a few methods to choose from.
3. Verify telemetry in Grafana Cloud: Check telemetry status and confirm that query metrics appear in Database Observability.

Before you begin

To complete this setup, you need:

• An Azure Database for MySQL Flexible Server 8.0 or later server.
• Permission to modify server parameters.
• Permission to restart the Azure MySQL server if parameter changes require it.
• A MySQL admin user that can create users and grant privileges.
• A planned Grafana Alloy deployment location with network access to the Azure MySQL server endpoint.

Estimated setup time: 20-40 minutes, excluding any required maintenance window for restarting the server.

For general MySQL setup concepts, refer to Set up MySQL.

Set up your database

In this step, you’ll prepare your Azure MySQL Flexible Server for monitoring by setting up Performance Schema parameters, creating a monitoring user, and granting the permissions Database Observability needs.

Complete this before configuring Alloy. Without it, Alloy can connect to your database, but it won’t be able to collect the telemetry required for Database Observability.

Configure server parameters

Enable Performance Schema and related instrumentation by configuring server parameters on your Azure Database for MySQL Flexible Server. These parameters require a server restart to take effect.

Required server parameters

Use the Azure portal

1. Open the Azure Portal and navigate to Azure Database for MySQL flexible servers.
2. Select your MySQL flexible server.
3. In the left menu under Settings, select Server parameters.
4. Search for and configure each parameter listed above.
5. Click Save to apply the changes.
6. Some parameters require a server restart. Navigate to Overview and click Restart if prompted.

For detailed portal instructions, refer to Configure server parameters in the Azure documentation.

Use Terraform

Using Terraform with azurerm_mysql_flexible_server_configuration:

hcl Copy

resource "azurerm_mysql_flexible_server_configuration" "performance_schema" {
  name                = "performance_schema"
  resource_group_name = "<RESOURCE_GROUP>"
  server_name         = "<SERVER_NAME>"
  value               = "ON"
}

resource "azurerm_mysql_flexible_server_configuration" "performance_schema_consumer_events_waits_current" {
  name                = "performance_schema_consumer_events_waits_current"
  resource_group_name = "<RESOURCE_GROUP>"
  server_name         = "<SERVER_NAME>"
  value               = "ON"
}

resource "azurerm_mysql_flexible_server_configuration" "performance_schema_consumer_events_waits_history" {
  name                = "performance_schema_consumer_events_waits_history"
  resource_group_name = "<RESOURCE_GROUP>"
  server_name         = "<SERVER_NAME>"
  value               = "ON"
}

resource "azurerm_mysql_flexible_server_configuration" "performance_schema_consumer_global_instrumentation" {
  name                = "performance_schema_consumer_global_instrumentation"
  resource_group_name = "<RESOURCE_GROUP>"
  server_name         = "<SERVER_NAME>"
  value               = "ON"
}

resource "azurerm_mysql_flexible_server_configuration" "performance_schema_consumer_thread_instrumentation" {
  name                = "performance_schema_consumer_thread_instrumentation"
  resource_group_name = "<RESOURCE_GROUP>"
  server_name         = "<SERVER_NAME>"
  value               = "ON"
}

resource "azurerm_mysql_flexible_server_configuration" "performance_schema_max_digest_length" {
  name                = "performance_schema_max_digest_length"
  resource_group_name = "<RESOURCE_GROUP>"
  server_name         = "<SERVER_NAME>"
  value               = "4096"
}

resource "azurerm_mysql_flexible_server_configuration" "performance_schema_max_sql_text_length" {
  name                = "performance_schema_max_sql_text_length"
  resource_group_name = "<RESOURCE_GROUP>"
  server_name         = "<SERVER_NAME>"
  value               = "4096"
}

resource "azurerm_mysql_flexible_server_configuration" "max_digest_length" {
  name                = "max_digest_length"
  resource_group_name = "<RESOURCE_GROUP>"
  server_name         = "<SERVER_NAME>"
  value               = "4096"
}

Replace the placeholders:

• RESOURCE_GROUP: Azure resource group name.
• SERVER_NAME: Azure MySQL Flexible Server name.

Alternatively, configure parameters using the Azure CLI:

Bash Copy

az mysql flexible-server parameter set \
  --resource-group <RESOURCE_GROUP> \
  --server-name <SERVER_NAME> \
  --name performance_schema \
  --value ON

az mysql flexible-server parameter set \
  --resource-group <RESOURCE_GROUP> \
  --server-name <SERVER_NAME> \
  --name performance_schema_consumer_events_waits_current \
  --value ON

az mysql flexible-server parameter set \
  --resource-group <RESOURCE_GROUP> \
  --server-name <SERVER_NAME> \
  --name performance_schema_consumer_events_waits_history \
  --value ON

az mysql flexible-server parameter set \
  --resource-group <RESOURCE_GROUP> \
  --server-name <SERVER_NAME> \
  --name performance_schema_consumer_global_instrumentation \
  --value ON

az mysql flexible-server parameter set \
  --resource-group <RESOURCE_GROUP> \
  --server-name <SERVER_NAME> \
  --name performance_schema_consumer_thread_instrumentation \
  --value ON

az mysql flexible-server parameter set \
  --resource-group <RESOURCE_GROUP> \
  --server-name <SERVER_NAME> \
  --name performance_schema_max_digest_length \
  --value 4096

az mysql flexible-server parameter set \
  --resource-group <RESOURCE_GROUP> \
  --server-name <SERVER_NAME> \
  --name performance_schema_max_sql_text_length \
  --value 4096

az mysql flexible-server parameter set \
  --resource-group <RESOURCE_GROUP> \
  --server-name <SERVER_NAME> \
  --name max_digest_length \
  --value 4096

Create a monitoring user and grant required privileges

Connect to your Azure MySQL Flexible Server and create the monitoring user:

Create the db-o11y user and grant base privileges:

SQL Copy

CREATE USER 'db-o11y'@'%' IDENTIFIED BY '<DB_O11Y_PASSWORD>';
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'db-o11y'@'%';
GRANT SELECT ON performance_schema.* TO 'db-o11y'@'%';

Replace <DB_O11Y_PASSWORD> with a secure password for the db-o11y MySQL user.

Disable tracking of monitoring user queries

Prevent tracking of queries executed by the monitoring user itself:

SQL Copy

UPDATE performance_schema.setup_actors SET ENABLED = 'NO', HISTORY = 'NO' WHERE USER = 'db-o11y';

Grant object privileges

Grant access to specific schemas when you want detailed information:

SQL Copy

GRANT SELECT, SHOW VIEW ON <SCHEMA_NAME>.* TO 'db-o11y'@'%';

Replace <SCHEMA_NAME> with the name of the schema you want to monitor.

Alternatively, if you’re unsure which specific schemas need access, grant broader read access to all schemas:

SQL Copy

GRANT SELECT, SHOW VIEW ON *.* TO 'db-o11y'@'%';

Enable Performance Schema consumers

Database Observability uses Performance Schema consumers to collect CPU time, query samples, and wait events. These consumers must be enabled before Alloy can collect complete query telemetry.

Choose one of the following:

Option 1: Enable consumers manually

Use this method if you don’t want Alloy to modify Performance Schema settings.

Check whether the required consumers are enabled:

SQL Copy

SELECT NAME, ENABLED
FROM performance_schema.setup_consumers
WHERE NAME IN (
  'events_statements_cpu',
  'events_waits_current',
  'events_waits_history'
);

Enable any disabled consumers:

SQL Copy

UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME IN (
  'events_statements_cpu',
  'events_waits_current',
  'events_waits_history'
);

These consumers disable when your database restarts. If you use this method, re-enable them after each restart.

Option 2: Let Alloy manage consumers automatically

Use this method if you want to prepare the database so Alloy can automatically re-enable the required Performance Schema consumers after your database restarts.

To prepare the database for this method, grant the monitoring user permission to update Performance Schema consumers:

SQL Copy

GRANT UPDATE ON performance_schema.setup_consumers TO 'db-o11y'@'%';

Later, when you configure Alloy, enable automatic Performance Schema consumer management in the Alloy configuration.

Verify user privileges

Verify that the user exists and has the expected privileges:

SQL Copy

SHOW GRANTS FOR 'db-o11y'@'%';

Expected output:

Copy

+------------------------------------------------------------------------------+
| Grants for db-o11y@%                                                         |
+------------------------------------------------------------------------------+
| GRANT PROCESS, REPLICATION CLIENT ON *.* TO `db-o11y`@`%`                    |
| GRANT SELECT, SHOW VIEW ON *.* TO `db-o11y`@`%`                              |
| GRANT SELECT ON `performance_schema`.* TO `db-o11y`@`%`                      |
| GRANT INSERT, UPDATE ON `performance_schema`.`setup_actors` TO `db-o11y`@`%` |
+------------------------------------------------------------------------------+

Verify server parameter settings

Verify that the settings were applied correctly:

SQL Copy

SHOW VARIABLES LIKE 'performance_schema';

Expected result: Value is ON.

SQL Copy

SHOW VARIABLES LIKE 'performance_schema_max_digest_length';

Expected result: Value is 4096.

SQL Copy

SHOW VARIABLES LIKE 'performance_schema_max_sql_text_length';

Expected result: Value is 4096.

SQL Copy

SHOW VARIABLES LIKE 'max_digest_length';

Expected result: Value is 4096.

Database setup checkpoint

Continue to Alloy configuration only after these conditions are true:

• performance_schema is ON.
• performance_schema_max_digest_length, performance_schema_max_sql_text_length, and max_digest_length are set to 4096.
• SHOW GRANTS FOR 'db-o11y'@'%'; includes all required monitoring and object privileges.
• The required Performance Schema consumers are enabled manually, or the monitoring user has permission for Alloy-managed consumer updates.
• The db-o11y monitoring user can connect from the network where Alloy will run.
• Any parameter changes that required a restart have been applied and the server restart is complete.

After these checks pass, your Azure MySQL server is ready for Database Observability. Next, configure Alloy so it can collect telemetry from the server endpoint and send it to Grafana Cloud.

Configure Grafana Alloy

After you set up your database, choose how to configure Alloy.

Pick one:

1. Configuration page (recommended): Database Observability generates the Alloy configuration for you. Then let Fleet Management apply it to an enrolled collector, or choose Manual Configuration to download the generated file and deploy it yourself. Best for most teams.
2. Kubernetes Monitoring Helm chart: Set databaseObservability.enabled in your values.yaml. Best for teams already running Alloy through the k8s-monitoring Helm chart.
3. Custom configuration file (advanced): Write the Alloy configuration yourself. Best for full control, custom components or relabeling, or environments the other paths don’t cover.

Make sure you’re on a supported Alloy version

Option 1: Configure Alloy from the Database Observability Configuration page (recommended)

Start here for most deployments. The Configuration page (Configuration > Setup) generates the Alloy configuration for you, then lets you choose how to deploy it:

• Fleet Management: Grafana Cloud deploys the configuration to an enrolled Alloy collector and manages it for you, so you don’t edit or ship config files by hand. Best if you want to manage collectors centrally and monitor their health from Grafana Cloud. Refer to Introduction to Fleet Management.
• Manual Configuration: Download the generated configuration and deploy it with your own tooling. Best if you can’t use Fleet Management or you already manage Alloy deployment yourself.

To start the guided setup flow:

1. Open Database Observability in Grafana Cloud.
2. Go to Configuration.
3. Open Setup.
4. Click Add database.
5. Select your database engine.
6. Follow the setup flow and choose Fleet Management or Manual Configuration when prompted.

For an overview of setup methods and what appears in the Setup tab, refer to Configure Alloy from the Configuration page.

Option 2: Configure Alloy with the Grafana Kubernetes Monitoring Helm chart

Use this method if you already manage Alloy with the k8s-monitoring Helm chart. This path configures Alloy outside the Database Observability setup flow in Grafana Cloud.

Extend your values.yaml and set databaseObservability.enabled to true within the MySQL integration.

YAML Copy

integrations:
  collector: alloy-singleton
  mysql:
    instances:
      - name: <INSTANCE_NAME>
        jobLabel: integrations/db-o11y
        exporter:
          enabled: true
          collectors:
            perfSchemaEventsStatements:
              enabled: true
          dataSource:
            host: <SERVER_FQDN>
            auth:
              usernameKey: username
              passwordKey: password
        databaseObservability:
          enabled: true
          allowUpdatePerformanceSchemaSettings: true
          extraConfig: |
            exclude_schemas = ["azure_sys", "azure_maintenance"]
            cloud_provider {
              azure {
                resource_group  = "<AZURE_RESOURCE_GROUP>"
                subscription_id = "<AZURE_SUBSCRIPTION_ID>"
                server_name     = "<AZURE_SERVER_NAME>"
              }
            }
        secret:
          create: false
          name: <SECRET_NAME>
          namespace: <NAMESPACE>
        logs:
          enabled: true
          labelSelectors:
            app.kubernetes.io/instance: <INSTANCE_NAME>

Replace the placeholders:

• INSTANCE_NAME: Name for this database instance in Kubernetes.
• SERVER_FQDN: Azure MySQL server fully qualified domain name.
• AZURE_RESOURCE_ID: Azure resource ID for your MySQL Flexible Server.
• SECRET_NAME: Name of the Kubernetes secret containing database credentials.
• NAMESPACE: Kubernetes namespace where the secret exists.

To see the full set of values, refer to the k8s-monitoring Helm chart documentation or the example configuration.

Configure Azure Key Vault and Kubernetes (optional)

If you use Azure Key Vault with External Secrets Operator to manage database credentials, configure them as follows.

Secret naming convention

Store monitoring credentials in Azure Key Vault with a name following this convention:

Copy

mysql-<SERVER_NAME>-monitoring

MySQL secret format

Store the secret as JSON with the following format:

JSON Copy

{
  "username": "db-o11y",
  "password": "<DB_O11Y_PASSWORD>",
  "host": "<SERVER_FQDN>",
  "port": 3306
}

Replace the placeholders:

• DB_O11Y_PASSWORD: Password for the db-o11y MySQL user.
• SERVER_FQDN: Azure MySQL server fully qualified domain name.

Create the secret with the Azure CLI

Bash Copy

az keyvault secret set \
  --vault-name <KEY_VAULT_NAME> \
  --name "mysql-<SERVER_NAME>-monitoring" \
  --value '{"username":"db-o11y","password":"<DB_O11Y_PASSWORD>","host":"<SERVER_FQDN>","port":3306}'

Kubernetes External Secrets configuration

Use the External Secrets Operator to sync the Azure secret into Kubernetes:

YAML Copy

---
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: <SERVER_NAME>-db-monitoring-secretstore
spec:
  provider:
    azurekv:
      tenantId: <AZURE_TENANT_ID>
      vaultUrl: https://<KEY_VAULT_NAME>.vault.azure.net
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: <SERVER_NAME>-db-monitoring-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: <SERVER_NAME>-db-monitoring-secretstore
  dataFrom:
    - extract:
        key: mysql-<SERVER_NAME>-monitoring

Replace the placeholders:

• SERVER_NAME: Azure MySQL server name.
• AZURE_TENANT_ID: Azure tenant ID.
• KEY_VAULT_NAME: Azure Key Vault name.

Option 3: Configure Alloy with a custom configuration file (advanced)

Use this method if you manage Alloy configuration outside Grafana Cloud or need custom relabeling. This path configures Alloy outside the Database Observability setup flow in Grafana Cloud.

Add the Azure MySQL configuration blocks

Add these blocks to Alloy for Azure Database for MySQL. Replace <DB_NAME>. Create a local.file with the Data Source Name string, for example, <DB_USER>:<DB_PASSWORD>@tcp(<SERVER_FQDN>:<DB_PORT>)/:

Alloy Copy

local.file "mysql_secret_<DB_NAME>" {
  filename  = "/var/lib/alloy/mysql_secret_<DB_NAME>"
  is_secret = true
}

prometheus.exporter.mysql "mysql_<DB_NAME>" {
  data_source_name  = local.file.mysql_secret_<DB_NAME>.content
  enable_collectors = ["perf_schema.eventsstatements"]
  perf_schema.eventsstatements {
    exclude_schemas = ["azure_sys", "azure_maintenance"]
    text_limit      = 0
    limit           = 100
  }
}

database_observability.mysql "mysql_<DB_NAME>" {
  data_source_name  = local.file.mysql_secret_<DB_NAME>.content
  forward_to        = [loki.relabel.database_observability_mysql_<DB_NAME>.receiver]
  targets           = prometheus.exporter.mysql.mysql_<DB_NAME>.targets
  exclude_schemas = ["azure_sys", "azure_maintenance"]

  // OPTIONAL: enable these settings if you chose Alloy-managed Performance
  // Schema consumers during database setup. The auto_enable_setup_consumers
  // setting enables the required performance_schema.setup_consumers options.
  // It requires allow_update_performance_schema_settings and UPDATE on
  // performance_schema.setup_consumers.
  allow_update_performance_schema_settings = true

  query_samples {
    auto_enable_setup_consumers = true
  }

  cloud_provider {
    azure {
      resource_group  = "<AZURE_RESOURCE_GROUP>"
      subscription_id = "<AZURE_SUBSCRIPTION_ID>"
      server_name     = "<AZURE_SERVER_NAME>"
    }
  }
}

loki.relabel "database_observability_mysql_<DB_NAME>" {
  forward_to = [loki.write.logs_service.receiver]

  rule {
    target_label = "instance"
    replacement  = "<INSTANCE_LABEL>"
  }
}

discovery.relabel "database_observability_mysql_<DB_NAME>" {
  targets = database_observability.mysql.mysql_<DB_NAME>.targets

  rule {
    target_label = "job"
    replacement  = "integrations/db-o11y"
  }

  // OPTIONAL: relabel `instance` to `dsn` before overwriting `instance`;
  // the `dsn` label is used in the integration with the knowledge graph
  rule {
    source_labels = ["instance"]
    target_label  = "dsn"
  }
  rule {
    target_label = "instance"
    replacement  = "<INSTANCE_LABEL>"
  }
}

prometheus.scrape "database_observability_mysql_<DB_NAME>" {
  targets    = discovery.relabel.database_observability_mysql_<DB_NAME>.output
  forward_to = [prometheus.remote_write.metrics_service.receiver]
}

Replace the placeholders:

• DB_NAME: Database name Alloy uses in component identifiers (appears in component names and secret filenames).
• AZURE_RESOURCE_GROUP: Azure Resource Group for your MySQL Flexible Server.
• AZURE_SUBSCRIPTION_ID: Azure Subscription ID for your MySQL Flexible Server.
• AZURE_SERVER_NAME: Azure Server Name for your MySQL Flexible Server (optional).
• INSTANCE_LABEL: Value that sets the instance label on logs and metrics (optional).
• Secret file content DSN example: DB_USER:DB_PASSWORD@tcp(SERVER_FQDN:DB_PORT)/.
  • DB_USER: Database user Alloy uses to connect (for example, db-o11y).
  • DB_PASSWORD: Password for the database user.
  • SERVER_FQDN: Azure MySQL server fully qualified domain name (for example, <SERVER_NAME>.mysql.database.azure.com).
  • DB_PORT: Database port number (default: 3306).

Find more about the options supported by the database_observability.mysql component in the reference documentation.

The cloud_provider block integrates Database Observability with Cloud Provider Observability. To navigate between query performance and Azure infrastructure metrics, refer to Preconfigured dashboards and alerts for Azure metrics.

Add Prometheus and Loki write configuration

Add Prometheus and Loki write configuration

Add the Prometheus remote write and Loki write configuration. From Grafana Cloud, open your stack to get the URLs and generate API tokens:

Alloy Copy

prometheus.remote_write "metrics_service" {
  endpoint {
    url = sys.env("GCLOUD_HOSTED_METRICS_URL")

    basic_auth {
      password = sys.env("GCLOUD_RW_API_KEY")
      username = sys.env("GCLOUD_HOSTED_METRICS_ID")
    }
  }
}

loki.write "logs_service" {
  endpoint {
    url = sys.env("GCLOUD_HOSTED_LOGS_URL")

    basic_auth {
      password = sys.env("GCLOUD_RW_API_KEY")
      username = sys.env("GCLOUD_HOSTED_LOGS_ID")
    }
  }
}

Replace the placeholders:

• GCLOUD_HOSTED_METRICS_URL: Your Grafana Cloud Prometheus remote write URL.
• GCLOUD_HOSTED_METRICS_ID: Your Grafana Cloud Prometheus instance ID (username).
• GCLOUD_HOSTED_LOGS_URL: Your Grafana Cloud Loki write URL.
• GCLOUD_HOSTED_LOGS_ID: Your Grafana Cloud Loki instance ID (username).
• GCLOUD_RW_API_KEY: Grafana Cloud API token with write permissions.

Troubleshoot first-run issues

If data doesn’t appear after setup:

• If the database instance doesn’t appear in Database Observability, check Alloy connectivity and labels.
• If telemetry status checks fail, use the Configuration page to identify the failed requirement.
• If query metrics appear but samples, wait events, or explain plans are missing, check database privileges and Performance Schema settings.
• If Alloy can’t connect to the database, check firewall rules, virtual network settings, DNS, and the monitoring user’s host restrictions.

For detailed guidance, refer to Troubleshoot Alloy or Troubleshoot MySQL.

Next steps

• View query performance
• Find your application’s queries
• Analyze explain plans