MySQL Monitoring: InnoDB, Slow Queries und Replikation
Überwachen Sie Threads, InnoDB Buffer Pool, Row Locks und Replikationsverzögerung jedes MySQL-Servers und verknüpfen Sie langsame Queries mit den auslösenden Requests.
Warum MySQL mit Obseria überwachen
Slow Queries mit Aufrufer
Einträge aus dem Slow Query Log und Datenbank-Spans an einem Ort zeigen, welcher Endpunkt und welches Deployment eine Regression verursacht haben.
InnoDB im Kontext
Buffer-Pool-Auslastung, Page Flushes und Row Lock Waits neben Platten- und CPU-Metriken des Hosts erklären, warum die Latenz steigt.
Verlässliche Replikas
Sekunden hinter der Quelle pro Replika, mit Alerts, bevor Lesezugriffe veraltete Daten sehen oder ein Failover länger dauert als geplant.
MySQL-Komponenten, die Obseria überwacht
- Serverstatus. Globale Statuszähler wie Threads, Operationen, Handler, Sorts und temporäre Tabellen.
- InnoDB Buffer Pool. Pages nach Zustand, Auslastung in Bytes, Read Requests im Vergleich zu Plattenzugriffen und Page Flushes.
- Locks. Table Locks sowie InnoDB Row Lock Waits und -Zeit, die Hauptquellen für Konflikte.
- Replikation. Sekunden hinter der Quelle und konfigurierte SQL-Verzögerung pro Replika.
- Performance Schema. I/O-Wartezahlen und -zeiten für Tabellen und Indizes aus performance_schema.
- Slow Query Log. Zeilen aus dem Slow Query Log über den filelog-Receiver, durchsuchbar neben den Metriken.
Die MySQL-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Verbindungen zur Datenbank
Zeigt, wie viele Nutzer und Anwendungen verbunden sind und ob Verbindungsversuche scheitern oder abgewiesen werden.
Effiziente Speichernutzung
Zeigt, wie gut die Datenbank häufig genutzte Daten im schnellen Speicher hält, statt sie von langsamen Festplatten zu lesen.
Arbeitslast und langsame Abfragen
Macht sichtbar, wie viel Arbeit die Datenbank leistet, wo Anfragen aufeinander warten und welche Abfragen zu lange dauern.
Stand der Replikation
Zeigt, ob Sicherungskopien Ihrer Daten mit der Hauptdatenbank Schritt halten, damit bei einem Wechsel nichts verloren geht.
Alle 10 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
mysql.threads | 1 | Verbundene, laufende, gecachte und erzeugte Threads; laufende Threads zeigen echte Parallelität. |
mysql.connection.errors | 1 | Verbindungsfehler nach Typ, einschließlich Erreichen von max_connections. |
mysql.buffer_pool.usage | By | Bytes im InnoDB Buffer Pool nach Zustand (data, dirty). |
mysql.buffer_pool.operations | 1 | Read Requests und Plattenzugriffe; ihr Verhältnis ist die Buffer Pool Hit Rate. |
mysql.buffer_pool.page_flushes | 1 | Aus dem Buffer Pool geschriebene Pages; Spitzen zeigen Schreibdruck. |
mysql.row_locks | 1 | InnoDB Row Lock Waits und Lock-Zeit, das zentrale Konfliktsignal. |
mysql.operations | 1 | InnoDB-fsync-, Lese- und Schreiboperationen für die I/O-Analyse. |
mysql.query.slow.count | 1 | Queries, die long_query_time überschritten haben. |
mysql.replica.time_behind_source | s | Sekunden, die eine Replika hinter ihrer Quelle liegt. |
mysql.tmp_resources | 1 | Erzeugte temporäre Tabellen und Dateien, bei großen Sorts oft auf der Platte. |
MySQL-Monitoring in wenigen Minuten einrichten
- Schritt 1
Monitoring-User anlegen
Legen Sie einen eigenen MySQL-User mit PROCESS, REPLICATION CLIENT und SELECT auf performance_schema an und hinterlegen Sie das Passwort als Umgebungsvariable.
- Schritt 2
mysql-Receiver konfigurieren
Ergänzen Sie den mysql-Receiver im OpenTelemetry Collector oder Obseria Agent und aktivieren Sie optionale Metriken wie Slow-Query-Zähler und Replikationsverzögerung.
- Schritt 3
Slow Logs und Traces erfassen
Aktivieren Sie das Slow Query Log, senden Sie es über den filelog-Receiver und instrumentieren Sie die aufrufenden Services mit 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]
Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- MySQL-Übersicht: Threads, Queries und Verbindungsfehler
- InnoDB Buffer Pool und I/O
- Row Locks und Lock-Zeit
- Alert: Replika mehr als 30 Sekunden hinter der Quelle
- Alert: Slow Queries über der Baseline
MySQL-Monitoring: Darauf kommt es an
Warum MySQL Monitoring wichtig ist
MySQL betreibt einen großen Teil des Webs: Shops, Content-Plattformen, SaaS-Backends. Die Standard-Storage-Engine InnoDB ist robust, reagiert aber empfindlich auf Speicherdimensionierung, Lock-Konflikte und ineffiziente Queries. Wird MySQL langsam, zeigt sich das als langsame Seiten und API-Timeouts in den Services darüber. MySQL Monitoring macht die Ursachen sichtbar: Parallelität, Effizienz des Buffer Pools, Locking, langsame Statements und Replikationsverzögerung.
Obseria erfasst MySQL-Metriken mit dem mysql-Receiver des OpenTelemetry Collectors, der globale Statuszähler, InnoDB-Statistiken und performance_schema-Tabellen liest. Slow Query Logs und Datenbank-Spans Ihrer Anwendungen vervollständigen das Bild.
Die MySQL-Metriken, auf die es ankommt
Threads und Verbindungen
mysql.threads unterscheidet verbundene und laufende Threads. Viele verbundene, aber wenige laufende Threads bedeuten meist inaktive Pool-Verbindungen. Viele laufende Threads bedeuten echte Parallelität; übersteigt ihre Zahl lange die CPU-Kerne, stauen sich Queries. mysql.connection.errors zeigt, wann Clients abgewiesen werden, etwa weil max_connections erreicht ist.
InnoDB Buffer Pool
Der Buffer Pool cacht Daten- und Index-Pages. Aus mysql.buffer_pool.operations ergibt das Verhältnis von Plattenzugriffen zu Read Requests die Buffer Pool Hit Rate. Gehen mit der Zeit mehr Lesezugriffe auf die Platte, ist das Working Set größer als innodb_buffer_pool_size. mysql.buffer_pool.usage und mysql.buffer_pool.page_flushes zeigen, wie viele Dirty Pages entstehen und wie stark InnoDB schreiben muss.
Locks
mysql.row_locks meldet Row Lock Waits und die aufsummierte Lock-Zeit. Steigende Waits stammen meist aus langen Transaktionen, Hot Rows wie Zählern oder fehlenden Indizes, durch die Updates mehr Zeilen sperren als nötig.
Queries und Replikation
mysql.query.slow.count zählt Statements über long_query_time. mysql.replica.time_behind_source zeigt, wie weit jede Replika zurückliegt; Lesezugriffe auf verzögerte Replikas liefern veraltete Daten.
Typische Probleme und wie Sie sie erkennen
- Zu viele Verbindungen: Verbindungsfehler steigen, verbundene Threads stehen am Limit. Prüfen Sie Pool-Größen pro Service und Timeouts für inaktive Verbindungen.
- Zu kleiner Buffer Pool: Plattenzugriffe steigen im Verhältnis zu Read Requests, begleitet von höherer Plattenlatenz auf dem Host.
- Lock-Konflikte: Row Lock Waits steigen, während der Durchsatz sinkt. Prüfen Sie lang laufende Transaktionen und die Statements in den Datenbank-Spans dieses Zeitraums.
- Temporäre Tabellen auf der Platte:
mysql.tmp_resourceswächst bei großen GROUP-BY- oder ORDER-BY-Queries; bessere Indizes oder umgeschriebene Queries helfen. - Replica Lag: Große Schreib-Batches oder Single-Threaded Apply. Erwägen Sie parallele Replikation und korrelieren Sie Lag mit dem Schreibdurchsatz der Quelle.
Best Practices für MySQL Monitoring
- Nutzen Sie einen eigenen Monitoring-User mit minimalen Rechten statt root.
- Aktivieren Sie das Slow Query Log mit realistischem
long_query_timeund senden Sie es zentral, statt es auf dem Server zu lesen. - Lassen Sie performance_schema aktiviert; es liefert I/O-Wartestatistiken für Tabellen und Indizes bei moderatem Overhead.
- Alarmieren Sie auf Symptome wie Verbindungsfehler, Replikationsverzögerung und Query-Latenz der Datenbank-Spans, nicht auf jeden Zähler.
- Überwachen Sie Managed-Instanzen wie Amazon RDS oder Aurora MySQL mit demselben Receiver plus den Metriken des Anbieters, damit selbst betriebene und gemanagte Datenbanken gleich aussehen.
So unterstützt Obseria Ihr MySQL Monitoring
Obseria speichert MySQL-Metriken, Slow Query Logs und Datenbank-Spans gemeinsam in Obseria Lake. TopoGraph zeigt, welche Services mit welchem MySQL-Server sprechen, sodass ein Alert auf Replica Lag oder Lock Waits sofort die betroffenen Anwendungen nennt. Obseria Intelligence korreliert einen Latenzanstieg mit Deployments, einzelnen Statements und Host-Metriken und legt die wahrscheinliche Ursache mit einer Beweiskette dar. Für Amazon RDS, Aurora und andere Managed-MySQL-Angebote ergänzen die agentenlosen Cloud-Integrationen die Metriken des Anbieters ohne Agent auf dem Datenbank-Host.
Dashboards, Alerts und SLOs sind enthalten. Mit OQL zählen Sie zum Beispiel Slow-Query-Einträge pro Statement-Fingerprint und vergleichen sie mit der p95-Dauer der passenden Datenbank-Spans vor und nach einem Release. Die Obseria Pipeline maskiert sensible Werte in geloggten Queries, bevor sie gespeichert werden.
Ein bewährter Einstieg: Aktivieren Sie zuerst den Receiver auf Quelle und Replikas, richten Sie Alerts für Verbindungsfehler und Replikationsverzögerung ein und instrumentieren Sie danach die Services mit dem meisten Datenbank-Traffic. So entsteht innerhalb kurzer Zeit eine Sicht, die Datenbankzustand und Anwendungsverhalten zusammenführt.
Verwandte Integrationen
Passende Funktionen
Datenbank-Monitoring
Finden Sie die langsame Query hinter dem langsamen Endpunkt. Obseria verknüpft Datenbankmetriken, Query-Performance und Logs mit den Traces und Services, die sie aufrufen.
Mehr erfahrenDistributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenAnomalie-Erkennung
Obseria Intelligence lernt den normalen Rhythmus jedes Service, meldet echte Abweichungen statt Schwellenwert-Rauschen und fasst zusammenhängende Anomalien zu einem Problem mit wahrscheinlicher Ursache zusammen.
Mehr erfahrenMehr erfahren
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Was ist eine Root-Cause-Analyse (RCA)?
Was ist eine Root-Cause-Analyse? Der RCA-Prozess für Software-Incidents, 5 Whys, Fishbone und Fehlerbaum, ein Praxisbeispiel und RCA mit KI.
Häufige Fragen zum MySQL-Monitoring
Der OpenTelemetry-mysql-Receiver funktioniert mit MySQL 8 und mit Managed Services wie Amazon RDS for MySQL und Aurora MySQL. Einige optionale Metriken setzen ein aktiviertes performance_schema voraus.
PROCESS und REPLICATION CLIENT für Status- und Replikationsdaten sowie SELECT auf performance_schema. Zugriff auf Anwendungsschemas ist nicht nötig.
Obseria kombiniert das Slow Query Log, die Metrik mysql.query.slow.count und Datenbank-Spans Ihrer Services. Sie sehen das Statement, seine Häufigkeit und den Endpunkt, der es abgesetzt hat.
Ja. Aktivieren Sie mysql.replica.time_behind_source im Receiver und alarmieren Sie, wenn eine Replika stärker verzögert ist, als Ihre Lesekonsistenz erlaubt.
Das entscheiden Sie. Die Obseria Pipeline kann Literale und andere sensible Werte beim Ingest maskieren oder verwerfen, bevor etwas gespeichert wird.
Starten Sie heute mit dem MySQL-Monitoring
Binden Sie MySQL in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.