AWS Enhanced Monitoring: Problemanalyse bei AWS RDS

Mit diesem Deep Dive ins AWS Enhanced Monitoring zeigen wir euch, wie man Problemen bei AWS RDS Datenbanken (wie plötzlichen Abfällen der CPU-Auslastung) auf die Schliche kommen kann.

Problemanalyse bei AWS RDS

Um die folgenden Analysen besser nachvollziehen zu können, sollten folgende Themen bekannt sein:

Problem

Es gab bei einem unserer Projekte regelmäßig Verluste bei der Ausführungsgeschwindigkeit ihrer Anwendung. In unseren Standard-Monitoring-Systemen (AWS CloudWatch & New Relic) waren unter anderem plötzliche Abfälle bei der CPU-Auslastung der Datenbank (AWS RDS MySQL5.6 mit General Purpose Storage) ersichtlich. Damit hatten wir zwar den ungefähren Zeitpunkt, aber es gab sonst keinerlei Anhaltspunkte für die Ursache.

rds-cloudwatch

CPU-Auslastung im CloudWatch

Wir haben dann AWS Enhanced Monitoring für die Datenbank aktiviert. Damit hatten wir schlagartig sehr viele neue Metriken und Graphen für die Analyse zur Verfügung.

rds-em-metrics

verfügbare Metriken mit AWS Enhanced Monitoring

Zu den Störungszeiten waren in den Graphen des AWS Enhanced Monitorings ungewöhnliche Verhaltensmuster erkennbar. Leider visualisierten die Graphen vom AWS Enhanced Monitoring maximal die letzte Stunde. Dadurch konnten die bereitgestellten Informationen zum gleichen Ereigniszeitraum nie vollständig analysiert werden.

rds-em

Graphen des AWS Enhanced Monitoring mit markiertem Ereigniszeitpunkt

Die Ursache

Die Störung wurde durch das Aufbrauchen der IOPS-Credit der Datenbank verursacht. In einem solchen Fall werden die nutzbaren IOPS auf das zugesicherte Limit beschränkt. Dieses berechnet sich aus einem statischen Wert und der Größe des reservierten Storage.

Durch das Bursting-Feature kann eine Datenbank mit General Purpose Storage bis zu 3000 IOPS für einen geringen Zeitraum nutzen. Für jede Zeiteinheit, in der die genutzten IOPS über dem zugesicherten Limit liegen, werden die Credits reduziert. Wenn weniger IOPS als das zugesicherte Limit genutzt werden, erhöhen sich die Credits. Diese Berechnungen basieren auf den System-IOPS. Diese sind nur im Enhanced Monitoring von AWS und nicht im CloudWatch sichtbar.

Die Datenbank unserer Kunden hat zu nutzerstarken Zeiten mehr als die zugesicherten IOPS verbraucht. Mit steigender Nutzerzahl stiegen natürlich auch die IOPS und somit verkürzte sich der Zeitraum in dem das Bursting genutzt werden konnte. Das AWS CloudWatch hatte dabei zu einem Zeitpunkt ca. 260 IOPS angezeigt. Im AWS Enhanced Monitoring wurden zum gleichen Zeitpunkt 420 IOPS angegeben. Dieser Unterschied ist eine Folge aus den unterschiedlichen Messorten. AWS CloudWatch zeichnet die durch die MySQL-Engine ausgegebenen IOPS auf. AWS Enhanced Monitoring hingegen liest die IOPS aus dem System aus. Die MySQL-Engine bezieht bei ihrer Berechnung IOPS durch z.B. temporär erstellte Tabellen nicht mit ein. Durch diesen Umstand wurde die Überschreitung des zugesicherten Limits erst sichtbar, als wir die Daten aus dem Enhanced Monitoring analysiert haben.

Die Lösung

Es gibt für die Beseitigung dieser Ursache 3 Lösungsansätze.

  1. Verringerung der IOPS durch Anpassung/Optimierung der Applikation
  2. Vergrößerung des Storage, sodass das zugesicherte IOPS Limit erhöht wird und über dem durchschnittlichen Verbrauch liegt
  3. Umstellung der Datenbank auf Provisioned IOPS Storage

Wir haben uns für den dritten Lösungsansatz entschieden.

Lösung 1. war bei diesem Projekt nicht umsetzbar, weil:

  • eine Dritt-Anbieter-Software genutzt wird
  • die notwendigen Anpassungen zur Optimierung der Datenbankzugriffe sind zu nah am Core der Software
  • die Wartbarkeit und die Update-Fähigkeit der Software würde stark erschwert werden

Lösung 2. wurde wegen folgender Nachteile nicht umgesetzt:

  • erhöht die Kosten für das Backup, da immer komplette Snapshots erstellt werden
  • verlängert die Zeit von Wartungsarbeiten, z.B.
    • Wiederherstellung von Snapshots
    • Umstellung des Storage z.B. für mehr IOPS
    • Aktualisierung der MySQL-Engine
    • Vergrößerung der Instanzleistung z.B. durch Erhöhung CPU-Anzahl oder des RAM

Der Weg

Wie haben wir nun die aufgelisteten Probleme gelöst?

Mittels AWS Cloudwatch haben wir die Datenbank als im Fehler involviertes System erkannt. Da wir keine Auffälligkeiten bei den anderen Komponenten und in den Applikationslog finden konnten, haben wir uns bei der Analyse auf die Datenbank konzentriert. Um die geringe Sichtbarkeit des AWS CloudWatch zu kompensieren, haben wir bei der Datenbank das AWS Enhanced Monitoring aktiviert. Leider war das Zeitfenster der Graphen (siehe Problem) zu klein, um die Ursache genau erkennen zu können. Daher haben wir uns genauer mit den Eigenschaften von AWS Enhanced Monitoring beschäftigt. Dabei haben wir gesehen, dass es alle getrackten Daten in AWS CloudWatch Logs in der Log-Gruppe RDSOSMetrics speichert.

Alle zu einem spezifischen Zeitpunkt erfassten Werte werden in einem JSON Dictionary zusammengefasst als Eintrag im AWS CloudWatch Logs hinterlegt. Die Werte sind absolut und werden nicht gemittelt. Man kann sich die Log-Einträge in der Oberfläche des AWS CloudWatch Logs ansehen. Dabei ist auch eine rudimentäre Suche möglich. Eine Aggregation oder Visualiserung der Daten kann in der Oberfläche jedoch nicht durchgeführt werden.

rds-em-cwl

AWS Enhanced Monitoring Daten im AWS CloudWatch Logs

Die Log-Einträge selbst sind also in der Form keine Hilfe.

Wir haben dann eine Möglichkeit zur Visualisierung der Daten gesucht. Das JSON-Format ist dabei bereits eine gute Hilfe. Nach einigen Suchmaschinen-Anfragen sind wir auf Flot gestoßen. Diese JavaScript-Bibliothek kann aus JSON formatierten Daten recht schnell gut nutzbare Graphen plotten. Die ersten Versuche die Log-Daten direkt ans Flot zu geben, waren leider nicht erfolgreich. Das liegt an der Art, wie wir die Daten aus AWS CloudWatch Logs exportieren. Wir nutzen dazu die AWS-Cli mit dem Sub-Befehl ‚logs‘. Dieser gibt ein JSON mit Kontroll-Informationen und den Log-Daten zurück. Durch die Kapselung von JSON in JSON werden die Log-Daten maskiert. Deshalb kann Flot diese nicht direkt nutzen.

Zur Beseitigung dieses Umstandes haben wir ein Shell-Script geschrieben. Dieses lädt automatisch die Log-Daten herunter und bereitet diese so vor, dass Flot damit arbeiten kann. Mittels unterschiedlichen Argumenten kann die Quelle gesteuert werden. Das Standard-Argument ‚-h‘ zeigt natürlich eine Hilfe an:

 

fetch-logs.sh [-h] -g <log-group-name> -s <log-stream-name> [-b <start-time>] [-e <end-time>] [-p <awscli-profile-name>]
  -b: start time of log to be fetched in 'UNIX timestamp format * 1000' (default = 0)
  -e: end time of log to be fetched in 'UNIX timestamp format + 1000' (default = now)
  -g: name of log group (see aws [--profile <awscli-profile-name>] logs describe-log-groups or AWS Console)
  -h: this help
  -p: name of aws cli profile
  -s: name of log stream (see aws [--profile <awscli-profile-name>] --log-group-name <log-group-name> logs decribe-log-streams or AWS Console)
    UNIX timestamp format can be generated with:
     "date -d '2016-01-09 15:00:00' +%s000"

Nachdem Script-Durchlauf gibt es im Script-Verzeichnis zwei neue Dateien. „logs.json“ beinhaltet alle Daten, die per AWS-Cli heruntergeladen wurden. „clean_metrics.json“ beinhaltet ein JSON Dictionary mit allen zu plottenden Daten. Dabei wird im Script festgelegt, welche Daten ausgelesen und in die Datei geschrieben werden.

Visualisierung AWS RDS Enhanced Monitoring

Script-Ausgabe

Wenn „clean_metrics.json“ erfolgreich erstellt wurde, muss nur noch die „index.html“ in einem Browser aufgerufen werden. Diese liest automatisch die JSON-Datei ein und startet das Plotting der Werte.

Die Seite bietet einige Features, die eine Analyse erleichtern:

  • „Small Graphs“ – zeigt kleine Graphen an, sodass bei einer Auflösung von 1920×1080 alles auf einen Bildschirm passt (Standard-Ansicht)
  • „Big Graphs“ – vergrößert die Graphen, sodass sie die ganze Monitorbreite einnehmen
  • „Reset“ – setzt Zoom-Stufe und Scroll-Bereich zurück
  • Pfeil nach links/rechts – verschiebt den sichtbaren Zeitrahmen in die entsprechende Richtung
  • ist der Mauszeiger innerhalb eines Graphen, wird er von einer senkrechten Linie begleitet
  • die senkrechte Linie wird über alle Graphen synchronisiert
  • alle Messpunkte zeigt beim Halten des Mauszeigers über den Punkt detailierte Informationen an
  • durch markieren eines Bereiches innerhalb eines Graphes werden alle Graphen auf den ausgewählten Abschnitt hineingezoomt

Hier ein paar Eindrücke der Ansicht:

 

Mit dem Script und den selbst geplotteten Graphen konnten wir bereits mehrere Fehlerursachen genauer eingrenzen und, wie in diesem Fall, beseitigen. Für uns ist dieses Tool mittlerweile Standard bei RDS Analysen und der Invest in Speicherplatz für AWS Enhanced Monitoring Daten lohnt sich.

Quellcode

Wir haben die Scripte natürlich mit unserem Konto auf Github veröffentlicht. Sie ist unter der Unlicense lizensiert. Damit kann also jeder den Code nutzen und manipulieren, wie es für den entsprechenden Zweck notwendig ist.

 

Wir hoffen, euch hilft dieses „Deep Dive“ ins Enhanced Monitoring von AWS.

Gebt uns gerne Feedback!

 

Update vom 28.02.2016 16:51: AWS Enhanced Monitoring wurde um eine Zeitfenster-Auswahl erweitert. Damit kann man das Zeitfenster von maximal einer Stunde verschieben und so alle getrackten Daten sichten.

AWS Enhanced Monitoring - Zeitfenster-Auswahl

Zeitfenster-Auswahl

Verpassen Sie keinen Cloud-Artikel mehr. Jetzt für unseren Newsletter anmelden!

Dieser Beitrag hat einen Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.