Skip to main content

Mysql Receiver

Status Available in: contrib Maintainers: @antonblock, @ishleenk17, @ebrdarSplunk, @XSAM, @akshays-19, @sv-splunk, @splunk-shanu Source: opentelemetry-collector-contrib

Supported Telemetry

Logs Metrics

Overview

This receiver queries MySQL’s global status and InnoDB tables. Some metrics will not appear if their corresponding feature is inactive.
There are also optional metrics that you must specify in your configuration to collect, listed in documentation.md

Prerequisites

The receiver detects the database product and version on first connection and adjusts its behavior accordingly.

Supported database versions

See COMPATIBILITY.md for full details on version-gated behavior and fallbacks. Collecting most metrics requires the ability to execute SHOW GLOBAL STATUS. Collecting query samples requires the performance_schema to be enabled:
Collecting disabled-by-default InnoDB redo-log LSN and checkpoint-age metrics requires MySQL 8.0.11 or later. For MySQL 8.0.11 through 8.0.29, grant the receiver user SELECT on performance_schema and the BACKUP_ADMIN dynamic privilege:
MySQL 8.0.30 and later versions do not require BACKUP_ADMIN for these metrics.

Configuration

The following settings are optional:
  • endpoint: (default = localhost:3306)
  • tls: Defines the TLS configuration to use. If tls is not set, the default is to disable TLS connections.
    • insecure: (default = false) Set this to true to disable TLS connections.
    • insecure_skip_verify: (default = false) Set this to true to enable TLS but not verify the certificate.
    • server_name_override: This sets the ServerName in the TLSConfig.
  • username: (default = root)
  • password: A static MySQL password.
  • db_auth: Component ID of a dbauth provider extension (for example aws_iam_db_auth). Mutually exclusive with password. Requires TLS (tls.insecure: false). RDS MySQL/Aurora MySQL only. Cleartext password auth (mysql_clear_password) is enabled automatically for IAM tokens over TLS.
  • allow_native_passwords: (default = true)
  • database: The database name. If not specified, metrics will be collected for all databases.
  • collection_interval (default = 10s): This receiver collects metrics on an interval. This value must be a string readable by Golang’s time.ParseDuration. Valid time units are ns, us (or µs), ms, s, m, h.
  • initial_delay (default = 1s): defines how long this receiver waits before starting.
  • transport: (default = tcp): Defines the network to use for connecting to the server.
  • statement_events: Additional configuration for query to build mysql.statement_events.count and mysql.statement_events.wait.time metrics:
    • digest_text_limit - maximum length of digest_text. Longer text will be truncated (default=120)
    • time_limit - maximum time from since the statements have been observed last time (default=24h)
    • limit - limit of records, which is maximum number of generated metrics (default=250)
  • query_sample_collection: Additional configuration for query sample collection(db.server.query_sample event):
    • max_rows_per_query - maximum number of rows to collect per scrape (default=100)
  • top_query_collection: Additional configuration for top queries collection (db.server.top_query event):
    • lookback_time (optional, example = 60, default = 2 * collection_interval): The time window (in seconds) in which to query for top queries.
      • Queries that finished execution outside the lookback window are not included in the collection. Increasing the lookback window will be useful for capturing long-running queries.
    • max_query_sample_count (optional, example = 5000, default = 1000): The maximum number of records to fetch in a single run.
    • top_query_count: (optional, example = 100, default = 200): The maximum number of active queries to report (to the next consumer) in a single run.
    • collection_interval: (optional, default = 60s): The interval at which top queries should be emitted by this receiver.
      • This value can only guarantee that the top queries are collected at most once in this interval.
        • For instance, you have global collection_interval set to 10s and top_query_collection.collection_interval set to 60s.
          • In this case, the default receiver scraper will still run every 10 seconds.
          • However, the top queries collection will only run after 60 seconds have passed since the last collection.
        • For instance, you have global collection_interval set to 10s and top_query_collection.collection_interval set to 5s.
          • In this case, top_query_collection.collection_interval will have no impact on the collection frequency, which will run every 10s.
    • query_plan_cache_size: (optional, default = 1000). The query plan cache size. Once we got query plan results from explain queries, we will store them in the cache. This defines the cache’s size for query plan.
    • query_plan_cache_ttl: (optional, example = 1m, default = 1h). How long until a query plan expires in the cache. The receiver will run an explain query to MySQL to get the query plan after it expires.

Example Configuration

The full list of settings exposed for this receiver are documented in config.go with detailed sample configurations in testdata/config.yaml.

Resource attributes

The receiver reports the network location of the monitored instance as the server.address and server.port resource attributes. When endpoint is a loopback address (for example localhost:3306 or 127.0.0.1:3306), server.address reports the host name of the machine running the collector rather than the configured host. A loopback endpoint is only reachable when the instance is co-located with the collector, so the collector host’s name is the instance’s real network identity; reported verbatim, every monitored host would emit the same address. A non-loopback endpoint is reported as configured. With transport: unix, server.address is the socket path and server.port is not reported. Both attributes are enabled by default and can be turned off individually:

Metrics

Details about the metrics produced by this receiver can be found in metadata.yaml

Logs

Details about the logs produced by this receiver can be found in documentation.md Trace propagation: Query sample log records carry a TraceID and SpanID only when a MySQL session sets the @traceparent user variable (W3C TraceContext format, lowercase name). The collector extracts the TraceID and SpanID from that value and stamps the application’s trace context onto the corresponding log record. Log records without a @traceparent will have empty TraceID and SpanID fields. This allows application transactions to be correlated with query samples collected by this receiver.
Note: MySQL stores user variable names in lowercase in performance_schema.user_variables_by_thread regardless of how the client spelled them. The JOIN condition VARIABLE_NAME = 'traceparent' therefore matches any case variation the client used (e.g. SET @TraceParent = '...' works identically to SET @traceparent = '...').

Query plan availability by version

EXPLAIN needs a concrete SQL statement. The normalized digest text in events_statements_summary_by_digest uses placeholders (SELECT ? FROM t WHERE id = ?), which MySQL will not execute. MySQL 8.0 added query_sample_text to events_statements_summary_by_digest. It holds an actual statement that was run for each digest, so the top-query scraper can call EXPLAIN without needing to catch the query in flight. MariaDB and MySQL 5.x do not have query_sample_text, so the top-query scraper has nothing to EXPLAIN. Query plans are not available for these versions. If a statement is truncated (the stored text ends with ...), the receiver skips EXPLAIN for that statement on all versions. Truncation is controlled by performance_schema_max_sql_text_length (default 1024). Setting it to 4096 is recommended — see the requirements table below.

Splitting the execution plan onto its own event

db.server.top_query and db.server.query_sample each carry the statement’s execution plan in their mysql.query_plan attribute. The plan is the output of EXPLAIN FORMAT=json, a nested document with one object per table access, so it can dominate the record it travels on. Enabling db.server.query_plan reports the plan on a record of its own, where it can be filtered, routed or dropped independently of the query statistics and the session activity, and where an oversized plan does not take those with it when a batcher splits by size. It is disabled by default. It reports plans that db.server.top_query and db.server.query_sample already collect, so it adds no queries and needs no grants of its own, and enabling it without either of those events is a configuration error. Each of them contributes plans only while it is itself enabled.
Both source events are then emitted without their mysql.query_plan attribute, and the plan is reported on db.server.query_plan, joined back via mysql.query_plan.hash and db.namespace. A statement with no plan available produces no record. mysql.query_plan.source holds the name of the event each plan was reported for, so one literal matches both the attribute and the record’s event name in a routing rule, and plans from one source can be routed or dropped without touching the other. The two differ in cadence and volume: top query plans follow top_query_collection.collection_interval and are bounded by top_query_count, while sample plans follow the receiver’s collection_interval. Several sessions can be running one statement when a sample scrape fires, and they share a plan, so sample plans are reported once per scrape rather than once per sample. Plans are identified by db.namespace and mysql.query_plan.hash, which means:
  • One digest executed in several databases produces one record per database, since the plan is collected per database. performance_schema.events_statements_summary_by_digest is keyed on schema and digest, so such a digest also produces one db.server.top_query record per database, and db.namespace is what pairs each of those with its own plan.
  • db.server.top_query reports the database as the schema_name the statement was summarized under, while db.server.query_sample reports the session’s current database. For one statement these can differ, so the same plan can appear under two db.namespace values across the two events.
On MySQL 5.7 and MariaDB there is no query_sample_text to explain, so db.server.top_query has no plan to report on those versions (see the table under Supported database versions) and enabling db.server.query_plan there reports sample plans only.

MySQL Requirements to enable log collection

Enabling events_waits_current for lock-wait duration

The mysql.events_waits_current.timer_wait attribute on db.server.query_sample events is populated from performance_schema.events_waits_current. That consumer is disabled by default on all supported platforms. Without it, timer_wait is always 0.

Required privilege

The database user must have UPDATE on performance_schema.setup_consumers in addition to the SELECT grant above:

Enabling the consumer

Manual server (MySQL 5.7 / 8.x / MariaDB) — persistent across restarts Add to [mysqld] in my.cnf / my.ini:
AWS RDS (MySQL 5.7 / 8.x / MariaDB) — runtime only AWS RDS does not expose performance-schema-consumer-events-waits-current as a parameter group setting. The consumer must be enabled at runtime and will reset on instance restart or failover:
Run this statement after each restart, or grant the receiver user UPDATE on performance_schema.setup_consumers so that the receiver can re-enable it automatically on reconnect.

Metrics

Attributes

Resource Attributes

Configuration

Example Configuration


Last generated: 2026-10-05