Mysql Receiver
contrib
Maintainers: @antonblock, @ishleenk17, @ebrdarSplunk, @XSAM, @akshays-19, @sv-splunk, @splunk-shanu
Source: opentelemetry-collector-contrib
Supported Telemetry
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:
SELECT on performance_schema and the BACKUP_ADMIN dynamic privilege:
BACKUP_ADMIN for these metrics.
Configuration
The following settings are optional:endpoint: (default =localhost:3306)tls: Defines the TLS configuration to use. Iftlsis not set, the default is to disable TLS connections.insecure: (default =false) Set this totrueto disable TLS connections.insecure_skip_verify: (default =false) Set this totrueto 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 adbauthprovider extension (for exampleaws_iam_db_auth). Mutually exclusive withpassword. 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 arens,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 buildmysql.statement_events.countandmysql.statement_events.wait.timemetrics:digest_text_limit- maximum length ofdigest_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_sampleevent):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_queryevent):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_intervalset to10sandtop_query_collection.collection_intervalset to60s.- 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_intervalset to10sandtop_query_collection.collection_intervalset to5s.- In this case,
top_query_collection.collection_intervalwill have no impact on the collection frequency, which will run every 10s.
- In this case,
- For instance, you have global
- This value can only guarantee that the top queries are collected at most once in this interval.
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
Resource attributes
The receiver reports the network location of the monitored instance as theserver.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.yamlLogs
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 inperformance_schema.user_variables_by_threadregardless of how the client spelled them. The JOIN conditionVARIABLE_NAME = 'traceparent'therefore matches any case variation the client used (e.g.SET @TraceParent = '...'works identically toSET @traceparent = '...').
Query plan availability by version
EXPLAIN needs a concrete SQL statement. The normalized digest text inevents_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.
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_digestis keyed on schema and digest, so such a digest also produces onedb.server.top_queryrecord per database, anddb.namespaceis what pairs each of those with its own plan. db.server.top_queryreports the database as theschema_namethe statement was summarized under, whiledb.server.query_samplereports the session’s current database. For one statement these can differ, so the same plan can appear under twodb.namespacevalues across the two events.
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 haveUPDATE 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:
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:
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