Verwenden der Erweiterung log_fdw für den Zugriff auf das DB-Protokoll mit SQL - Amazon Relational Database Service

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.

Verwenden der Erweiterung log_fdw für den Zugriff auf das DB-Protokoll mit SQL

Der für die SQL Postgre-DB-Instance unterstützt die log_fdw Erweiterung, mit der Sie über eine SQL Schnittstelle auf Ihr Datenbank-Engine-Protokoll zugreifen können. Die log_fdw-Erweiterung umfasst zwei neue Funktionen, die das Erstellen von Fremdtabellen für Datenbankprotokolle erleichtern:

  • list_postgres_log_files führt die Dateien im Datenbankprotokollverzeichnis und die Dateigröße in Bytes auf.

  • create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text) erstellt eine Fremdtabelle für die angegebene Datei in der aktuellen Datenbank.

Alle durch log_fdw erstellten Funktionen gehören rds_superuser. Mitglieder der rds_superuser-Rolle können anderen Datenbankbenutzern Zugriff auf diese Funktionen gewähren.

Standardmäßig werden die Protokolldateien von im Format stderr (Standardfehler) generiert, wie im log_destination Parameter angegeben. Für diesen Parameter gibt es nur zwei Optionen: stderr und csvlog (kommagetrennte Werte,CSV). Wenn Sie die csvlog Option zum Parameter hinzufügen, RDS generiert Amazon stderr sowohl als auch csvlog Protokolle. Dies kann die Speicherkapazität Ihres DB-Clusters beeinträchtigen. Daher müssen Sie sich der anderen Parameter bewusst sein, die sich auf die Protokollbehandlung auswirken. Weitere Informationen finden Sie unter Festlegen des Protokollziels (stderr, csvlog).

Ein Vorteil der Generierung von csvlog-Protokollen ist, dass Sie mit der log_fdw-Erweiterung Fremdtabellen erstellen können, bei denen die Daten ordentlich in verschiedene Spalten aufgeteilt sind. Dazu muss Ihre Instance einer benutzerdefinierten DB-Parametergruppe zugeordnet sein, damit Sie die Einstellung für log_destination ändern können. Weitere Informationen zur Vorgehensweise finden Sie unter Arbeiten mit Parametern auf der DB-Instance von RDS for PostgreSQL.

Im folgenden Beispiel wird angenommen, dass der log_destination-Parameter cvslog enthält.

So verwenden Sie die Erweiterung log_fdw:

  1. Installieren Sie die log_fdw-Erweiterung.

    postgres=> CREATE EXTENSION log_fdw;
CREATE EXTENSION

  2. Erstellen Sie den Protokollserver als Fremddaten-Wrapper.

    postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw;
CREATE SERVER

  3. Wählen Sie aus einer Liste an Protokolldateien "alle" aus.

    postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1;

    Beispiel-Antwort.

              file_name           | file_size_bytes
------------------------------+-----------------
 postgresql.log.2023-08-09-22.csv |            1111
 postgresql.log.2023-08-09-23.csv |            1172
 postgresql.log.2023-08-10-00.csv |            1744
 postgresql.log.2023-08-10-01.csv |            1102
(4 rows)

  4. Erstellen Sie eine Tabelle mit einer einzigen 'log_entry'-Spalte für die ausgewählte Datei.

    postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log',
     'log_server', 'postgresql.log.2023-08-09-22.csv');

    Die Antwort liefert keine weiteren Details außer, dass die Tabelle jetzt existiert.

    -----------------------------------
(1 row)

  5. Wählen Sie ein Beispiel der Protokolldatei aus. Mit dem folgenden Code werden die Protokollzeit und die Fehlermeldungsbeschreibung abgerufen.

    postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1;

    Beispiel-Antwort.

                 log_time             |                                  message
----------------------------------+---------------------------------------------------------------------------
Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr
Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC
Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0
Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE
Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578
Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0
Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1
(7 rows)