MySQL-Monitoring: die Metriken, die wirklich etwas aussagen

1. Warum die falschen Metriken in die Irre führen

Gutes MySQL-Monitoring beginnt mit der Erkenntnis, dass klassische Server-Metriken wie CPU-Auslastung oder freier Arbeitsspeicher für sich genommen kaum etwas über den tatsächlichen Gesundheitszustand einer Datenbank aussagen. Eine MySQL-Instanz kann bei niedriger CPU-Last bereits massiv unter Lock-Contention leiden, während eine Instanz mit hoher CPU-Auslastung schlicht viele legitime Anfragen effizient verarbeitet. Wer nur auf Systemebene misst, übersieht genau die Probleme, die Anwendungen tatsächlich betreffen.

Sinnvolles MySQL-Monitoring braucht deshalb Metriken, die aus der Datenbank selbst stammen: wie effizient der Buffer Pool Anfragen bedient, wie nah die Verbindungsanzahl am konfigurierten Limit liegt, wie weit Replikate hinter dem Primary zurückliegen und wie oft Transaktionen aufeinander warten müssen. Diese Metriken zusammen ergeben ein Bild, das früh genug warnt, um einzugreifen, bevor Anwender einen Vorfall bemerken.

2. Buffer Pool Hit Ratio richtig einschätzen

Der InnoDB Buffer Pool hält häufig genutzte Daten und Indizes im Arbeitsspeicher, um teure Festplattenzugriffe zu vermeiden. Die Buffer Pool Hit Ratio beschreibt, welcher Anteil der Leseanfragen direkt aus dem Speicher bedient werden konnte, statt eine Seite von der Festplatte nachzuladen. Ein gesunder Wert liegt bei über 99 Prozent, alles darunter deutet darauf hin, dass der Buffer Pool zu klein für die aktive Datenmenge dimensioniert ist.

Wichtig für korrektes MySQL-Monitoring ist, die Hit Ratio nicht isoliert, sondern zusammen mit der absoluten Anzahl an Reads pro Sekunde zu betrachten: eine Hit Ratio von 98 Prozent bei zehn Leseanfragen pro Sekunde ist unkritisch, dieselbe Ratio bei zehntausend Leseanfragen pro Sekunde bedeutet hunderte Festplattenzugriffe jede Sekunde und kann bereits spürbare Latenz verursachen. Die Größe von innodb_buffer_pool_size sollte sich an der Größe des aktiven Datenbestands orientieren, nicht an einer pauschalen Prozentangabe des verfügbaren Arbeitsspeichers.

-- Buffer Pool Hit Ratio berechnen
SELECT
  (1 - (SELECT VARIABLE_VALUE FROM performance_schema.global_status
        WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads')
      / (SELECT VARIABLE_VALUE FROM performance_schema.global_status
        WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests')
  ) * 100 AS buffer_pool_hit_ratio_percent;

-- Aktuelle Buffer-Pool-Größe und Auslastung prüfen
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW STATUS LIKE 'Innodb_buffer_pool_pages_free';
SHOW STATUS LIKE 'Innodb_buffer_pool_pages_total';

3. Connections und Threads: Sättigung erkennen

Ein plötzlicher Anstieg an offenen Verbindungen ist oft das früheste sichtbare Anzeichen eines Problems, sei es ein langsamer werdender Storage, eine hängende Anwendung, die Verbindungen nicht schließt, oder ein Traffic-Spike. Die Statusvariable Threads_connected im Verhältnis zu max_connections zeigt, wie nah ein System an seinem konfigurierten Limit liegt. Wird das Limit erreicht, lehnt MySQL neue Verbindungen komplett ab, was für Anwendungen meist deutlich schlimmer ist als erhöhte Latenz.

Für MySQL-Monitoring ist zusätzlich Threads_running relevant: diese Zahl zeigt, wie viele Verbindungen gerade aktiv eine Abfrage ausführen, im Gegensatz zu Threads_connected, das auch inaktive, nur offene Verbindungen mitzählt. Ein stark wachsendes Threads_running bei gleichbleibendem Threads_connected deutet auf eine sich aufbauende Query-Warteschlange hin, oft ein frühes Warnsignal für eine kommende Ueberlastung, lange bevor max_connections tatsächlich erreicht wird.

-- Verbindungsauslastung im Verhältnis zum konfigurierten Limit
SELECT
  (SELECT VARIABLE_VALUE FROM performance_schema.global_status
   WHERE VARIABLE_NAME = 'Threads_connected') AS connected,
  (SELECT VARIABLE_VALUE FROM performance_schema.global_variables
   WHERE VARIABLE_NAME = 'max_connections') AS max_conn,
  (SELECT VARIABLE_VALUE FROM performance_schema.global_status
   WHERE VARIABLE_NAME = 'Threads_running') AS running;

-- Aktuelle Prozesse und deren Zustand einsehen
SHOW FULL PROCESSLIST;

4. Replikationslag messen und interpretieren

Replikationslag beschreibt, wie weit ein Replikat hinter den Transaktionen des Primary zurückliegt, gemessen meist in Sekunden. Für Anwendungen mit Read/Write-Split ist das eine kritische Metrik im MySQL-Monitoring: ein Nutzer, der unmittelbar nach einem Schreibzugriff eine veraltete Leseantwort von einem nachhinkenden Replikat erhält, sieht scheinbar inkonsistente Daten, obwohl die Datenbank technisch korrekt arbeitet.

Die klassische Metrik Seconds_Behind_Master aus SHOW SLAVE STATUS ist ein guter erster Indikator, kann aber bei Netzwerkproblemen oder wenn der IO-Thread selbst hängt, fehlerhaft null anzeigen, obwohl der Replikat-Thread tatsächlich weit zurückliegt. Mit aktiviertem GTID und performance_schema-Replikationstabellen lässt sich der tatsächliche Lag präziser über den Zeitstempel der zuletzt angewendeten Transaktion ermitteln, was für produktives MySQL-Monitoring deutlich zuverlässiger ist.

-- Klassischer Replikationslag (auf dem Replikat ausführen)
SHOW SLAVE STATUS\G
-- Relevante Felder: Seconds_Behind_Master, Slave_IO_Running, Slave_SQL_Running

-- Präziserer Lag über Performance Schema (GTID-basiert)
SELECT
  CHANNEL_NAME,
  TIMESTAMPDIFF(SECOND, LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP, NOW()) AS lag_seconds
FROM performance_schema.replication_applier_status_by_worker;

5. Lock Waits und Deadlocks überwachen

Lock Waits entstehen, wenn eine Transaktion auf eine Zeilensperre wartet, die von einer anderen, noch laufenden Transaktion gehalten wird. Vereinzelte, kurze Lock Waits sind in jedem transaktionalen System normal, eine steigende Anzahl gleichzeitiger Lock Waits oder eine wachsende durchschnittliche Wartezeit deutet dagegen auf problematische Zugriffsmuster hin, etwa lange laufende Transaktionen, die Zeilen unnötig lange halten.

Für detailliertes MySQL-Monitoring von Lock-Problemen liefert die Tabelle performance_schema.data_lock_waits in Kombination mit data_locks genau, welche Transaktion auf welche andere wartet, inklusive der jeweiligen Query. Deadlocks, bei denen zwei Transaktionen sich gegenseitig blockieren, löst InnoDB automatisch auf, indem eine der beiden Transaktionen zurückgerollt wird. Ein häufiges Auftreten von Deadlocks in SHOW ENGINE INNODB STATUS ist trotzdem ein klares Signal für überarbeitungsbedürftige Transaktionslogik in der Anwendung.

-- Aktuell blockierte Transaktionen und ihre Blocker identifizieren
SELECT
  waiting_pid, waiting_query, blocking_pid, blocking_query
FROM sys.innodb_lock_waits;

-- Anzahl der Deadlocks seit dem letzten Server-Start prüfen
SHOW ENGINE INNODB STATUS\G
-- Abschnitt "LATEST DETECTED DEADLOCK" beachten

6. Performance Schema: Grundlagen und Tabellen

Das Performance Schema ist die zentrale Instrumentierung von MySQL für detailliertes MySQL-Monitoring auf Ebene einzelner Statements, Wartezustände und Ressourcen. Es sammelt Daten mit minimalem Overhead direkt im Server und stellt sie über Standard-SQL-Abfragen bereit, ohne dass externe Agenten auf den Datenbankserver installiert werden müssen. Wichtige Tabellen sind events_statements_summary_by_digest für aggregierte Query-Statistiken und table_io_waits_summary_by_table für I/O-Verteilung pro Tabelle.

Anders als der klassische Slow Query Log erfasst das Performance Schema auch schnelle, aber sehr häufig ausgeführte Queries, die in Summe erhebliche Last erzeugen, ohne dass eine einzelne Ausführung als langsam auffällt. Für produktives MySQL-Monitoring ist die Kombination aus Performance Schema für aggregierte Trends und Slow Query Log für einzelne problematische Statements deutlich aussagekräftiger als nur eine der beiden Quellen allein.

7. Slow Query Log und Query-Analyse

Der Slow Query Log protokolliert jede Abfrage, deren Ausführungszeit einen konfigurierten Schwellenwert überschreitet, standardmäßig zwei Sekunden. Für aussagekräftiges MySQL-Monitoring sollte dieser Schwellenwert deutlich niedriger gesetzt werden, oft auf 100 bis 500 Millisekunden, da moderne Anwendungen bereits bei deutlich kürzeren Antwortzeiten spürbare Latenz für Nutzer erzeugen. Die Option log_queries_not_using_indexes ergänzt den Slow Query Log um Abfragen, die ohne Index einen vollständigen Tabellenscan ausführen.

Werkzeuge wie pt-query-digest von Percona Toolkit aggregieren den Slow Query Log nach Query-Mustern und zeigen, welche Abfragen in Summe die meiste Zeit verbrauchen, statt nur einzelne Ausreisser zu listen. Diese aggregierte Sicht ist für die Priorisierung von Optimierungsarbeit meist wertvoller als die chronologische Rohliste des Logs.

# my.cnf: Slow Query Log für aussagekräftiges Monitoring konfigurieren
[mysqld]
slow_query_log               = ON
slow_query_log_file           = /var/log/mysql/slow.log
long_query_time                = 0.2
log_queries_not_using_indexes  = ON
log_throttle_queries_not_using_indexes = 60

# Analyse mit Percona Toolkit
# pt-query-digest /var/log/mysql/slow.log --limit=20

8. Alerting-Schwellenwerte sinnvoll setzen

Alerting-Schwellenwerte ohne Bezug zur tatsächlichen Systemcharakteristik erzeugen entweder verpasste Vorfälle oder Alert-Fatigue durch zu viele falsche Alarme. Gutes MySQL-Monitoring setzt Schwellenwerte relativ zum normalen Betriebsverhalten des jeweiligen Systems und unterscheidet zwischen Warnung und kritischem Alarm, statt einen einzigen starren Grenzwert für alles zu verwenden.

Die folgende Tabelle zeigt Ausgangswerte, die sich in produktiven Umgebungen bewährt haben und als Startpunkt für eigene, an die jeweilige Workload angepasste Schwellenwerte dienen können.

9. Dashboards: von Rohdaten zu Handlungsempfehlungen

Ein gutes MySQL-Monitoring-Dashboard zeigt nicht nur Rohwerte, sondern ordnet sie in einen Kontext ein, der eine Entscheidung ermöglicht: reicht der Buffer Pool aktuell aus, nähert sich die Verbindungsanzahl dem Limit, wie hat sich der Replikationslag in den letzten 24 Stunden entwickelt. Zeitreihen sind dabei fast immer aussagekräftiger als Momentaufnahmen, weil sie Trends sichtbar machen, bevor ein Schwellenwert überschritten wird.

In der Praxis hat sich eine Kombination aus dem MySQL-Exporter für Prometheus und vorgefertigten Grafana-Dashboards bewährt, die Buffer Pool, Connections, Replikationslag und Lock-Metriken auf einer gemeinsamen Zeitachse darstellen. Wichtig ist, Dashboards regelmäßig gegen tatsächliche Vorfälle zu validieren: wenn ein Vorfall im Nachhinein nicht im Dashboard erkennbar war, fehlt eine Metrik, die ergänzt werden muss.

10. Zusammenfassung

Wirksames MySQL-Monitoring stützt sich nicht auf CPU-Auslastung oder freien Arbeitsspeicher allein, sondern auf Metriken aus der Datenbank selbst: Buffer Pool Hit Ratio für Speicherdimensionierung, Threads_connected und Threads_running für Verbindungssättigung, Replikationslag für Datenkonsistenz bei Read/Write-Split und Lock Waits für problematische Transaktionsmuster.

Performance Schema liefert die Datenbasis für aggregierte Trends, der Slow Query Log ergänzt einzelne problematische Statements. Erst mit realistischen, an die eigene Workload angepassten Alerting-Schwellenwerten und Dashboards, die Zeitreihen statt Momentaufnahmen zeigen, wird aus einer Sammlung von Metriken tatsächlich wirksames MySQL-Monitoring.

11. FAQ: MySQL-Monitoring