Documentation Grafana Alloy Reference Components database_observability database_observability.mysql

database_observability.mysql

database_observability.mysql connects to a MySQL database and collects observability data from the performance_schema and information_schema. The component collects query details, schema information, explain plans, query samples, and lock information. It forwards this data as log entries to Loki receivers and exports targets for Prometheus scraping.

Usage

Alloy Copy

database_observability.mysql "<LABEL>" {
  data_source_name = <DATA_SOURCE_NAME>
  forward_to       = [<LOKI_RECEIVERS>]
}

Arguments

You can use the following arguments with database_observability.mysql:

The following collectors are configurable:

Blocks

You can use the following blocks with database_observability.mysql:

cloud_provider

The cloud_provider block has no attributes. It contains zero or one of the aws, azure, or gcp blocks. You use the cloud_provider block to provide information related to the cloud provider that hosts the database under observation. This information is appended as labels to the collected metrics. The labels make it easier for you to filter and group your metrics.

aws

The aws block supplies the ARN identifier for the database being monitored.

azure

The azure block supplies the identifying information for the database being monitored.

gcp

The gcp block supplies the identifying information for the GCP Cloud SQL database being monitored.

database_instance

The database_instance block defines one database server to monitor. Repeat the block to monitor several databases with a single component. The block label must be unique across database_instance blocks and identifies the database in the component’s metrics endpoint path. Each database_instance block must also point to a distinct server: two blocks that resolve to the same host, port, and database name are rejected.

Each database_instance block can also contain a [cloud_provider][cloud_provider] block that applies to that database only.

The component always embeds a mysqld_exporter for each database_instance block and serves its metrics on the block’s metrics path. Use the [prometheus_exporter][prometheus_exporter] block to configure it. External exporter targets are only supported in the top-level single-DSN form.

When you define database_instance blocks, don’t set the top-level data_source_name, targets, and cloud_provider arguments. They’re mutually exclusive with database_instance blocks. All other arguments and blocks, such as collector settings and prometheus_exporter, apply to every configured database.

The metrics for each database are served on a separate /db/<LABEL>/metrics path under the component’s HTTP endpoint, and the exported targets point to the corresponding path. When you don’t define database_instance blocks, the component serves metrics on its historical /metrics path. The metrics endpoints are served exactly at those paths: requests to any other path under the component’s HTTP endpoint return HTTP 404.

For example:

Alloy Copy

database_observability.mysql "pool" {
  forward_to = [loki.write.logs_service.receiver]

  database_instance "orders" {
    data_source_name = sys.env("ORDERS_DSN")

    cloud_provider {
      aws {
        arn = "orders-rds-db-arn"
      }
    }
  }

  database_instance "billing" {
    data_source_name = sys.env("BILLING_DSN")
  }
}

clustering

When Alloy is using clustering, and enabled is set to true, then this database_observability.mysql component instance opts-in to distributing its configured databases between all cluster nodes.

Clustering assumes that all cluster nodes are running with the same configuration file. All component instances opting in to clustering use the instance key of each configured database, <network>(<host>:<port>)/<dbname>, and a consistent hashing algorithm to determine ownership of each database between the cluster peers. Each peer then only collects from the subset of databases it’s responsible for, and only exports the targets of those databases, so prometheus.scrape components on the same node scrape exactly the databases the node owns. When a node joins or leaves the cluster, every peer recalculates ownership: expect a short gap or a brief duplicate collection for a database while its ownership moves. This includes the collectors that update performance_schema settings, such as setup_actors and setup_consumers, which can briefly run from two nodes during the move: their updates are idempotent. While the cluster isn’t yet ready to admit traffic, for example while it’s still forming and waiting for the minimum cluster size, the component doesn’t collect from any database.

Clustering is also useful with a single database: when several cluster nodes run an identical configuration, exactly one node collects from the database at a time, which gives you a highly available setup without duplicate collection.

If Alloy is not running in clustered mode, then the block is a no-op and database_observability.mysql collects from every configured database.

setup_consumers

query_details

schema_details

The cache_enabled, cache_size, and cache_ttl settings are deprecated: they are accepted for backward compatibility, but ignored.

explain_plans

locks

query_samples

setup_actors

health_check

prometheus_exporter

The prometheus_exporter block configures the embedded mysqld_exporter scrapers. The data_source_name is inherited from the parent block.

Refer to prometheus.exporter.mysql docs for the full list of supported arguments and sub-blocks.

Exported fields

The following fields are exported and can be referenced by other components.

Example

Alloy Copy

database_observability.mysql "<LABEL>" {
  data_source_name = "<DATA_SOURCE_NAME>"
  forward_to       = [loki.relabel.<LABEL>.receiver]

  enable_collectors = ["query_samples", "explain_plans"]

  cloud_provider {
    aws {
      arn = "<AWS_RDS_ARN>"
    }
  }
}

Replace the following:

• <LABEL>: The Alloy component label (for example, prod_mysql).
• <DATA_SOURCE_NAME>: The MySQL connection Data Source Name (for example, user:pass@tcp(mysql:3306)/).
• <AWS_RDS_ARN>: The ARN of your AWS RDS database (for example, arn:aws:rds:us-east-1:123456789:db/prod-mysql).

For a complete end-to-end example that demonstrates sending database observability metrics to Grafana Cloud, refer to Collect MySQL database metrics and logs.

Compatible components

database_observability.mysql can accept arguments from the following components:

• Components that export Targets
• Components that export Loki LogsReceiver

database_observability.mysql has exports that can be consumed by the following components:

• Components that consume Targets