How to Monitor MySQL with OpenTelemetry

What to observe in MySQL

The signals that predict MySQL trouble are connection usage against max_connections, query throughput and slow queries, InnoDB buffer-pool efficiency, lock waits and deadlocks, and replication lag. As with any relational database, slow queries and locking are the common paths to user-facing latency, and a buffer pool that no longer holds the working set turns fast reads into disk reads.

The highest-value view ties a slow application request to the exact statement behind it, so database metrics are most useful alongside application spans that carry the SQL as an attribute.

How OpenTelemetry collects it

The Collector's mysql receiver connects as a monitoring user and reads the server and InnoDB status, emitting connection, throughput, buffer-pool, lock and handler metrics over OTLP. The slow-query log, enabled with long_query_time, is collected with the filelog receiver so the actual slow statements are visible.

The permission detail is the monitoring user: grant it the process and replication-client privileges and read on the performance schema, or the receiver returns partial data. Application spans carrying the statement complete the picture.

Key metrics to watch

The signals that explain most MySQL incidents:

What to put on a dashboard

A MySQL dashboard should answer: are we out of connections, is the buffer pool still absorbing reads, and is anything locked or lagging. Row one: connections against max_connections and slow-query rate. Row two: buffer-pool hit efficiency and lock waits/deadlocks. Row three: replication lag per replica and throughput by command type.

# connection saturation
mysql.threads{kind="connected"} / mysql_max_connections

# buffer pool read efficiency (disk reads climbing = pool too small)
rate(mysql.buffer_pool.operations{operation="reads"}[5m])

# lock waits trending up = contention
rate(mysql.locks[5m])

Reading the signals: common failure modes

Connection exhaustion

Applications hit 'too many connections' and latency spikes as requests wait for a slot. Connected threads sit at max_connections. The cause is usually a missing connection pooler or a leak of unclosed connections; pool in front of MySQL rather than only raising the limit.

Buffer pool too small

Read latency and disk I/O rise because queries are reading from disk instead of the InnoDB buffer pool. The disk-read counter climbs. Either the working set has outgrown the pool or a query is scanning far more rows than needed, findable in the slow-query log.

Deadlocks and lock waits

Some transactions stall or roll back while others proceed, and deadlock counts rise, because concurrent transactions contend for the same rows in a conflicting order. Find the statements involved; the fix is usually indexing, shorter transactions, or a consistent lock order.

Example alert conditions

Starting thresholds to tune:

From monitoring to autonomous resolution

Ops Singularity's TelemetryOps ingests MySQL telemetry over OpenTelemetry, and Sentinel AI resolves database incidents through governed Action Tickets. Explore TelemetryOps.