MySQL monitoring: InnoDB, slow queries and replication
Watch threads, InnoDB buffer pool, row locks and replica delay for every MySQL server, and link slow queries to the requests that issued them.
Why monitor MySQL with Obseria
Slow queries with a caller
Slow query log entries and database spans in one place show which endpoint and which deployment caused a regression.
InnoDB health in context
Buffer pool usage, page flushes and row lock waits next to host disk and CPU metrics explain why latency rises.
Replicas you can rely on
Seconds behind source per replica, with alerts before read traffic sees stale data or failover takes longer than planned.
MySQL components Obseria monitors
- Server status. Global status counters such as threads, operations, handlers, sorts and temporary tables.
- InnoDB buffer pool. Pages by state, usage in bytes, read requests versus disk reads and page flushes.
- Locks. Table locks and InnoDB row lock waits and time, the main sources of contention.
- Replication. Seconds behind source and configured SQL delay for each replica.
- Performance schema. Table and index I/O wait counts and times from performance_schema.
- Slow query log. Slow query log lines collected with the filelog receiver and searchable next to metrics.
The MySQL signals that matter
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.Database connections
Shows how many users and applications are connected and whether connection attempts are failing or being refused.
Memory efficiency
Tells you how well the database keeps frequently used data in fast memory instead of reading from slow disks.
Workload and slow queries
Reveals how much work the database handles, where requests wait for each other and which queries take too long.
Replication status
Shows whether backup copies of your data keep up with the main database, so a switchover loses nothing.
Show all 10 metrics in detail
| Metric | Unit | What it tells you |
|---|---|---|
mysql.threads | 1 | Connected, running, cached and created threads; running threads show real concurrency. |
mysql.connection.errors | 1 | Connection errors by type, including hitting max_connections. |
mysql.buffer_pool.usage | By | Bytes in the InnoDB buffer pool by state (data, dirty). |
mysql.buffer_pool.operations | 1 | Read requests and disk reads; their ratio is the buffer pool hit rate. |
mysql.buffer_pool.page_flushes | 1 | Pages flushed from the buffer pool; spikes indicate write pressure. |
mysql.row_locks | 1 | InnoDB row lock waits and lock time, the core contention signal. |
mysql.operations | 1 | InnoDB fsync, read and write operations for I/O load analysis. |
mysql.query.slow.count | 1 | Queries that exceeded long_query_time. |
mysql.replica.time_behind_source | s | Seconds a replica lags behind its source. |
mysql.tmp_resources | 1 | Temporary tables and files created, often on disk for large sorts. |
Set up MySQL monitoring in minutes
- Step 1
Create a monitoring user
Create a dedicated MySQL user with PROCESS, REPLICATION CLIENT and SELECT on performance_schema, and keep the password in an environment variable.
- Step 2
Configure the mysql receiver
Add the mysql receiver to the OpenTelemetry Collector or Obseria Agent and enable optional metrics such as slow query count and replica delay.
- Step 3
Collect slow logs and traces
Enable the slow query log, ship it with the filelog receiver and instrument the calling services with OpenTelemetry.
receivers:
mysql:
endpoint: localhost:3306
username: otel_monitor
password: ${env:MYSQL_PASSWORD}
collection_interval: 30s
metrics:
mysql.query.slow.count:
enabled: true
mysql.replica.time_behind_source:
enabled: true
mysql.connection.errors:
enabled: true
filelog/mysql_slow:
include: [/var/log/mysql/mysql-slow.log]
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [mysql]
exporters: [otlphttp]
logs:
receivers: [filelog/mysql_slow]
exporters: [otlphttp]
Out of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- MySQL overview: threads, queries and connection errors
- InnoDB buffer pool and I/O
- Row locks and lock time
- Alert: replica more than 30 seconds behind source
- Alert: slow queries above baseline
MySQL monitoring: what matters
Why MySQL monitoring matters
MySQL runs a large share of the web: shops, content platforms, SaaS backends. Its default storage engine InnoDB is robust, but it is sensitive to memory sizing, lock contention and inefficient queries. When MySQL slows down, the effect shows up as slow page loads and API timeouts in the services above it. MySQL monitoring makes the causes visible: concurrency, buffer pool efficiency, locking, slow statements and replication delay.
Obseria collects MySQL metrics with the mysql receiver of the OpenTelemetry Collector, which reads global status counters, InnoDB statistics and performance_schema tables. Slow query logs and database spans from your applications complete the picture.
The MySQL metrics that matter
Threads and connections
mysql.threads distinguishes connected from running threads. Many connected but few running threads usually means idle pool connections. A high number of running threads means real concurrency, and if it exceeds the CPU cores for long, queries queue. mysql.connection.errors shows when clients are rejected, for example because max_connections is reached.
InnoDB buffer pool
The buffer pool caches data and index pages. From mysql.buffer_pool.operations, the ratio of disk reads to read requests gives the buffer pool hit rate. If more reads go to disk over time, the working set has outgrown innodb_buffer_pool_size. mysql.buffer_pool.usage and mysql.buffer_pool.page_flushes show how many dirty pages build up and how hard InnoDB has to flush.
Locks
mysql.row_locks reports row lock waits and accumulated lock time. Rising waits usually come from long transactions, hot rows such as counters, or missing indexes that make updates lock more rows than necessary.
Queries and replication
mysql.query.slow.count counts statements above long_query_time. mysql.replica.time_behind_source shows how far each replica is behind; reads from lagging replicas return stale data.
Common problems and how to detect them
- Too many connections: connection errors climb and threads connected sits at the limit. Check pool sizes per service and timeouts for idle connections.
- Buffer pool too small: disk reads rise relative to read requests, together with higher disk latency on the host.
- Lock contention: row lock waits rise while throughput falls. Look at long-running transactions and the statements in database spans around that time.
- Disk-based temporary tables:
mysql.tmp_resourcesgrows for large GROUP BY or ORDER BY queries; better indexes or query rewrites help. - Replica lag: large write batches or single-threaded apply. Consider parallel replication and correlate lag with write throughput on the source.
Best practices for MySQL monitoring
- Use a dedicated monitoring user with minimal privileges instead of root.
- Enable the slow query log with a realistic
long_query_timeand ship it centrally instead of reading it on the server. - Keep performance_schema enabled; it provides table and index I/O wait statistics with modest overhead.
- Alert on symptoms such as connection errors, replica delay and query latency of database spans, not on every counter.
- Monitor managed instances such as Amazon RDS or Aurora MySQL with the same receiver plus the provider metrics, so self-hosted and managed look alike.
How Obseria helps with MySQL monitoring
Obseria stores MySQL metrics, slow query logs and database spans together in Obseria Lake. TopoGraph shows which services talk to which MySQL server, so an alert on replica lag or lock waits immediately shows the affected applications. Obseria Intelligence correlates a latency increase with deployments, specific statements and host metrics and lays out the likely root cause with a chain of evidence. For Amazon RDS, Aurora and other managed MySQL offerings, the agentless cloud integrations add provider metrics without an agent on the database host.
Dashboards, alerts and SLOs are included. With OQL you can, for example, count slow query log entries per statement fingerprint and compare them with the p95 duration of the matching database spans before and after a release. Obseria Pipeline masks sensitive values in logged queries before they are stored.
Related integrations
Related capabilities
Database Monitoring
Find the slow query behind a slow endpoint. Obseria links database metrics, query performance and logs to the traces and services that call them.
Learn moreDistributed Tracing
Follow each request across services, queues and databases with OpenTelemetry-native distributed tracing, and find the slow span or failing dependency in seconds.
Learn moreAnomaly Detection
Obseria Intelligence learns the normal rhythm of every service, flags real deviations instead of threshold noise and groups related anomalies into one problem with a probable root cause.
Learn moreLearn more
The four golden signals: latency, traffic, errors and saturation
The four golden signals explained: latency, traffic, errors and saturation, how they relate to the RED and USE methods, and how to measure them with OTel.
What is root cause analysis (RCA)?
What is root cause analysis? The RCA process for software incidents, 5 Whys, fishbone and fault tree methods, a worked example and how AI speeds up RCA.
MySQL monitoring FAQ
The OpenTelemetry mysql receiver works with MySQL 8 and with managed services such as Amazon RDS for MySQL and Aurora MySQL. Some optional metrics depend on performance_schema being enabled.
PROCESS and REPLICATION CLIENT for status and replication data, plus SELECT on performance_schema. No access to application schemas is required.
It combines the slow query log, the mysql.query.slow.count metric and database spans from your services, so you see the statement, its frequency and the endpoint that issued it.
Yes. Enable mysql.replica.time_behind_source in the receiver and alert when a replica lags more than your read consistency tolerates.
You decide. Obseria Pipeline can mask or drop literals and other sensitive values at ingest, before anything is written to storage.
Start monitoring MySQL today
Connect MySQL in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.