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.
Verteilte Abfrageverfolgung in SQL Postgre-Protokollen in Aurora SQL Postgre Limitless Database
Distributed Query Tracing ist ein Tool zum Verfolgen und Korrelieren von Abfragen in SQL Postgre-Protokollen in der Aurora SQL Postgre Limitless Database. In Aurora Postgre verwenden Sie die Transaktions-IDSQL, um eine Transaktion zu identifizieren. In Aurora Postgre SQL Limitless Database kann sich die Transaktions-ID jedoch auf verschiedenen Routern wiederholen. Daher empfehlen wir, die Tracing-ID stattdessen in Limitless Database zu verwenden.
Die wichtigsten Anwendungsfälle sind die folgenden:
-
Verwenden Sie die
rds_aurora.limitless_get_last_trace_id()
Funktion, um die eindeutige Ablaufverfolgungs-ID der letzten Abfrage in der aktuellen Sitzung zu ermitteln. Durchsuchen Sie dann die DB-Cluster-Protokollgruppe in Amazon CloudWatch Logs mit dieser Tracing-ID, um alle zugehörigen Protokolle zu finden.Sie können die
log_min_error_statement
Parameterlog_min_messages
und zusammen verwenden, um die Menge der gedruckten Protokolle zu steuern und eine Erklärung zu drucken, die die Tracing-ID enthält. -
Verwenden Sie den
log_min_duration_statement
Parameter, um die Laufzeit zu bestimmen, bei deren Überschreitung alle Abfragen ihre Ausführungsdauer und die Ablaufverfolgungs-ID ausgeben. Diese Laufzeit kann dann in der Protokollgruppe des DB-Clusters unter CloudWatch Logs durchsucht werden, um Engpassknoten zu ermitteln und Optimierungsmaßnahmen zu planen.Der
log_min_duration_statement
Parameter aktiviert die Tracing-ID für alle Knoten, unabhängig von den Werten vonlog_min_messages
und Parametern.log_min_error_statement
Verfolgungs-ID
Im Mittelpunkt dieser Funktion steht eine eindeutige Kennung, die so genannte Tracing-ID. Die Ablaufverfolgungs-ID ist eine 31-stellige Zeichenfolge, die an die STATEMENT Protokollzeilen der SQL Postgre-Protokolle angehängt wird. Sie dient als genaue Kennung für die Korrelation von Protokollen, die sich auf eine bestimmte Abfrageausführung beziehen. Beispiele sind 1126253375719408504000000000011
und 1126253375719408495000000000090
.
Die Ablaufverfolgungs-ID setzt sich wie folgt zusammen:
-
Transaktions-ID — Die ersten 20 Ziffern, die die Transaktion eindeutig identifizieren.
-
Befehls-ID — Die ersten 30 Ziffern, die auf eine einzelne Abfrage innerhalb einer Transaktion hinweisen.
Wenn mehr als 4.294.967.294 Abfragen innerhalb eines expliziten Transaktionsblocks ausgeführt werden, wird der Befehls-Identifier um bis übergeben.
1
In diesem Fall werden Sie durch die folgende Meldung im Postgre-Protokoll benachrichtigt:LOG
SQLwrapping around the tracing ID back to 1 after running 4294967294 (4.2 billion or 2^32-2) queries inside of an explicit transaction block
-
Knotentyp-ID — Die letzte Ziffer, die angibt, ob der Knoten als Koordinator-Router (
1
) oder als Teilnehmerknoten (0
) fungiert.
Die folgenden Beispiele veranschaulichen die Komponenten der Tracing-ID:
-
1126253375719408504000000000011
:-
Transaktions-ID —
1126253375719408504
-
Befehls-ID —
112625337571940850400000000001
gibt den ersten Befehl im Transaktionsblock an -
Knotentyp-ID —
1
gibt einen Koordinator-Router an
-
-
1126253375719408495000000000090
:-
Transaktions-ID —
1126253375719408495
-
Befehlskennung —
112625337571940849500000000009
gibt den neunten Befehl im Transaktionsblock an -
Knotentyp-ID —
0
gibt einen Teilnehmerknoten an
-
Verwenden Sie die Abfrageablaufverfolgung
Führen Sie die folgenden Aufgaben aus, um die Abfrageablaufverfolgung zu verwenden:
-
Stellen Sie sicher, dass die Ablaufverfolgung aktiviert ist.
Sie können dies mit dem folgenden Befehl überprüfen:
SHOW rds_aurora.limitless_log_distributed_trace_id;
Es ist standardmäßig aktiviert (
on
). Wenn es nicht aktiviert ist, stellen Sie es mit dem folgenden Befehl ein:SET rds_aurora.limitless_log_distributed_trace_id = on;
-
Steuern Sie die Menge der gedruckten Protokolle, indem Sie den Schweregrad des Protokolls konfigurieren.
Das Protokollvolumen wird durch den
log_min_messages
Parameter gesteuert. Derlog_min_error_statement
Parameter wird verwendet, um dieSTATEMENT
Zeile mit der Tracing-ID zu drucken. Beide sindERROR
standardmäßig auf eingestellt. Sie können dies mit den folgenden Befehlen überprüfen:SHOW log_min_messages; SHOW log_min_error_statement;
Um den Schweregrad zu aktualisieren und die
STATEMENT
Zeile für die aktuelle Sitzung zu drucken, verwenden Sie die folgenden Befehle mit einem dieser Schweregrade:SET log_min_messages = '
DEBUG5
|DEBUG4
|DEBUG3
|DEBUG2
|DEBUG1
|INFO
|NOTICE
|WARNING
|ERROR
|LOG
|FATAL
|PANIC
'; SET log_min_error_statement = 'DEBUG5
|DEBUG4
|DEBUG3
|DEBUG2
|DEBUG1
|INFO
|NOTICE
|WARNING
|ERROR
|LOG
|FATAL
|PANIC
';Beispielsweise:
SET log_min_messages = 'WARNING'; SET log_min_error_statement = 'WARNING';
-
Aktivieren Sie das Drucken der Ablaufverfolgungs-ID in den Protokollen ab einer bestimmten Laufzeit.
Der
log_min_duration_statement
Parameter kann auf die Mindestlaufzeit der Abfrage geändert werden, bei deren Überschreitung die Abfrage eine Protokollzeile mit der Ausführungsdauer zusammen mit der Ablaufverfolgung im IDs gesamten DB-Cluster ausgibt. Dieser Parameter ist-1
standardmäßig auf gesetzt, was bedeutet, dass er deaktiviert ist. Sie können dies mit dem folgenden Befehl überprüfen:SHOW log_min_duration_statement;
Wenn Sie ihn ändern, werden die Dauer und die Tracing-ID in den Protokollen für jede Abfrage im DB-Cluster
0
gedruckt. Sie können es0
für die aktuelle Sitzung auf einstellen, indem Sie den folgenden Befehl verwenden:SET log_min_duration_statement = 0;
-
Rufen Sie die Tracing-ID ab.
Rufen Sie nach dem Ausführen einer Abfrage (auch innerhalb eines expliziten Transaktionsblocks) die
rds_aurora.limitless_get_last_trace_id
Funktion auf, um die Ablaufverfolgungs-ID des letzten Abfragelaufs abzurufen:SELECT * FROM rds_aurora.limitless_get_last_trace_id();
Diese Funktion gibt die Transaktions-ID und die Befehls-ID zurück. Sie gibt den Knotentypbezeichner nicht zurück.
=> SELECT * FROM customers; customer_id | fname | lname -------------+-------+------- (0 rows) => SELECT * FROM rds_aurora.limitless_get_last_trace_id(); transaction_identifier | command_identifier ------------------------+-------------------------------- 10104661421959001813 | 101046614219590018130000000001 (1 row)
Die Funktion gibt für nicht verteilte Abfragen eine Leerzeile zurück, da sie keine Ablaufverfolgungs-ID haben.
=> SET search_path = public; SET => SELECT * FROM rds_aurora.limitless_get_last_trace_id(); transaction_identifier | command_identifier ------------------------+-------------------- | (1 row)
Anmerkung
Bei VACUUM ANALYZE Und-Abfragen wird die Angabe zur Dauer nicht mit der Ablaufverfolgungs-ID protokolliert. Daher wird die Ablaufverfolgungs-ID
limitless_get_last_trace_id()
nicht zurückgegeben. Wenn ANALYZE es sich bei VACUUM oder um einen Vorgang mit langer Laufzeit handelt, können Sie die folgende Abfrage verwenden, um die Ablaufverfolgungs-ID für diesen Vorgang abzurufen:SELECT * FROM rds_aurora.limitless_stat_activity WHERE distributed_tracing_id IS NOT NULL;
Wenn der Server stoppt, bevor Sie die letzte Ablaufverfolgungs-ID finden können, müssen Sie die SQL Postgre-Protokolle manuell durchsuchen, um die Ablaufverfolgung IDs in den Protokollen von unmittelbar vor dem Ausfall zu finden.
-
Suchen Sie in den DB-Cluster-Protokollen nach der Tracing-ID mithilfe von. CloudWatch
Verwenden Sie CloudWatch Insights, um die Protokollgruppe des DB-Clusters abzufragen, wie in den folgenden Beispielen gezeigt.
-
Fragen Sie nach einer bestimmten Transaktions-ID ab und alle Befehle werden darin ausgeführt:
fields @timestamp, @message | filter @message like /10104661421959001813/ | sort @timestamp desc
-
Abfrage nach einer bestimmten Befehlskennung:
fields @timestamp, @message | filter @message like /101046614219590018130000000001/ | sort @timestamp desc
-
-
Untersuchen Sie alle Protokolle im DB-Cluster, die durch die verteilte Abfrage erstellt wurden.
Beispiele für Protokolle
Die folgenden Beispiele zeigen die Verwendung von Abfrageablaufverfolgung.
Korrelierung von Protokollen für fehleranfällige Abfragen
In diesem Beispiel wird der TRUNCATE
Befehl für die customers
Tabelle ausgeführt, wenn diese Tabelle nicht existiert.
- Ohne Abfrageablaufverfolgung
-
SQLPostgre-Protokolldatei auf dem Koordinator-Router:
2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:DETAIL: relation "public.customers" does not exist 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:CONTEXT: remote SQL command: truncate public.customers; 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:STATEMENT: truncate customers;
SQLPostgre-Protokolldatei auf einem Teilnehmer-Shard:
2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[ 27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[ 27503]:STATEMENT: truncate customers;
Diese Protokolle sind typisch. Ihnen fehlen die genauen Kennungen, die für die einfache Korrelation von Abfragen im gesamten DB-Cluster erforderlich sind.
- Mit Abfrageablaufverfolgung
-
SQLPostgre-Protokolldatei auf dem Koordinator-Router:
2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:DETAIL: relation "public.customers" does not exist 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:CONTEXT: remote SQL command: truncate public.customers; 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:STATEMENT: /* tid = 1126253375719408502700000000011 */ truncate customers;
SQLPostgre-Protokolldatei auf einem Teilnehmer-Shard:
2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:STATEMENT: /* tid = 1126253375719408502700000000010 */ truncate customers;
Bei der Abfrageablaufverfolgung wird jeder Protokollzeile ein 31-stelliger eindeutiger Bezeichner angehängt. Hier
1126253375719408502700000000011
und1126253375719408502700000000010
stellen die Ablaufverfolgung IDs für den Koordinator- bzw. den Teilnehmerknoten dar.-
Transaktions-ID —
11262533757194085027
-
Befehls-ID: —
112625337571940850270000000001
-
Knotentyp-ID — Die letzte Ziffer
1
oder0
steht für einen Koordinator-Router bzw. einen Teilnehmerknoten.
-
Korrelierende Protokolle, um die Laufzeit der Abfrage auf verschiedenen Knoten zu ermitteln
In diesem Beispiel wurde der log_min_duration_statement
Parameter so aktualisiert, dass er 0
die Dauer für alle Abfragen ausgibt.
- Ohne Abfrageablaufverfolgung
-
2024-01-15 07:28:46 UTC:[local]:postgres@postgres_limitless:[178322]:LOG: duration: 12.779 ms statement: select * from customers;
- Mit Abfrageablaufverfolgung
-
SQLPostgre-Protokolldatei auf dem Koordinator-Router:
2024-01-15 07:32:08 UTC:[local]:postgres@postgres_limitless:[183877]:LOG: duration: 12.618 ms statement: /* tid = 0457669566240497088400000000011 */ select * from customers;
SQLPostgre-Protokolldatei auf einem Teilnehmer-Shard:
2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.279 ms statement: /* tid = 0457669566240497088400000000010 */ START TRANSACTION ISOLATION LEVEL READ COMMITTED 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.249 ms parse <unnamed>: SELECT customer_id, fname, lname FROM public.customers 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.398 ms bind <unnamed>/c1: SELECT customer_id, fname, lname FROM public.customers 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.019 ms execute <unnamed>/c1: SELECT customer_id, fname, lname FROM public.customers 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.073 ms statement: /* tid = 0457669566240497088400000000010 */ COMMIT TRANSACTION