Documentation Grafana Cloud Monitor applications Database Observability Set up MySQL Amazon Aurora

Set up Amazon Aurora MySQL

Set up Database Observability with Grafana Cloud to collect telemetry from Amazon Aurora MySQL clusters using Grafana Alloy. You configure your Aurora cluster 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 Amazon Aurora MySQL cluster parameter groups 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 Aurora MySQL has three steps:

1. Set up your database: Prepare your Aurora cluster so Alloy can collect from it.
2. Configure Grafana Alloy: Configure how Alloy collects telemetry and sends it to Grafana Cloud. Aurora 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 Amazon Aurora MySQL 8.0 or later cluster.
• Permission to modify the Aurora cluster parameter group.
• Permission to reboot the Aurora cluster 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 each Aurora instance endpoint.

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

Set up your database

In this step, you’ll prepare your Aurora MySQL cluster 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 the DB parameter group

Enable Performance Schema and related instrumentation by configuring your Aurora MySQL cluster parameter group. These parameters require a cluster restart to take effect.

If these values are already enabled on the parameter group attached to your cluster, you don’t need to change them or restart the cluster. If you update any parameter that requires a reboot, plan a maintenance window and wait for the cluster restart to complete before continuing.

Required parameters

Use the Amazon RDS console

1. Open the RDS Console and navigate to Parameter groups.
2. Create a new parameter group or modify an existing one with family aurora-mysql8.0.
3. Set the parameters listed above.
4. Apply the parameter group to your Aurora cluster.
5. Reboot the cluster to apply changes.

For detailed console instructions, refer to Working with parameter groups in the AWS documentation.

Use Terraform

Using Terraform with the terraform-aws-modules/rds-aurora/aws module:

hcl Copy

create_db_parameter_group = true
db_parameter_group_family = "aurora-mysql8.0"
db_parameter_group_parameters = [
  {
    name         = "performance_schema"
    value        = "1"
    apply_method = "pending-reboot"
  },
  {
    name         = "performance-schema-consumer-events-waits-current"
    value        = "ON"
    apply_method = "pending-reboot"
  },
  {
    name         = "performance_schema_consumer_events_waits_history"
    value        = "ON"
    apply_method = "pending-reboot"
  },
  {
    name         = "performance_schema_consumer_global_instrumentation"
    value        = "1"
    apply_method = "pending-reboot"
  },
  {
    name         = "performance_schema_consumer_thread_instrumentation"
    value        = "1"
    apply_method = "pending-reboot"
  },
  {
    name         = "performance_schema_max_digest_length"
    value        = "4096"
    apply_method = "pending-reboot"
  },
  {
    name         = "performance_schema_max_sql_text_length"
    value        = "4096"
    apply_method = "pending-reboot"
  },
  {
    name         = "max_digest_length"
    value        = "4096"
    apply_method = "pending-reboot"
  }
]

Or using a standalone aws_db_parameter_group resource:

hcl Copy

resource "aws_db_parameter_group" "aurora_mysql_monitoring" {
  name   = "<CLUSTER_NAME>-monitoring-params"
  family = "aurora-mysql8.0"

  parameter {
    name         = "performance_schema"
    value        = "1"
    apply_method = "pending-reboot"
  }

  parameter {
    name         = "performance-schema-consumer-events-waits-current"
    value        = "ON"
    apply_method = "pending-reboot"
  }

  parameter {
    name         = "performance_schema_consumer_events_waits_history"
    value        = "ON"
    apply_method = "pending-reboot"
  }

  parameter {
    name         = "performance_schema_consumer_thread_instrumentation"
    value        = "1"
    apply_method = "pending-reboot"
  }

  parameter {
    name         = "performance_schema_max_digest_length"
    value        = "4096"
    apply_method = "pending-reboot"
  }

  parameter {
    name         = "performance_schema_max_sql_text_length"
    value        = "4096"
    apply_method = "pending-reboot"
  }

  parameter {
    name         = "max_digest_length"
    value        = "4096"
    apply_method = "pending-reboot"
  }
}

Replace <CLUSTER_NAME> with your Aurora cluster name.

After applying the parameter group to your cluster, restart the cluster for the changes to take effect.

Create a monitoring user and grant required privileges

Connect to your Aurora MySQL cluster 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 parameter group 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 reboot have been applied and the cluster restart is complete.

After these checks pass, Aurora is ready for Database Observability. Next, configure Alloy so it can collect telemetry from the Aurora instance endpoints 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: <DB_NAME>
        jobLabel: integrations/db-o11y
        exporter:
          enabled: true
          collectors:
            perfSchemaEventsStatements:
              enabled: true
          dataSource:
            host: <INSTANCE_ENDPOINT> # Must be specific instance endpoint
            auth:
              usernameKey: <DB_USERNAME_SECRET_KEY>
              passwordKey: <DB_PASSWORD_SECRET_KEY>
        databaseObservability:
          enabled: true
          allowUpdatePerformanceSchemaSettings: true
          extraConfig: |
            exclude_schemas = ["rdsadmin"]
            cloud_provider {
              aws {
                arn = "<AWS_AURORA_INSTANCE_ARN>"
              }
            }
        secret:
          create: false
          name: <DB_NAME>
          namespace: mysql
        logs:
          enabled: true
          labelSelectors:
            app.kubernetes.io/instance: <DB_NAME>

Replace the placeholders:

• DB_NAME: Database name Alloy uses in component identifiers (appears in component names and secrets).
• INSTANCE_ENDPOINT: The specific instance endpoint. Do not use the Cluster Endpoint here; doing so breaks metric correlation during role changes.
• DB_USERNAME_SECRET_KEY: Kubernetes secret key containing database user.
• DB_PASSWORD_SECRET_KEY: Kubernetes secret key containing database password.
• AWS_AURORA_INSTANCE_ARN: The specific Amazon Aurora instance Amazon Resource Name.

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

Configure AWS Secrets Manager and Kubernetes (optional)

If you use AWS Secrets Manager with External Secrets Operator to manage database credentials, configure them as follows.

Secret path convention

Store monitoring credentials in AWS Secrets Manager at a path following this convention:

Copy

/kubernetes/rds/<CLUSTER_NAME>/monitoring

MySQL secret format

Store the secret as JSON with the following format:

JSON Copy

{
  "username": "db-o11y",
  "password": "<DB_O11Y_PASSWORD>",
  "engine": "mysql",
  "host": "<INSTANCE_ENDPOINT>.rds.amazonaws.com",
  "port": 3306,
  "dbClusterIdentifier": "<CLUSTER_NAME>"
}

Replace the placeholders:

• DB_O11Y_PASSWORD: Password for the db-o11y MySQL user.
• INSTANCE_ENDPOINT: The specific instance endpoint. Do not use the Cluster Endpoint here; doing so breaks metric correlation during role changes.
• CLUSTER_NAME: Aurora cluster name.

Create the secret with the AWS CLI

Bash Copy

aws secretsmanager create-secret \
  --name "/kubernetes/rds/<CLUSTER_NAME>/monitoring" \
  --description "Alloy monitoring credentials for Aurora MySQL cluster" \
  --secret-string '{"username":"db-o11y","password":"<DB_O11Y_PASSWORD>","engine":"mysql","host":"<INSTANCE_ENDPOINT>.rds.amazonaws.com","port":3306,"dbClusterIdentifier":"<CLUSTER_NAME>"}'

Kubernetes External Secrets configuration

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

YAML Copy

---
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: <CLUSTER_NAME>-db-monitoring-secretstore
spec:
  provider:
    aws:
      service: SecretsManager
      region: <AWS_REGION>
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: <CLUSTER_NAME>-db-monitoring-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: <CLUSTER_NAME>-db-monitoring-secretstore
  dataFrom:
    - extract:
        conversionStrategy: Default
        decodingStrategy: None
        key: /kubernetes/rds/<CLUSTER_NAME>/monitoring
        metadataPolicy: None
        version: AWSCURRENT

Replace the placeholders:

• CLUSTER_NAME: Aurora cluster name.
• AWS_REGION: AWS region where the secret is stored.

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

Add these blocks to Alloy for Aurora MySQL. Replace <DB_NAME>. Create a local.file with the Data Source Name string, for example, <DB_USER>:<DB_PASSWORD>@tcp(<INSTANCE_ENDPOINT>:<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 = ["rdsadmin"]
    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   = ["rdsadmin"]

  // 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 {
    aws {
      arn = "<AWS_AURORA_INSTANCE_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>"
  }
}

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

  // OPTIONAL: add any additional relabeling rules
  // (must be consistent with rules in "loki.relabel")
  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>"
  }
  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_AURORA_INSTANCE_ARN: The specific Amazon Aurora instance Amazon Resource Name for cloud provider integration. Do not use the cluster Amazon Resource Name.
• INSTANCE_LABEL: Value that sets the instance label on logs and metrics (optional).
• Secret file content DSN example: DB_USER:DB_PASSWORD@tcp(INSTANCE_ENDPOINT:DB_PORT)/.
  • DB_USER: Database user Alloy uses to connect (for example, db-o11y).
  • DB_PASSWORD: Password for the database user.
  • INSTANCE_ENDPOINT: The specific instance endpoint. Do not use the Cluster Endpoint here; doing so breaks metric correlation during role changes.
  • 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 AWS infrastructure metrics, refer to Preconfigured dashboards and alerts.

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 security groups, subnets, 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