Seminar TiDB Monitoring, Diagnose und Troubleshooting

Komplexe Störungen lassen sich nur mit einer klaren Verbindung aus Zeitachse, Metriken, Logs, SQL-Daten und Gegenproben sicher eingrenzen. Das Seminar trainiert diesen Diagnosepfad an realistischen Ausfall- und Performancefällen.

Drei Tage sind erforderlich, um Monitoring-Baselines aufzubauen, SQL-Diagnose zu beherrschen und mehrere Störungsklassen mit vollständiger Ursachenanalyse und Betriebsdokumentation praktisch zu bearbeiten.

Inhaltsverzeichnis

1. Lernziele und fachliche Einordnung
2. Zielgruppe und Voraussetzungen
3. Kapitel 1: Monitoring-Stack und Baselines
4. Kapitel 2: SQL-Beobachtung und Ursachenanalyse
5. Kapitel 3: Systematische Störungsdiagnose
6. Kapitel 4: Typische Fehlerbilder im Labor
7. Kapitel 5: Incident-Runbooks und Betriebsübergabe
8. Praxisübungen und Laborszenarien
9. Didaktik und Arbeitsweise

Lernziele

• Relevante TiDB-Metriken und Baselines definieren.
• Top SQL, Slow Query und EXPLAIN ANALYZE zielgerichtet einsetzen.
• Störungen mit Hypothesen und Gegenproben eingrenzen.
• OOM-, Disk-, Lock-, Hotspot- und Ausfallszenarien diagnostizieren.
• Incident-Runbooks und Verbesserungsmaßnahmen standardisieren.

Zielgruppe und Voraussetzungen

Zielgruppe: Datenbankadministration, SRE, Plattformbetrieb, DevOps, Support und technische Betriebsleitung.

Voraussetzungen: TiDB-Architekturgrundlagen, Linux, SQL sowie Erfahrung mit Monitoring, Logs und Incident-Bearbeitung.

Kapitel 1: Monitoring-Stack und Baselines

Inhaltsverzeichnis dieses Kapitels

1. Prometheus, Grafana und Alerting
2. Overview- und Komponenten-Dashboards
3. Verfügbarkeit, Latenz, Durchsatz und Sättigung
4. Normalbereiche, Warn- und Kritisch-Schwellen

Schwerpunkt: Prometheus, Grafana und Alerting, Overview- und Komponenten-Dashboards, Verfügbarkeit, Latenz, Durchsatz und Sättigung, Normalbereiche, Warn- und Kritisch-Schwellen.

Schritt-für-Schritt-Anleitung

1. Schritt 1: Zielbild und Randbedingungen erfassen

   Für den Themenblock werden Einsatzfall, gewünschte Servicequalität, Daten- und Sicherheitsanforderungen sowie die Abhängigkeiten zu Prometheus, Grafana und Alerting und Overview- und Komponenten-Dashboards dokumentiert. Messbare Prüfkriterien verhindern, dass Konfigurationen nur nach Einzelbeobachtungen bewertet werden.

2. Schritt 2: Komponenten und Datenflüsse modellieren

   Rollen, Konfigurationsobjekte, Datenwege, Zustandsübergänge und Fehlergrenzen werden anhand von Prometheus, Grafana und Alerting, Overview- und Komponenten-Dashboards, Verfügbarkeit, Latenz, Durchsatz und Sättigung, Normalbereiche, Warn- und Kritisch-Schwellen in einem technischen Ablaufmodell festgehalten. Verantwortlichkeiten und Voraussetzungen werden jedem Schritt eindeutig zugeordnet.

3. Schritt 3: Konfiguration oder Prozessfolge umsetzen

   Das Laborszenario wird vom definierten Ausgangszustand bis zum funktionsfähigen Ergebnis umgesetzt. SQL, Befehle, Konfigurationswerte oder Manifeste werden versioniert, kommentiert und mit den erwarteten Zwischenständen abgeglichen.

4. Schritt 4: Positiv-, Negativ- und Fehlerfälle prüfen

   Funktion, Konsistenz, Berechtigungen, Performance und Fehlermeldungen werden mit Normalfällen, Grenzwerten und gezielt ausgelösten Störungen getestet. Die Prüfung bezieht insbesondere Verfügbarkeit, Latenz, Durchsatz und Sättigung und Normalbereiche, Warn- und Kritisch-Schwellen ein.

5. Schritt 5: Betriebsfähigkeit und Wiederholbarkeit herstellen

   Erforderliche Metriken, Logs, Alarmkriterien, Rückfallpunkte und Wartungsschritte werden ergänzt. Abweichungen zwischen Soll und Ist werden als konkrete Korrekturmaßnahmen dokumentiert.

6. Schritt 6: Arbeitsergebnis standardisieren

   Als verbindliches Arbeitsergebnis entsteht eine dokumentierte Betriebsbaseline mit priorisierten Alarmen. Das Ergebnis wird mit Abnahmekriterien, Zuständigkeiten und einem Termin für die nächste Überprüfung versehen.

Kapitel 2: SQL-Beobachtung und Ursachenanalyse

Inhaltsverzeichnis dieses Kapitels

1. Top SQL und Statement Summary
2. Slow Query Log und SQL-Digest
3. EXPLAIN und EXPLAIN ANALYZE
4. Planabweichungen, Wartezeiten und Ausführungsphasen

Schwerpunkt: Top SQL und Statement Summary, Slow Query Log und SQL-Digest, EXPLAIN und EXPLAIN ANALYZE, Planabweichungen, Wartezeiten und Ausführungsphasen.

Schritt-für-Schritt-Anleitung

1. Schritt 1: Zielbild und Randbedingungen erfassen

   Für den Themenblock werden Einsatzfall, gewünschte Servicequalität, Daten- und Sicherheitsanforderungen sowie die Abhängigkeiten zu Top SQL und Statement Summary und Slow Query Log und SQL-Digest dokumentiert. Messbare Prüfkriterien verhindern, dass Konfigurationen nur nach Einzelbeobachtungen bewertet werden.

2. Schritt 2: Komponenten und Datenflüsse modellieren

   Rollen, Konfigurationsobjekte, Datenwege, Zustandsübergänge und Fehlergrenzen werden anhand von Top SQL und Statement Summary, Slow Query Log und SQL-Digest, EXPLAIN und EXPLAIN ANALYZE, Planabweichungen, Wartezeiten und Ausführungsphasen in einem technischen Ablaufmodell festgehalten. Verantwortlichkeiten und Voraussetzungen werden jedem Schritt eindeutig zugeordnet.

3. Schritt 3: Konfiguration oder Prozessfolge umsetzen

   Das Laborszenario wird vom definierten Ausgangszustand bis zum funktionsfähigen Ergebnis umgesetzt. SQL, Befehle, Konfigurationswerte oder Manifeste werden versioniert, kommentiert und mit den erwarteten Zwischenständen abgeglichen.

4. Schritt 4: Positiv-, Negativ- und Fehlerfälle prüfen

   Funktion, Konsistenz, Berechtigungen, Performance und Fehlermeldungen werden mit Normalfällen, Grenzwerten und gezielt ausgelösten Störungen getestet. Die Prüfung bezieht insbesondere EXPLAIN und EXPLAIN ANALYZE und Planabweichungen, Wartezeiten und Ausführungsphasen ein.

5. Schritt 5: Betriebsfähigkeit und Wiederholbarkeit herstellen

   Erforderliche Metriken, Logs, Alarmkriterien, Rückfallpunkte und Wartungsschritte werden ergänzt. Abweichungen zwischen Soll und Ist werden als konkrete Korrekturmaßnahmen dokumentiert.

6. Schritt 6: Arbeitsergebnis standardisieren

   Als verbindliches Arbeitsergebnis entsteht einen wiederholbaren Analysepfad für langsame und ressourcenintensive SQL-Anweisungen. Das Ergebnis wird mit Abnahmekriterien, Zuständigkeiten und einem Termin für die nächste Überprüfung versehen.

Kapitel 3: Systematische Störungsdiagnose

Inhaltsverzeichnis dieses Kapitels

1. Symptom, Beginn und betroffene Pfade
2. Metriken, Logs und Clusterinformationen
3. Hypothesen, Eingrenzung und Gegenprobe
4. Sofortmaßnahme, Ursachenbehebung und Nachkontrolle

Schwerpunkt: Symptom, Beginn und betroffene Pfade, Metriken, Logs und Clusterinformationen, Hypothesen, Eingrenzung und Gegenprobe, Sofortmaßnahme, Ursachenbehebung und Nachkontrolle.

Schritt-für-Schritt-Anleitung

1. Schritt 1: Zielbild und Randbedingungen erfassen

   Für den Themenblock werden Einsatzfall, gewünschte Servicequalität, Daten- und Sicherheitsanforderungen sowie die Abhängigkeiten zu Symptom, Beginn und betroffene Pfade und Metriken, Logs und Clusterinformationen dokumentiert. Messbare Prüfkriterien verhindern, dass Konfigurationen nur nach Einzelbeobachtungen bewertet werden.

2. Schritt 2: Komponenten und Datenflüsse modellieren

   Rollen, Konfigurationsobjekte, Datenwege, Zustandsübergänge und Fehlergrenzen werden anhand von Symptom, Beginn und betroffene Pfade, Metriken, Logs und Clusterinformationen, Hypothesen, Eingrenzung und Gegenprobe, Sofortmaßnahme, Ursachenbehebung und Nachkontrolle in einem technischen Ablaufmodell festgehalten. Verantwortlichkeiten und Voraussetzungen werden jedem Schritt eindeutig zugeordnet.

3. Schritt 3: Konfiguration oder Prozessfolge umsetzen

   Das Laborszenario wird vom definierten Ausgangszustand bis zum funktionsfähigen Ergebnis umgesetzt. SQL, Befehle, Konfigurationswerte oder Manifeste werden versioniert, kommentiert und mit den erwarteten Zwischenständen abgeglichen.

4. Schritt 4: Positiv-, Negativ- und Fehlerfälle prüfen

   Funktion, Konsistenz, Berechtigungen, Performance und Fehlermeldungen werden mit Normalfällen, Grenzwerten und gezielt ausgelösten Störungen getestet. Die Prüfung bezieht insbesondere Hypothesen, Eingrenzung und Gegenprobe und Sofortmaßnahme, Ursachenbehebung und Nachkontrolle ein.

5. Schritt 5: Betriebsfähigkeit und Wiederholbarkeit herstellen

   Erforderliche Metriken, Logs, Alarmkriterien, Rückfallpunkte und Wartungsschritte werden ergänzt. Abweichungen zwischen Soll und Ist werden als konkrete Korrekturmaßnahmen dokumentiert.

6. Schritt 6: Arbeitsergebnis standardisieren

   Als verbindliches Arbeitsergebnis entsteht ein einheitliches Diagnoseverfahren mit Beweissicherung und Prüfpunkten. Das Ergebnis wird mit Abnahmekriterien, Zuständigkeiten und einem Termin für die nächste Überprüfung versehen.

Kapitel 4: Typische Fehlerbilder im Labor

Inhaltsverzeichnis dieses Kapitels

1. Speicherengpass und OOM-Risiko
2. Disk-Latenz und volle Datenträger
3. Hot Regions, Sperren und Konflikte
4. Komponentenausfall und eingeschränkte Erreichbarkeit

Schwerpunkt: Speicherengpass und OOM-Risiko, Disk-Latenz und volle Datenträger, Hot Regions, Sperren und Konflikte, Komponentenausfall und eingeschränkte Erreichbarkeit.

Schritt-für-Schritt-Anleitung

1. Schritt 1: Zielbild und Randbedingungen erfassen

   Für den Themenblock werden Einsatzfall, gewünschte Servicequalität, Daten- und Sicherheitsanforderungen sowie die Abhängigkeiten zu Speicherengpass und OOM-Risiko und Disk-Latenz und volle Datenträger dokumentiert. Messbare Prüfkriterien verhindern, dass Konfigurationen nur nach Einzelbeobachtungen bewertet werden.

2. Schritt 2: Komponenten und Datenflüsse modellieren

   Rollen, Konfigurationsobjekte, Datenwege, Zustandsübergänge und Fehlergrenzen werden anhand von Speicherengpass und OOM-Risiko, Disk-Latenz und volle Datenträger, Hot Regions, Sperren und Konflikte, Komponentenausfall und eingeschränkte Erreichbarkeit in einem technischen Ablaufmodell festgehalten. Verantwortlichkeiten und Voraussetzungen werden jedem Schritt eindeutig zugeordnet.

3. Schritt 3: Konfiguration oder Prozessfolge umsetzen

   Das Laborszenario wird vom definierten Ausgangszustand bis zum funktionsfähigen Ergebnis umgesetzt. SQL, Befehle, Konfigurationswerte oder Manifeste werden versioniert, kommentiert und mit den erwarteten Zwischenständen abgeglichen.

4. Schritt 4: Positiv-, Negativ- und Fehlerfälle prüfen

   Funktion, Konsistenz, Berechtigungen, Performance und Fehlermeldungen werden mit Normalfällen, Grenzwerten und gezielt ausgelösten Störungen getestet. Die Prüfung bezieht insbesondere Hot Regions, Sperren und Konflikte und Komponentenausfall und eingeschränkte Erreichbarkeit ein.

5. Schritt 5: Betriebsfähigkeit und Wiederholbarkeit herstellen

   Erforderliche Metriken, Logs, Alarmkriterien, Rückfallpunkte und Wartungsschritte werden ergänzt. Abweichungen zwischen Soll und Ist werden als konkrete Korrekturmaßnahmen dokumentiert.

6. Schritt 6: Arbeitsergebnis standardisieren

   Als verbindliches Arbeitsergebnis entsteht ein Fehlerkatalog mit Symptomen, Diagnosemerkmalen und Abhilfeschritten. Das Ergebnis wird mit Abnahmekriterien, Zuständigkeiten und einem Termin für die nächste Überprüfung versehen.

Kapitel 5: Incident-Runbooks und Betriebsübergabe

Inhaltsverzeichnis dieses Kapitels

1. Alarmannahme und Priorisierung
2. Kommunikation und Eskalation
3. Wiederherstellung und Datenprüfung
4. Post-Incident-Analyse und Maßnahmenverfolgung

Schwerpunkt: Alarmannahme und Priorisierung, Kommunikation und Eskalation, Wiederherstellung und Datenprüfung, Post-Incident-Analyse und Maßnahmenverfolgung.

Schritt-für-Schritt-Anleitung

1. Schritt 1: Zielbild und Randbedingungen erfassen

   Für den Themenblock werden Einsatzfall, gewünschte Servicequalität, Daten- und Sicherheitsanforderungen sowie die Abhängigkeiten zu Alarmannahme und Priorisierung und Kommunikation und Eskalation dokumentiert. Messbare Prüfkriterien verhindern, dass Konfigurationen nur nach Einzelbeobachtungen bewertet werden.

2. Schritt 2: Komponenten und Datenflüsse modellieren

   Rollen, Konfigurationsobjekte, Datenwege, Zustandsübergänge und Fehlergrenzen werden anhand von Alarmannahme und Priorisierung, Kommunikation und Eskalation, Wiederherstellung und Datenprüfung, Post-Incident-Analyse und Maßnahmenverfolgung in einem technischen Ablaufmodell festgehalten. Verantwortlichkeiten und Voraussetzungen werden jedem Schritt eindeutig zugeordnet.

3. Schritt 3: Konfiguration oder Prozessfolge umsetzen

   Das Laborszenario wird vom definierten Ausgangszustand bis zum funktionsfähigen Ergebnis umgesetzt. SQL, Befehle, Konfigurationswerte oder Manifeste werden versioniert, kommentiert und mit den erwarteten Zwischenständen abgeglichen.

4. Schritt 4: Positiv-, Negativ- und Fehlerfälle prüfen

   Funktion, Konsistenz, Berechtigungen, Performance und Fehlermeldungen werden mit Normalfällen, Grenzwerten und gezielt ausgelösten Störungen getestet. Die Prüfung bezieht insbesondere Wiederherstellung und Datenprüfung und Post-Incident-Analyse und Maßnahmenverfolgung ein.

5. Schritt 5: Betriebsfähigkeit und Wiederholbarkeit herstellen

   Erforderliche Metriken, Logs, Alarmkriterien, Rückfallpunkte und Wartungsschritte werden ergänzt. Abweichungen zwischen Soll und Ist werden als konkrete Korrekturmaßnahmen dokumentiert.

6. Schritt 6: Arbeitsergebnis standardisieren

   Als verbindliches Arbeitsergebnis entsteht ein praxistaugliches Incident-Runbook für den TiDB-Regelbetrieb. Das Ergebnis wird mit Abnahmekriterien, Zuständigkeiten und einem Termin für die nächste Überprüfung versehen.

Praxisübungen und Laborszenarien

• Eine Baseline und Alarmpriorisierung für einen Laborcluster erstellen.
• Eine langsame Abfrage vom Symptom bis zum Operatorengpass analysieren.
• Ein OOM- oder Disk-Latenz-Szenario mit Metriken und Logs eingrenzen.
• Hot Region und Lock-Konflikt diagnostizieren und beheben.
• Ein Incident-Runbook mit Zeitachse, Beweisen und Nachkontrolle erstellen.

Didaktik und Arbeitsweise

Kurze Fachimpulse werden unmittelbar durch Demonstrationen, strukturierte Konfigurations- oder SQL-Schritte, kontrollierte Fehlerfälle und dokumentierte Prüfpunkte vertieft. Jede Übung beginnt mit einem definierten Ausgangszustand und endet mit messbaren Abnahmekriterien, damit die erarbeiteten Vorgehensweisen als wiederholbare Standards nutzbar bleiben.