Anzeigen reaktiver Anomalien

Innerhalb eines Insights können Sie Anomalien für Amazon-RDS-Ressourcen anzeigen. Auf einer Seite mit reaktiven Einblicken können Sie im Abschnitt Aggregierte Metriken eine Liste von Anomalien mit entsprechenden Zeitplänen anzeigen. Es gibt auch Abschnitte, in denen Informationen zu Protokollgruppen und Ereignissen im Zusammenhang mit den Anomalien angezeigt werden. Ursachenanomalien in einem reaktiven Einblick verfügen jeweils über eine entsprechende Seite mit Details zur Anomalie.

Anzeigen der detaillierten Analyse einer reaktiven RDS-Anomalie

In dieser Phase führen Sie einen Drilldown in der Anomalie durch, um die detaillierte Analyse und Empfehlungen für Ihre Amazon-RDS-DB-Instances zu erhalten.

Die detaillierte Analyse ist nur für Amazon RDS-DB-Instances verfügbar, für die Performance Insights aktiviert ist.

So führen Sie einen Drilldown auf die Seite mit den Anomaliedetails durch

1. Suchen Sie auf der Insight-Seite eine aggregierte Metrik mit dem Ressourcentyp AWS/RDS .

2. Wählen Sie die Option View details aus.

   Die Seite mit den Anomaliedetails wird angezeigt. Der Titel beginnt mit der Anomalie der Datenbankleistung und benennt die Ressource. Die Konsole verwendet standardmäßig die Anomalie mit dem höchsten Schweregrad, unabhängig davon, wann die Anomalie aufgetreten ist.

3. (Optional) Wenn mehrere Ressourcen betroffen sind, wählen Sie eine andere Ressource aus der Liste oben auf der Seite aus.

Im Folgenden finden Sie Beschreibungen für die Komponenten der Detailseite.

Ressourcenübersicht

Der obere Abschnitt der Detailseite ist Ressourcenübersicht . In diesem Abschnitt wird die Leistungsanomalie zusammengefasst, die bei Ihrer Amazon RDS-DB-Instance auftritt.

Dieser Abschnitt enthält die folgenden Felder:

• Ressourcenname – Der Name der DB-Instance, bei der die Anomalie auftritt. In diesem Beispiel heißt die Ressource prod_db_678.

• DB-Engine – Der Name der DB-Instance, bei der die Anomalie aufgetreten ist. In diesem Beispiel ist die Engine Aurora MySQL .

• Anomalieschweregrad – Das Maß für die negativen Auswirkungen der Anomalie auf Ihre Instance. Mögliche Schweregrade sind Hoch, Mittel und Niedrig.

• Zusammenfassung der Anomalie – Eine kurze Zusammenfassung des Problems. Eine typische Zusammenfassung ist Unnormal hohe DB-Last .

• Startzeit und Endzeit – Die Zeit, zu der die Anomalie begann und endete. Wenn die Endzeit Andauernd ist, tritt die Anomalie immer noch auf.

• Dauer – Die Dauer des anomalen Verhaltens. In diesem Beispiel ist die Anomalie andauernd und tritt seit 3 Stunden und 2 Minuten auf.

Primäre Metrik

Im Abschnitt Primäre Metrik wird die Telefonieanomalie zusammengefasst, bei der es sich um die Anomalie der obersten Ebene innerhalb des Insights handelt. Sie können sich die kausale Anomalie als das allgemeine Problem vorstellen, das bei Ihrer DB-Instance auftritt.

Im linken Bereich finden Sie weitere Details zu dem Problem. In diesem Beispiel enthält die Zusammenfassung die folgenden Informationen:

• Datenbanklast (DB-Last) – Eine Kategorisierung der Anomalie als Datenbanklastproblem. Die entsprechende Metrik in Performance Insights ist DBLoad. Diese Metrik wird auch in Amazon veröffentlicht CloudWatch.

• db.r5.4xlarge – Die DB-Instance-Klasse. Die Anzahl der vCPUs, die in diesem Beispiel 16 beträgt, entspricht der gepunkteten Linie im Diagramm Durchschnittliche aktive Sitzungen (AAS).

• 24 (6-fache Spitze) – Die DB-Last, gemessen in durchschnittlichen aktiven Sitzungen (AAS) während des im Insight gemeldeten Zeitintervalls. Daher waren zu einem bestimmten Zeitpunkt während des Zeitraums der Anomalie durchschnittlich 24 Sitzungen in der Datenbank aktiv. Die DB-Last ist das 6-fache der normalen DB-Last für diese Instance.

• In der Regel: DB-Last bis zu 4 – Die Baseline der DB-Last, gemessen in AAS, während einer typischen Workload. Der Wert 4 bedeutet, dass im normalen Betrieb durchschnittlich 4 oder weniger Sitzungen zu einem bestimmten Zeitpunkt in der Datenbank aktiv sind.

Standardmäßig wird das Lastdiagramm nach Warteereignissen aufgeteilt. Das bedeutet, dass für jeden Balken im Diagramm der größte farbige Bereich das Warteereignis darstellt, das am meisten zur gesamten DB-Last beiträgt. Das Diagramm zeigt den Zeitpunkt (in Rot), zu dem das Problem begann. Konzentrieren Sie sich auf die Warteereignisse, die am meisten Platz in der Leiste beanspruchen:

• CPU

• IO:wait/io/sql/table/handler

Die vorhergehenden Warteereignisse erscheinen für diese Aurora MySQL-Datenbank mehr als normal. Informationen zum Optimieren der Leistung mithilfe von Warteereignissen in Amazon Aurora finden Sie unter Optimieren mit Warteereignissen für Aurora MySQL und Optimieren mit Warteereignissen für Aurora PostgreSQL im Amazon-Aurora-Benutzerhandbuch. Informationen zum Optimieren der Leistung mithilfe von Warteereignissen in RDS für PostgreSQL finden Sie unter Optimieren mit Warteereignissen für RDS für PostgreSQL im Amazon-RDS-Benutzerhandbuch.

Verwandte Metriken

Im Abschnitt Verwandte Metriken werden die kontextbezogenen Anomalien aufgeführt, bei denen es sich um spezifische Erkenntnisse innerhalb der kausalen Anomalie handelt. Diese Erkenntnisse enthalten zusätzliche Informationen zu den Leistungsproblemen.

Die Tabelle Zugehörige Metriken hat zwei Spalten: Metrikname und Timeline (UTC). Jede Zeile in der Tabelle entspricht einer bestimmten Metrik.

Die erste Spalte jeder Zeile enthält die folgenden Informationen:

• Name – Der Name der Metrik. Die erste Zeile identifiziert die Metrik als CPU-Ausführungsaufgaben.

• Derzeit – Der aktuelle Wert der Metrik. In der ersten Zeile ist der aktuelle Wert 162 Prozesse (3x).

• Normal – Die Baseline dieser Metrik für diese Datenbank, wenn sie normal funktioniert. DevOpsGuru für RDS berechnet die Baseline als 95. Perzentilwert über 1 Woche Verlauf. Die erste Zeile zeigt an, dass normalerweise 56 Prozesse auf der CPU ausgeführt werden.

• Beitragend zu – Die Erkenntnis, die mit dieser Metrik verknüpft ist. In der ersten Zeile ist die Metrik für CPU-Ausführungsaufgaben mit der Anomalie verknüpft, bei der die CPU-Kapazität überschritten wurde.

Die Spalte Timeline zeigt ein Liniendiagramm für die Metrik. Der schattierte Bereich zeigt das Zeitintervall an, in dem DevOpsGuru für RDS die Erkenntnis als hochschwer eingestuft hat.

Analyse und Empfehlungen

Während die kausale Anomalie das Gesamtproblem beschreibt, beschreibt eine kontextbezogene Anomalie eine bestimmte Erkenntnis, die untersucht werden muss. Jede Erkenntnis entspricht einer Reihe verwandter Metriken.

Im folgenden Beispiel eines Abschnitts Analyse und Empfehlungen hat die Anomalie mit hoher DB-Last zwei Ergebnisse.

Diese Tabelle hat die folgenden Spalten:

• Anomalie – Eine allgemeine Beschreibung dieser kontextbezogenen Anomalie. In diesem Beispiel sind die erste Anomalie Warteereignisse mit hoher Last und die zweite ist eine Überschreitung der CPU-Kapazität.

• Analyse – Eine detaillierte Erklärung der Anomalie.

  In der ersten Anomalie tragen drei Wartetypen zu 90 % der DB-Last bei. In der zweiten Anomalie hat die CPU-Ausführungswarteschlange 150 überschritten, was bedeutet, dass zu einem bestimmten Zeitpunkt mehr als 150 Sitzungen auf CPU-Zeit warteten. Die CPU-Auslastung betrug über 97 %, was bedeutet, dass die CPU während der Dauer des Problems zu 97 % ausgelastet war. Daher war die CPU fast kontinuierlich belegt, während durchschnittlich 150 Sitzungen darauf warteten, auf der CPU ausgeführt zu werden.

• Empfehlungen – Die vorgeschlagene Benutzerantwort auf die Anomalie.

  In der ersten Anomalie DevOpsempfiehltGuru für RDS, die Warteereignisse cpu und zu untersuchenio/table/sql/handler. Informationen zum Optimieren der Datenbankleistung basierend auf diesen Ereignissen finden Sie unter cpu und io/table/sql/handler im Amazon-Aurora-Benutzerhandbuch.

  In der zweiten Anomalie DevOpsempfiehltGuru für RDS, den CPU-Verbrauch zu reduzieren, indem Sie drei SQL-Anweisungen optimieren. Sie können den Mauszeiger über die Links bewegen, um den SQL-Text zu sehen.

• Verwandte Metriken – Metriken, die Ihnen spezifische Messungen für die Anomalie liefern. Weitere Informationen zu diesen Metriken finden Sie unter Metrikreferenz für Amazon Aurora im Amazon-Aurora-Benutzerhandbuch oder Metrikreferenz für Amazon RDS im Amazon-RDS-Benutzerhandbuch.

  In der ersten Anomalie DevOpsempfiehltGuru für RDS, die DB-Last mit der maximalen CPU für Ihre Instance zu vergleichen. In der zweiten Anomalie besteht die Empfehlung darin, die CPU-Ausführungswarteschlange, die CPU-Auslastung und die SQL-Ausführungsrate zu betrachten.