Documentation Grafana Cloud Observe and act Monitor applications Database Observability Set up MySQL Self-managed

Set up self-managed MySQL

Set up Database Observability with Grafana Cloud to collect telemetry from MySQL using Grafana Alloy. You configure your database 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 MySQL for monitoring.
• 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 self-managed MySQL has three steps:

1. Set up your database: Prepare MySQL so Alloy can collect from it.
2. Configure Grafana Alloy: Configure how Alloy collects telemetry and sends it to Grafana Cloud. Self-managed 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:

• A self-managed MySQL 8.0 or later database.
• Permission to modify your MySQL configuration.
• Permission to restart MySQL if configuration 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 MySQL host.

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

Set up your database

In this step, you’ll prepare MySQL for monitoring by enabling Performance Schema, 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 MySQL settings

Enable Performance Schema and related query capture settings in your MySQL configuration. How you configure these values depends on your MySQL deployment and operating system. If you change a startup-only variable, restart MySQL before continuing.

Required settings

Update MySQL configuration

Add or update these settings in your MySQL server configuration file, for example, my.cnf or mysqld.cnf:

ini Copy

[mysqld]
performance-schema=ON
max-digest-length=4096
performance-schema-max-digest-length=4096
performance-schema-max-sql-text-length=4096

Create a monitoring user and grant required privileges

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.

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: Let Alloy manage consumers automatically (recommended)

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.

Option 2: 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.

Disable tracking of monitoring user queries

Database Observability uses Performance Schema to collect query telemetry. If Performance Schema tracks the db-o11y monitoring user, Alloy’s own collection queries can appear in Database Observability as database workload.

Choose one of the following:

Option 1: Let Alloy manage actor tracking automatically (recommended)

Use this method if you want to prepare the database so Alloy can automatically disable tracking for the monitoring user after MySQL restarts.

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

SQL Copy

GRANT INSERT, UPDATE ON performance_schema.setup_actors TO 'db-o11y'@'%';

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

Option 2: Disable tracking manually

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

Check whether a setup_actors row already exists for the monitoring user:

SQL Copy

SELECT *
FROM performance_schema.setup_actors
WHERE USER = 'db-o11y';

If no row is returned, add one:

SQL Copy

INSERT INTO performance_schema.setup_actors
  (HOST, USER, ROLE, ENABLED, HISTORY)
VALUES
  ('%', 'db-o11y', '%', 'NO', 'NO');

If a row exists, disable instrumentation and history for it:

SQL Copy

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

setup_actors settings reset when MySQL restarts. If you use this method, re-apply this configuration after each restart.

Verify user privileges

Verify that the user exists and has the expected privileges:

SQL Copy

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

Confirm the output includes grants equivalent to:

• PROCESS, REPLICATION CLIENT ON *.*
• SELECT ON performance_schema.*
• SELECT, SHOW VIEW ON <SCHEMA_NAME>.*, or SELECT, SHOW VIEW ON *.* if you granted broader read access
• UPDATE ON performance_schema.setup_consumers, if you chose Alloy-managed Performance Schema consumers
• INSERT, UPDATE ON performance_schema.setup_actors, if you chose Alloy-managed Performance Schema actor tracking

Verify MySQL 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 the required monitoring and object privileges, plus the optional Performance Schema grants for any settings you chose Alloy to manage.
• The required Performance Schema consumers are enabled, or Alloy has privileges to manage them automatically.
• Tracking is disabled for the db-o11y monitoring user, or Alloy has privileges to manage actor tracking automatically.
• The db-o11y monitoring user can connect from the network where Alloy will run.
• Any configuration changes that required a restart have been applied and the MySQL restart is complete.

After these checks pass, MySQL is ready for Database Observability. Next, configure Alloy so it can collect telemetry from the database 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: <DB_HOST>
            auth:
              usernameKey: <DB_USERNAME_SECRET_KEY>
              passwordKey: <DB_PASSWORD_SECRET_KEY>
        databaseObservability:
          enabled: true
        secret:
          create: false
          name: <INSTANCE_NAME>
          namespace: mysql
        logs:
          enabled: true
          labelSelectors:
            app.kubernetes.io/instance: <INSTANCE_NAME>

Replace the placeholders:

• INSTANCE_NAME: Name for this database instance in Kubernetes.
• DB_HOST: Hostname or IP address of the database.
• DB_USERNAME_SECRET_KEY: Kubernetes secret key containing database user.
• DB_PASSWORD_SECRET_KEY: Kubernetes secret key containing database password.

To let Alloy keep the required Performance Schema consumers enabled and disable tracking of the monitoring user automatically, add these values to the same databaseObservability block:

YAML Copy

          allowUpdatePerformanceSchemaSettings: true
          collectors:
            querySamples:
              autoEnableSetupConsumers: true
            setupActors:
              autoUpdateSetupActors: true

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

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 MySQL configuration blocks

Add these blocks to Alloy. Replace <DB_NAME>. Create a local.file with the Data Source Name string, for example, <DB_USER>:<DB_PASSWORD>@tcp(<DB_HOST>:<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 {
    limit      = 100
    text_limit = 0
  }
}

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

  // OPTIONAL: enable these settings if you chose Alloy-managed Performance
  // Schema consumers or actor tracking during database setup.
  allow_update_performance_schema_settings = true

  // Requires UPDATE on performance_schema.setup_consumers.
  query_samples {
    auto_enable_setup_consumers = true
  }

  // Requires INSERT and UPDATE on performance_schema.setup_actors.
  setup_actors {
    auto_update_setup_actors = true
  }

  // OPTIONAL: provide additional information specific to the cloud provider
  // that hosts the database to enable infrastructure observability features.
  // For Azure and Google Cloud SQL examples, refer to the platform setup guides.
  cloud_provider {
    aws {
      arn = "<AWS_RDS_DB_ARN>"
    }
  }
}

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

  // OPTIONAL: add any additional relabeling rules
  // (must be consistent with rules in "discovery.relabel")
  rule {
    target_label = "instance"
    replacement  = "<INSTANCE_LABEL>"
  }
  rule {
    target_label = "<CUSTOM_LABEL_1>"
    replacement  = "<CUSTOM_VALUE_1>"
  }
}

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

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

  // OPTIONAL: add any additional relabeling rules
  // (must be consistent with rules in "loki.relabel")
  // 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>"
  }
  rule {
    target_label = "<CUSTOM_LABEL_1>"
    replacement  = "<CUSTOM_VALUE_1>"
  }
}

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).
• AWS_RDS_DB_ARN: Amazon RDS database ARN for cloud provider integration (optional). For Azure or Google Cloud SQL, refer to the Azure MySQL or Cloud SQL MySQL setup guides.
• INSTANCE_LABEL: Value that sets the instance label on logs and metrics (optional).
• CUSTOM_LABEL_1, CUSTOM_VALUE_1: Optional custom label key and value you attach to logs and metrics.
• Secret file content DSN example: DB_USER:DB_PASSWORD@tcp(DB_HOST:DB_PORT)/.
  • DB_USER: Database user Alloy uses to connect (for example, db-o11y).
  • DB_PASSWORD: Password for the database user.
  • DB_HOST: Hostname or IP address of the database.
  • DB_PORT: Database port number.

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

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 network and firewall 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
• Link traces and queries
• Analyze explain plans