View a markdown version of this page

Überwachung von Aurora DSQL-Clustern mit Aurora DSQL Database Insights - Amazon Aurora DSQL
Was ist DASH?DASH-Metriken und WarteereignisseZugriff auf DASH-DatenZugehörige Ressourcen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Überwachung von Aurora DSQL-Clustern mit Aurora DSQL Database Insights

Aurora DSQL Database Insights bietet Zugriff auf pro Sekunde abgetastete Daten für jede aktive Sitzung in Ihrem Cluster, die vom DSQL Active Session History (DASH) -Sampler gesammelt wurden, der den Wartestatus und die normalisierte SQL-Anweisung aufzeichnet, die jede Sitzung ausführt. Per-minute Die aggregierten Ergebnisse von DASH werden als (oTEL) -Metriken veröffentlicht. CloudWatch OpenTelemetry Verwenden Sie diese Daten, um die Auslastung Ihrer Datenbank zu verstehen, die Abfragen zu finden, die die meisten Ressourcen verbrauchen, und Leistungsprobleme zu diagnostizieren.

Sie müssen DASH nicht einrichten. Es wird automatisch für jeden Aurora DSQL-Cluster aktiviert, und aggregierte Daten pro Minute sind ohne zusätzliche Kosten über Amazon CloudWatch Database Insights und über Prometheus Query Language (PromQL) -Abfragen verfügbar, die anhand CloudWatch von Otel-Metriken ausgeführt werden.

Was ist DASH?

Eine aktive Sitzung stellt eine einzelne Verbindung zu Ihrem Cluster dar, für die eine Transaktion geöffnet ist. Zu jedem Zeitpunkt befindet sich jede aktive Sitzung in einem von drei Zuständen:

  • CPU verwenden

  • Es wird auf den Abschluss eines externen Vorgangs gewartet, z. B. ein Speicherlesevorgang oder eine Commit-Bestätigung

  • Während der Transaktion inaktiv, es wird auf die nächste Anweisung Ihrer Anwendung in einer offenen Transaktion gewartet

DASH verfolgt nur Sitzungen, für die eine Transaktion offen ist. DASH erfasst diese Aktivität, indem es alle aktiven Sitzungen auf Ihrem Cluster einmal pro Sekunde abtastet. Jede Stichprobe zeichnet zwei Dinge auf:

  • Das Warteereignis — der Status, in dem sich die Sitzung zum Zeitpunkt der Probenahme befand. Die DASH-Warteereignisse vollständige Liste finden Sie unter.

  • Die SQL-Anweisung — die ersten 256 Zeichen der SQL-Anweisung, die in der Sitzung ausgeführt wurde. Dies ist ausreichend, um die meisten Abfragen zu identifizieren.

DASH aggregiert diese Stichproben pro Sekunde und veröffentlicht sie CloudWatch einmal pro Minute, aufgeschlüsselt nach Warteereignissen und SQL-Anweisungen. Das Ergebnis ist eine einzelne Zeitreihenmetrikdb.active_sessions.avg, die die durchschnittliche Anzahl der aktiven Sitzungen in jedem Probenzeitraum aufzeichnet. Dieser Wert wird auch als Average Active Sessions (AAS) bezeichnet.

AAS ist das grundlegende Signal für die Aurora DSQL-Leistungsanalyse. Die Aufschlüsselung der Warteereignisse zeigt, wofür Ihre Sitzungen Zeit aufwenden, und nicht nur, wie stark der Cluster ausgelastet ist. Die SQL-Aufschlüsselungsattribute werden in einzelne Abfragen geladen.

Tipp

Aurora DSQL skaliert die CPU elastisch, sodass das nützlichste Diagnosesignal die Form des Warteprofils (die proportionale Verteilung der Sitzungszeit auf die Warteereignisse) ist und nicht AAS gegenüber einer festen vCPU-Obergrenze. Vergleichen Sie diese Form mit der Basislinie, die Sie während des normalen Betriebs beobachten. Eine Änderung dieser Proportionen deutet auf eine Veränderung der Arbeitslast oder des Systemverhaltens hin.

DASH-Metriken und Warteereignisse

DASH stellt eine einzelne Metrik zur Verfügung, deren Dimensionen es Ihnen ermöglichen, das Laden der Datenbank nach Warteereignissen und SQL-Anweisungen zu segmentieren. In der folgenden Tabelle wird die DASH-Metrik beschrieben.

Metrik Einheit Description
db.active_sessions.avg Anzahl Die durchschnittliche Anzahl aktiver Sitzungen auf dem Cluster während des Probenahmezeitraums (AAS). Jede aktive Sitzung wird entweder auf der CPU oder in einem benannten Wartezustand ausgeführt.

Die Metrik hat die folgenden Dimensionen (Labels), die Sie verwenden, um die Daten zu gruppieren und zu filtern.

Dimension Description
db.wait.class Die umfassendere Klassifizierung von Warteereignissen, um den allgemeinen Ressourcentyp zu identifizieren, der zur Datenbanklast beiträgt. class:oncpuBedeutet beispielsweise, dass die Anweisung aktiv auf der CPU ausgeführt wird und class:io dass die Anweisung auf den Abschluss eines input/output Vorgangs wartet.
db.wait.event Der Wartestatus, in dem sich die Stichprobensitzungen befanden. Die DASH-Warteereignisse vollständige Werteliste finden Sie unter.
db.session.state Der Sitzungsstatus — active (Ausführung einer Anweisung) oder idle in transaction (Warten auf den nächsten Befehl von der Anwendung, während die Transaktion geöffnet bleibt).
db.query.id Der Fingerabdruck des normalisierten SQL-Textes der Anweisung, die in den Sitzungen ausgeführt wurde.
db.query.normalized_text Der normalisierte SQL-Text der Anweisung, die in den Sitzungen ausgeführt wurde. DASH entfernt Literalwerte, sodass Anweisungen gruppiert werden, die sich nur in ihren Parametern unterscheiden.
aws.auroradsql.session.role.arn Die IAM-Rolle ARN ging davon aus, eine Verbindung zum Aurora DSQL-Cluster herzustellen.
application.name Der Anwendungsname, den Sie in den Verbindungsparametern festgelegt haben. Sie können ihn bei der Verbindungsherstellung überschreiben. DASH schließt diese Dimension nur ein, wenn Sie sie explizit festlegen.

DASH-Warteereignisse

In Aurora-DSQL-Sitzungen können die folgenden Warteereignisse auftreten. Die speicherbezogenen Warteereignisse —SequentialScanRead,, ScatteredBatchRead SingleReadUniqueConstraintCheck, und FkExistenceCheck — stellen die Kommunikation zwischen der Abfrageverarbeitungsebene und der Speicherschicht sowie die Kommunikation mit dem Commit Commit-Service dar. Diese Liste könnte im Laufe der Zeit erweitert werden, da Aurora DSQL neue Warteereignisse identifiziert.

Warteereignis Warte, Klasse Description
OnCpu class:oncpu Die Sitzung wartet nicht auf externe Eingaben und wird aktiv auf der CPU ausgeführt. Dabei werden Ausdrücke analysiert, geplant, ausgewertet oder Ergebnisse verarbeitet.
ClientRead class:client Die Sitzung befindet sich innerhalb einer offenen Transaktion im Leerlauf und wartet darauf, dass die Anwendung die nächste SQL-Anweisung oder einen commit/rollback Befehl sendet. Häufige oder lange ClientRead Wartezeiten deuten oft auf übermäßige Anwendungs-Roundtrips oder Transaktionen hin, die Sie länger als nötig geöffnet halten.
ClientWrite class:client Die Datenbank sendet Ergebnisse über das Netzwerk an die Anwendung. Ein hoher ClientWrite Wert kann auf große Ergebnismengen oder eine Netzwerklatenz zwischen der Anwendung und der Datenbank hinweisen.
SequentialScanRead class:io Die Sitzung liest einen zusammenhängenden Bereich von Schlüsseln aus dem Speicher. Dabei handelt es sich nicht unbedingt um einen vollständigen Tabellenscan — er deckt möglicherweise einen relativ kleinen Bereich zusammenhängender Schlüssel ab.
ScatteredBatchRead class:io Die Sitzung führt stapelweise Lesevorgänge aus dem Speicher durch und ruft mehrere nicht zusammenhängende Schlüssel in einem einzigen Speicheraufruf ab.
SingleRead class:io Die Sitzung liest ein einzelnes Tupel (Punktsuche) aus dem Speicher. ScatteredBatchReadmit einer Batchgröße von 1 ersetzt dieses Ereignis weitgehend, was in aktuellen Aurora DSQL-Versionen ungewöhnlich ist.
UniqueConstraintCheck class:io In der Sitzung werden eindeutige Schlüsseleinschränkungen validiert, was bedeutet, dass Speicherlesevorgänge erforderlich sind, um nach Duplikaten zu suchen. Dies gilt sowohl für eindeutige Einschränkungen für Spalten, die keine Primärschlüsselspalten sind, als auch für Primärschlüsseleinschränkungen beim Einfügen neuer Zeilen.
FkExistenceCheck class:io In der Sitzung wird überprüft, ob eine Fremdschlüsselzeile, auf die verwiesen wird, vorhanden ist. Lesevorgänge sind erforderlich, um die Beziehung zu bestätigen.
StartTransaction class:io Die Sitzung bereitet den Beginn der verteilten Transaktion vor.
Commit class:io Die Sitzung hat einen Commit initiiert und wartet auf die Bestätigung durch den Commit-Service. Die Antwort ist entweder ein Erfolg oder ein Abbruch (Serialisierungsfehler). Beiden Ergebnissen geht eine Commit Wartezeit voraus.
PgSleep class:timeout Die Sitzung befindet sich im Ruhezustand, da die Anwendung explizit aufgerufen wurde. pg_sleep() Dabei handelt es sich um eine von der Anwendung initiierte Wartezeit, nicht um eine von der Datenbank auferlegte Wartezeit.

Zugriff auf DASH-Daten

Sie können auf drei Arten auf DASH-Daten zugreifen:

  • Amazon CloudWatch Database Insights — Eine kuratierte Benutzeroberfläche (UI) ohne Code zur Erkundung der Datenbanklast und der wichtigsten SQL-Befehle. Dies ist der Ausgangspunkt für die meisten Untersuchungen.

  • PromQL — Fragen Sie die zugrunde liegende db.active_sessions.avg Metrik programmgesteuert ab, um sie in Überwachungstools von Drittanbietern zu integrieren oder um sie interaktiv zu untersuchen.

  • KI-Fähigkeit zur DSQL-Systemdiagnose von Aurora — Ein auf künstlicher Intelligenz (KI) basierender Gesundheitscheck-Agent, der automatisch DASH-Daten analysiert, die Verteilung von Warteereignissen über Zeitrahmen hinweg vergleicht und Diagnoseberichte generiert.

Alle diese Zugriffspfade werden aus demselben DASH-Datensatz gelesen.

Verwenden von CloudWatch Database Insights

Amazon CloudWatch Database Insights präsentiert DASH-Daten über ein von Aurora DSQL-specific kuratiertes Dashboard. Ihre Aurora DSQL-Cluster werden automatisch in Database Insights angezeigt. Sie benötigen keine weitere Einrichtung, außer den Cluster zu erstellen und Transaktionen darauf auszuführen.

Um DASH-Daten in Database Insights anzuzeigen

  1. Öffnen Sie die CloudWatch Konsole und wählen Sie im linken Navigationsbereich Database Insights aus.

  2. Suchen Sie in der Fleet Health-Ansicht Ihren Aurora DSQL-Cluster in der Liste der Datenbankressourcen. Alternativ können Sie direkt zur Datenbank-Instance-Seite navigieren und Ihren Cluster im linken Bereich auswählen.

  3. Wählen Sie den DB-Identifier, um das Database Instance Dashboard zu öffnen.

  4. Verwenden Sie das Diagramm DB-Auslastung, um die durchschnittlichen aktiven Sessions im Zeitverlauf anzuzeigen. Bei dem Diagramm handelt es sich um eine gestapelte Visualisierung, bei der jedes farbige Band für ein Warteereignis steht. Die Gesamthöhe zeigt also, wie stark der Cluster ausgelastet ist, und die Bänder zeigen, für welche Sessions ihre Zeit aufgewendet wird.

  5. Verwenden Sie das Steuerelement Slice By im DB-Load-Diagramm, um zwischen Warteereignissen und SQL-Text umzuschalten.

  6. Im Abschnitt „DB-Lastanalyse“ werden AAS nach den wichtigsten Warteereignissen und die Top-SQL nach ihrem Beitrag zu AAS sortiert.

  7. Verwenden Sie die Zeitbereichsauswahl oben auf der Seite, um sich auf ein bestimmtes Überwachungsfenster zu konzentrieren, z. B. auf den Zeitraum einer gemeldeten Verlangsamung.

Verwenden von PromQL

DASH stellt Daten als CloudWatch Metrik zur Verfügungdb.active_sessions.avg, die Sie mit PromQL in Query Studio abfragen können. CloudWatch

Die folgenden Beispiele funktionieren in Query Studio, wo der aktive Workspace die Ergebnisse bereits Ihrem Konto und Ihrer Region zuordnet und die Zeitauswahl das Bewertungsfenster steuert. Da der Metrikname Punkte enthält, verwenden die Beispiele die PromQL-Auswahlform für zitierte Namen,. {"db.active_sessions.avg"}

Anmerkung

Alle Beispiele enthalten einen @resource.aws.auroradsql.cluster_id Labelfilter, um die Ergebnisse auf einen einzelnen Cluster zu beschränken. cluster-idErsetzen Sie es durch Ihre Cluster-ID. Wenn Sie nur einen Cluster haben, können Sie diesen Filter weglassen oder stattdessen die UI-Filter von Query Studio verwenden. Um alle Labels zu ermitteln, die für die Metrik in Ihrer Umgebung verfügbar sind, führen {"db.active_sessions.avg"} Sie eine Serienabfrage aus und überprüfen Sie den Labelsatz für jede zurückgegebene Serie.

Die Datenbank wird nach einem Warteereignis geladen

Gibt die durchschnittliche Anzahl der aktiven Sitzungen, gruppiert nach Warteereignissen, zurück. Dabei handelt es sich um dieselbe AAS-by-wait-event Ansicht, die im Database Insights-DB-Load-Diagramm verfügbar ist, aber programmgesteuert zugänglich ist.

avg by ("db.wait.event") (
  {
    "db.active_sessions.avg",
    "@resource.aws.auroradsql.cluster_id"="cluster-id"
  }
)

Das Ergebnis enthält eine Reihe pro eindeutigem db.wait.event Wert, die jeweils den durchschnittlichen AAS-Beitrag dieses Wartezustands enthalten.

Top-SQL nach durchschnittlich aktiven Sitzungen

Ordnet SQL-Anweisungen nach ihrem durchschnittlichen Beitrag zur Datenbanklast. Dies ist das PromQL-Äquivalent der Top-SQL-Ansicht von Database Insights.

topk(5,
  avg by ("db.query.normalized_text") (
    {
      "db.active_sessions.avg",
      "@resource.aws.auroradsql.cluster_id"="cluster-id"
    }
  )
)

Um die wichtigsten Kombinationen von SQL-Anweisungen und Warteereignissen nach ihrem Beitrag zum Laden anzuzeigen, fügen Sie der db.wait.event Gruppierungsklausel etwas hinzu. Da dabei alle Kombinationen in eine Rangfolge gebracht werden, können die Ergebnisse mehrere Warteereignisse für dieselbe Anweisung mit hohem Beitrag beinhalten:

topk(5,
  avg by ("db.query.normalized_text", "db.wait.event") (
    {
      "db.active_sessions.avg",
      "@resource.aws.auroradsql.cluster_id"="cluster-id"
    }
  )
)
SQL-Anweisungen, die die meisten Speicherlesevorgänge ausführen

Gibt die fünf SQL-Anweisungen zurück, die am meisten Zeit mit Speicherlesevorgängen verbringen, indem nach den Speicher-Read-Wait-Ereignissen gefiltert wird.

topk(5,
  sum by ("db.query.normalized_text") (
    {
      "db.active_sessions.avg",
      "db.wait.event"=~"S.*Read|.*Check",
      "@resource.aws.auroradsql.cluster_id"="cluster-id"
    }
  )
)

Der reguläre Ausdruck S.*Read entspricht den Speicherleseereignissen, deren Namen mit Read (SequentialScanRead,,) beginnen S und damit enden. ScatteredBatchRead SingleRead Das Muster schließt .*Check explizit ein, weil die Ereignisse UniqueConstraintCheck und FkExistenceCheck wait nicht mit dem ersten Muster übereinstimmen, sondern es sich auch um Warteereignisse beim Speichern und Lesen handelt.

Verwenden des AI-Skills Aurora DSQL-Systemdiagnose

Die KI-Kompetenz Aurora DSQL-Systemdiagnose automatisiert die Zustandsprüfung Ihres Aurora DSQL-Clusters, indem sie DASH-Daten liest, die Verteilungen von Warteereignissen über Zeitrahmen hinweg vergleicht und einen Diagnosebericht generiert. Der Skill ist Teil des Databases-on-aws-Plugins in Agent Plugins for AWS im Repository awslabs/agent-plugins und funktioniert mit jedem unterstützten KI-Codierungsagenten.

Um den Zustand des Clusters zu analysieren, geben Sie eine Eingabeaufforderung wie die folgende ein:

„Überprüfen Sie die Leistung meines Aurora DSQL-Clusters cluster-id us-east-1 und schreiben Sie mir einen Markdown-Bericht.“

Der Skill verwendet den CloudWatch Model Context Protocol (MCP) -Server, um die db.active_sessions.avg Metrik über einen ausgewählten Zeitraum hinweg zu analysieren, und gibt einen Markdown-Bericht zurück. Sie können dieses Leistungsvergleichsfenster in der Eingabeaufforderung wie folgt steuern:

„Überprüfen Sie die Leistung der letzten 4 Stunden und vergleichen Sie sie mit der Leistung vom letzten Montag.“

Wenn bestimmte Abfragen problematisch erscheinen, leitet der Skill einen umfassenderen SQL-focused Diagnose-Workflow ein und meldet mögliche Lösungen für diese Aussage. Es entscheidet anhand der erkannten Warteereignisverschiebung, ob eine Abfrage weiter untersucht werden soll, sodass Sie keine zusätzlichen Eingabeaufforderungen benötigen.