What goes in a MySQL monitoring dashboard in Metabase?

A MySQL monitoring dashboard tracks statement throughput and latency percentiles alongside the four things that actually take a MySQL server down: index-less queries, buffer pool misses, connection exhaustion, and replication lag. Metabase connects to MySQL natively, so every card is plain SQL over performance_schema and the sys views — no exporter or agent in between.

What does a MySQL monitoring dashboard look like?

Here’s the layout this guide builds. Server-level numbers sit at the top; the middle section is the workload — statements by type, latency percentiles, the slow-query trend, and buffer pool efficiency; the bottom section is the three resources that run out, namely connections, locks, and replication headroom.

Which cards belong on a MySQL monitoring dashboard?

Eight cards. Percentiles rather than averages for latency, rows examined per row returned charted as its own trend, and the three exhaustible resources — connections, locks, replica apply — each given a card instead of an alert nobody reads.

• Statements per second by type — SELECT, INSERT, UPDATE, DELETE (stacked bar)
• Statement latency by hour, p95 and p99 (line)
• Slow queries and rows examined per row returned (combo)
• InnoDB buffer pool hit rate (gauge)
• Connections against max_connections by hour (area with goal)
• Row lock waits by table (row)
• Replication lag by replica (line)
• Top statement digests by total latency, with calls and rows examined vs. sent (table)

What data does the dashboard need?

• performance_schema.events_statements_summary_by_digest — calls, sum_timer_wait, quantile_95, sum_rows_examined, sum_rows_sent, sum_no_index_used, and sum_created_tmp_disk_tables per normalized statement.
• sys.statement_analysis and sys.statements_with_full_table_scans for the readable table cards, plus sys.schema_unused_indexes when you want the other half of the index conversation.
• performance_schema.global_status sampled on a schedule — Threads_connected, Innodb_buffer_pool_read_requests, Innodb_buffer_pool_reads, Innodb_row_lock_waits, Innodb_deadlocks — and global_variables for max_connections and innodb_buffer_pool_size.
• performance_schema.data_lock_waits and sys.innodb_lock_waits for contention by table, with deadlock counts rolled up from SHOW ENGINE INNODB STATUS.
• performance_schema.replication_connection_status and replication_applier_status_by_worker, plus a heartbeat table on the primary if you want true end-to-end lag.
• A snapshot table for all of the above, because the digest and status counters reset on restart and on FLUSH STATUS.

How do you build it?

1. Connect MySQL to Metabase with a dedicated user granted SELECT on performance_schema and sys, plus PROCESS and REPLICATION CLIENT. Point it at a replica if the primary is tight on headroom.
2. Schedule a job that snapshots the digest summaries and global_status every few minutes into your own table, and store the deltas — counters are cumulative, so the raw values cannot produce a trend.
3. Model the snapshot once: picoseconds to milliseconds, an examined-per-returned ratio, and a buffer pool hit rate computed from the delta. Every card reads the model, so no two cards disagree.
4. Build the digest table and the examined-per-returned trend first — they name the query to fix — then connections, locks, and replication, which tell you how much time you have.
5. Add filters for schema, host, and date range, and alert when connections pass a fraction of max_connections or a replica’s lag exceeds its budget.

Example card SQL

SELECT
d.schema_name,
LEFT(d.digest_text, 80)                                    AS digest,
d.count_star                                               AS calls,
ROUND(d.sum_timer_wait / 1e12, 1)                          AS total_latency_s,
ROUND(d.avg_timer_wait / 1e9,  2)                          AS avg_latency_ms,
ROUND(d.quantile_95    / 1e9,  2)                          AS p95_latency_ms,
d.sum_rows_examined                                        AS rows_examined,
d.sum_rows_sent                                            AS rows_sent,
ROUND(d.sum_rows_examined / NULLIF(d.sum_rows_sent, 0), 1) AS examined_per_sent,
d.sum_no_index_used                                        AS no_index_used,
d.sum_created_tmp_disk_tables                              AS tmp_disk_tables
FROM performance_schema.events_statements_summary_by_digest d
WHERE d.schema_name IS NOT NULL
AND d.last_seen >= NOW() - INTERVAL 1 DAY
ORDER BY d.sum_timer_wait DESC
LIMIT 20;

Related

Metrics

Integrations

Dashboards

FAQ