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 sekundengenaue Stichprobendaten für jede aktive Sitzung auf Ihrem Cluster, die vom DSQL Active Session History (DASH) -Sampler erfasst werden, der den Wartestatus und die normalisierte SQL-Anweisung jeder Sitzung aufzeichnet. Per-minute Die aggregierten Ergebnisse von DASH werden als (OTel) -Metriken veröffentlicht. CloudWatch OpenTelemetry Verwenden Sie diese Daten, um Ihre Datenbanklast zu verstehen, die Abfragen zu ermitteln, 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 über Amazon CloudWatch Database Insights und über Prometheus Query Language (PromQL) -Abfragen verfügbar, die ohne zusätzliche Kosten 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:

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

DASH aggregiert diese sekundengenauen Stichproben und veröffentlicht sie CloudWatch einmal pro Minute, aufgeschlüsselt nach Wait-Ereignis und SQL-Anweisung. 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 aufgewendet haben, und nicht nur, wie stark der Cluster ausgelastet ist. Die Attribute der SQL-Aufschlüsselung werden in einzelne Abfragen geladen.

DASH-Metriken und Warteereignisse

DASH macht eine einzelne Metrik verfügbar, deren Dimensionen es Ihnen ermöglichen, die Datenbanklast nach Warteereignissen und SQL-Anweisungen zu unterteilen. In der folgenden Tabelle wird die DASH-Metrik beschrieben.

Die Metrik hat die folgenden Dimensionen (Labels), anhand derer Sie die Daten gruppieren und filtern.

DASH-Warteereignisse

Bei 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 Speicherebene dar und stellen die Kommunikation mit dem Commit Commit-Service dar. Diese Liste könnte sich im Laufe der Zeit erweitern, wenn Aurora DSQL neue Warteereignisse identifiziert.

Zugreifen auf DASH-Daten

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

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

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 auf Ihr Konto und Ihre Region begrenzt und die Zeitauswahl das Evaluierungsfenster steuert. Da der Metrikname Punkte enthält, verwenden die Beispiele das PromQL-Selektorformular für Anführungszeichen,. {"db.active_sessions.avg"}

Die Datenbank wird durch ein Warte-Ereignis geladen

Gibt die durchschnittliche Anzahl aktiver Sitzungen zurück, gruppiert nach dem Warteereignis — dieselbe AAS-by-wait-event Ansicht, die im DB-Load-Diagramm von Database Insights verfügbar ist, auf die jedoch programmgesteuert zugegriffen werden kann.

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, wobei jede den durchschnittlichen AAS-Beitrag dieses Wartestatus enthält.

Top-SQL nach durchschnittlich aktiven Sitzungen

Ordnet SQL-Anweisungen nach ihrem durchschnittlichen Beitrag zur Datenbanklast ein. Dies ist das PromQL-Äquivalent zur 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"
    }
  )
)

Fügen Sie der Grouping-Klausel hinzudb.wait.event, um die Top-SQL-Statements- und Wait-Ereigniskombinationen nach ihrem Anteil am Ladevorgang anzuzeigen. Da dabei alle Kombinationen in einer Rangfolge aufgeführt werden, können die Ergebnisse mehrere Wait-Ereignisse für dieselbe Anweisung mit hohem Nutzwert enthalten:

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 Speicherlesewarteereignissen 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 Storage-Read-Ereignissen, deren Namen mit Read (SequentialScanRead,,) beginnen S und enden. ScatteredBatchRead SingleRead Das Muster schließt .*Check explizit mit ein, weil die Ereignisse UniqueConstraintCheck und FkExistenceCheck wait nicht dem ersten Muster entsprechen, sondern ebenfalls Speicherlese-Warte-Ereignisse sind.

Verwenden der KI-Fähigkeit zur Aurora DSQL-Systemdiagnose

Die KI-Fähigkeit zur Aurora DSQL-Systemdiagnose automatisiert die Health-Check-Analyse Ihres Aurora DSQL-Clusters, indem sie DASH-Daten liest, die Verteilung von Warteereignissen über Zeitrahmen hinweg vergleicht und einen Diagnosebericht generiert. Der Skill ist Teil des Plug-ins „Databases-on-aws“ in Agent Plugins for AWS im awslabs/agent -plugins-Repository und funktioniert mit jedem unterstützten KI-Codierungsagenten.

Um den Zustand des Clusters zu analysieren, geben Sie eine Aufforderung wie die folgende aus:

„Prüfen Sie die Leistung meines Aurora-DSQL-Clusters cluster-id in 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 eine Auswahl von Zeitrahmen hinweg zu analysieren, und gibt einen Markdown-Bericht zurück. Sie können dieses Fenster für den Leistungsvergleich in der Eingabeaufforderung aufrufen:

„Überprüfe die Leistung der letzten 4 Stunden und vergleiche sie mit der Leistung vom letzten Montag.“

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

Zugehörige Ressourcen