Metriken für ein effektives Datenbank-Monitoring
Effektives Datenbank-Monitoring erfordert das Überwachen von Metriken, um Engpässe oder potenzielle Ausfälle zu identifizieren. Es hilft Unternehmen auch, schnell auf Leistungsprobleme zu reagieren, bevor sie sich auf Anwendungen oder Kunden auswirken.
In diesem Blogpost werden wir einen Überblick darüber geben, welche der schier endlos vielen Metriken einer Datenbank überwacht werden sollten, um so schnell zu den Problem-Hotspots zu gelangen. Beispiele veranschaulichen dabei mögliche Auswirkungen. Obwohl dieser Blogpost auf Postgres Basis geschrieben wurde, können die Erkenntnisse auf jede Datenbank übertragen werden.
Proaktive und reaktive Überwachung
Wie bei jedem Monitoring lassen sich Datenbanken proaktiv und reaktiv überwachen. Bei der proaktiven Überwachung sollen Probleme erkannt werden, bevor sie zu groß werden. Dabei werden bestimmte Metriken untersucht und bei Anomalien Personen alarmiert. Dies ist auch die bevorzugte Überwachungsart. Reaktive Überwachung erfolgt, wenn sich ein Vorfall ereignet hat (in der Regel bei Sicherheitsvorfällen oder Performance-Problemen).
Übersicht der zu überwachenden Metriken
Ein interessanter Podcast zum Thema sowie das in dem Zusammenhang entstandene Community Document bilden die Grundlage für die empfohlene Metrik-Übersicht:
System-Monitoring
Datenbank-Monitoring
- TPS (= Transactions per Second) und QPS (= Queries per Second)
- Durchschnittliche Query-Dauer
- Längste Transaktionen (max transaction age oder top-n transactions by age)
- Commits & Rollbacks – wie viele Transaktionen werden rückgängig gemacht
- Transaction Wraparound – wie viele Transaktionen noch bis zum Limit
- Replication Lags
- Bytes in Replication Slot
- Ungenutzte Replication Slots
- Anzahl der WAL-Dateien, die auf Archivierung warten
- WAL generation rates
- Locks und deadlocks
- Query-Graph (Top n by total_time)
System-Monitoring
Bevor wir uns mit der Datenbanküberwachung beschäftigen, werfen wir einen Blick aufs System, auf dem die Datenbank läuft. Hervorzuheben sind dabei die folgenden Metriken:
Eine hohe CPU-Last kann dazu führen, dass die Datenbank nicht schnell genug auf Anfragen reagieren kann. Das kann zu Verzögerungen bei Ergebnisbereitstellung führen und die Antwortzeit der Datenbank verlangsamen.
Load Average
Auch ein hoher Load Average kann wegen verzögerter Anfragenreaktion zu langsamen Datenbank-Antwortzeiten führen. Ein Datenverlust ist ebenfalls möglich, wenn nicht alle eingehenden Anfragen bearbeitet werden können. Zu beachten ist, dass ein Load Average nicht nur die CPU berücksichtigt, sondern auch die Anzahl der Prozesse, die auf den CPU-Zugriff warten. D.h. eine hohe Load Average bedeutet nicht zwingend, dass die CPU-Last auch hoch ist.
Swap I/O
Da der Zugriff auf den Swap-Speicher langsamer ist als auf den RAM, hat auch das negative Auswirkungen auf die Antwortzeiten der Datenbank, wenn diese auf Daten im Swap-Speicher zugreifen muss. Läuft der Swap voll, kann sich das negativ auf die Systemstabilität auswirken.
Read and write latency
Neben potenziell langsamen Antwortzeiten kann eine hohe Read- / Write-Latenz zu Verzögerungen bei Transaktionen führen. Werden bei Latenzproblemen Transaktionen nicht schnell genug ausgeführt, kann das dazu führen, dass Transaktionen zu lange dauern und / oder fehlschlagen.
Disk space
Ob beim Schreiben in die Datenbank oder der Datensicherung. Ohne ausreichend Plattenplatz kann es zu Datenverlust kommen.
Page cache hit/miss
Eine hohe Miss-Rate bedeutet, dass die Datenbank mehr Daten von der Festplatte lesen muss, als auf die in dem Page Cache vorhandenen zuzugreifen. Das führt zu Performance-Problemen wie langsame Reaktionszeit oder verzögerter Anfragenverarbeitung. Eine hohe Hit-Rate bedeutet, dass der Page Cache mehr Speicherplatz braucht. Ist die Hit-Rate zu hoch und wird der Page-Cache zu groß, hat das negative Auswirkungen auf andere Anwendungen, was ebenfalls zu Performance-Problemen führen kann.
Datenbank-Monitoring
Nachdem wir wissen, dass unser System überwacht wird und gesund ist, schauen wir uns mal ein paar besondere Datenbank-Metriken an:
TPS (= Transactions per Second) und QPS (= Queries per Second)
TPS ist die Anzahl der Transaktionen, QPS die Anzahl der Abfragen, die pro Sekunde von der Datenbank verarbeitet werden können. Ermittelt werden können diese, in dem man die Anzahl der verarbeiteten Transaktionen/Abfragen in einem bestimmten Zeitraum durch die Zeit dividiert.
Sinkt die TPS oder QPS, kann es passieren, dass Abfragen und Transaktionen länger brauchen, bis sie abgeschlossen werden. Weiterhin kann es sein, dass die Datenbank nicht in der Lage ist, bei steigender Last entsprechend zu skalieren.
Durchschnittliche Query-Dauer
Steigt die Durchschnittszeit bei Queries an, kann es ein Hinweis darauf sein, dass Queries ineffizient arbeiten oder die Datenbank durch einen Engpass der Infrastruktur überlastet ist.
Längste Transaktionen (max transaction age oder top-n transactions by age)
Lange Transaktionen können einige Probleme mit sich bringen. Da Transaktionen Ressourcen der Datenbank in Anspruch nehmen und blockieren, kann es passieren, dass es zu Engpässen an ebendiesen kommt und die Datenbank früher oder später nicht mehr reagiert.
Commits & Rollbacks – wie viele Transaktionen werden rückgängig gemacht
In der Datenbank werden Commits und Rollbacks dazu verwendet, um Transaktionen erfolgreich abzuschließen und Änderungen festzuschreiben oder abzubrechen und Änderungen rückgängig zu machen.
Sind in der Datenbank viele Rollbacks zu verzeichnen, kann es ein Hinweis darauf sein, dass es mit der Datenkonsistenz Probleme gibt. Ebenfalls kann es ein Indikator dafür sein, dass die Auslastung hoch ist oder Abfragen ineffizient ausgeführt werden.
Transaction Wraparound – wie viele Transaktionen noch bis zum Limit
Die meisten Datenbanken verwenden eine 32-Bit signed Integer Transaktions-ID zur Verfolgung von Transaktionen. D.h. dass es ca. 2,1 Milliarden Transaktionen geben kann, bevor die höchste Transaktions-ID erreicht wird. Geschieht dies, kann ein Transaction Wraparound auftreten.
Allgemein bedeutet das, dass eine Transaktions-ID nicht mehr eindeutig ist und mit anderen Transaktionen kollidieren kann. Dadurch ist die Datenbank nicht mehr in der Lage, Transaktionen zu verarbeiten, sodass Datenverlust droht.
Replication Lags
Replication Lags treten idR dann auf, wenn die Replikation nicht in Echtzeit erfolgt und es zu Verzögerungen zwischen Schreiben der Daten auf dem Primärknoten und dem Übertragen der Daten auf die Replikate kommt. Dabei können normalerweise geringe Lags toleriert werden.
Regelmäßig oder über einen längeren Zeitraum hohe Replication Lags können zu Problemen führen, z.B. zur Beeinträchtigung der Datenbank-Reaktionsfähigkeit, sodass Replikate nicht aktuell sind, was zu Inkonsistenzen oder Datenverlust führen kann.
Bytes in Replication Slot
Die Anzahl der Bytes in einem Replication Slot hängt davon ab, wie viele Änderungen auf dem Primärknoten vorgenommen wurden und wie oft die Replikation stattfindet. Allerdings stellen Bytes im Replication Slot noch kein Problem dar.
Ist der Replication Slot voll, kann es passieren, dass die Replikation gestoppt wird und somit ein Datenverlust droht. Ein hoher Wert kann sich auf den Arbeitsspeicher der Datenbank auswirken, was wiederum negativ für die Datenbank-Performance ist.
Ungenutzte Replication Slots
Ein Replication Slot reserviert Speicherplatz für eine Replikation auf dem Primärknoten. Wird ein Slot erstellt, wird ein Teil des Arbeitsspeichers auf dem Primärknoten reserviert.
Bleiben Replication Slots ungenutzt, kann es passieren, dass sich WAL-Dateien auf dem Primärknoten stapeln. Dieses Speicherplatzproblem kann sich negativ auf die Datenbank-Performance auswirken.
Anzahl der WAL-Dateien, die auf Archivierung warten
Diese Metrik gibt an, wie viele WAL-Dateien (= Write-Ahead Log) noch auf Archivierung warten. WAL-Dateien sind Protokolldateien, die Datenbank-Änderungen festhalten, um nach einem Systemabsturz die Datenbank konsistent wiederherstellen zu können.
Ist die Anzahl auf Archivierung wartender WAL-Dateien zu hoch, kann es passieren, dass der verfügbare Speicherplatz für WAL-Dateien erschöpft ist. Geschieht dies, droht Datenverlust, da keine WAL-Dateien mehr geschrieben werden können. Weiterhin kann ein hoher Archiving Lag darauf hinweisen, dass es ein Problem mit dem Archivierungsprozess gibt, weil z.B. der Archivierungsspeicher zu langsam ist oder das Netzwerk Probleme hat.
Da grundsätzlich beim Datenbank-Start vor dem Normalbetrieb alle offenen Transaktionen sowie die im WAL festgehaltenen Änderungen wiederhergestellt werden müssen, kann es bei vielen auf Archivierung wartenden WAL-Dateien passieren, dass der Startprozess länger andauert.
WAL generation rates
Diese Metrik gibt an, mit welcher Geschwindigkeit die Datenbank WAL-Dateien generiert.
Ist der Wert zu hoch, heißt das, dass viele Datenbankänderungen vorgenommen werden. Das kann sich negativ auf die Performance auswirken, da unter Umständen die Transaktionsverarbeitung verlangsamt wird. Weiterhin kann eine hohe Generierungsrate den WAL-Speicher zum Überlauf bringen, sodass die Datenbank nicht mehr aufzeichnen kann und ein Systemausfall droht.
Locks und deadlocks
Ein Lock ist ein Mechanismus, mit dem die Datenbank gleichzeitigen Datenzugriff und deren Änderung durch mehrere Benutzer verhindert. Zu einem Deadlock kommt es dann, wenn mehrere Transaktionen Ressourcen sperren, die von der jeweils anderen Transaktion benötigt werden.
Blockieren Locks & Deadlocks die Datenbank, kann die Performance darunter leiden, da die Transaktionen und Abfragen langsamer ausgeführt werden. Steigen die Locks & Deadlocks an, kann sich das auch negativ auf die Skalierbarkeit der Datenbank auswirken. Ebenso können negative Seiteneffekte auftreten, wenn Transaktionen aufgrund von Deadlocks nicht abgeschlossen und abgebrochen werden müssen.
Query-Graph (Top n by total_time)
Lang dauernde Queries können zu Engpässen in der Datenbank führen, die sich negativ auf die Leistung auswirken und z.B. zu verzögerter Ausgabe von Daten führen.
