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.
# Überwachen von Amazon Aurora-Protokolldateien
Jede RDS-Datenbank-Engine generiert Protokolle, auf die Sie für die Überwachung und Fehlerbehebung zugreifen können. Der Typ der Protokolle hängt von Ihrer Datenbank-Engine ab.
Sie können auf Datenbankprotokolle für DB-Instance mithilfe der AWS-Managementkonsole, der AWS Command Line Interface (AWS CLI) oder der Amazon-RDS-API zugreifen. Sie können Transaktionsprotokolle nicht anzeigen, ansehen oder herunterladen.
**Anmerkung**
In einigen Fällen enthalten Protokolle versteckte Daten. Daher kann es sein, dass das AWS-Managementkonsole den Inhalt in einer Protokolldatei anzeigt, aber die Protokolldatei ist möglicherweise leer, wenn Sie sie herunterladen.
**Topics**
+ [Anzeigen und Auflisten von Datenbank-Protokolldateien](USER_LogAccess.Procedural.Viewing.md)
+ [Herunterladen einer Datenbank-Protokolldatei](USER_LogAccess.Procedural.Downloading.md)
+ [Überwachen einer Datenbank-Protokolldatei](USER_LogAccess.Procedural.Watching.md)
+ [Veröffentlichen von Datenbankprotokollen in Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md)
+ [Lesen der Protokolldateiinhalte mit REST](DownloadCompleteDBLogFile.md)
+ [Aurora MySQL-Datenbank-Logdateien](USER_LogAccess.Concepts.MySQL.md)
+ [Aurora PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md)
# Anzeigen und Auflisten von Datenbank-Protokolldateien
Sie können Datenbank-Protokolldateien für Ihre Amazon-Aurora-DB-Engine mithilfe der AWS-Managementkonsole anzeigen. Sie können auflisten, welche Protokolldateien zum Herunterladen bzw. Überwachen verfügbar sind, indem Sie die AWS CLI oder die Amazon-RDS-API verwenden.
**Anmerkung**
Sie können die Protokolldateien für Aurora Serverless v1-DB-Cluster in der RDS-Konsole nicht anzeigen. Sie können sie jedoch in der Amazon-CloudWatch-Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) ansehen.
## Konsole
**So zeigen Sie eine Datenbank-Protokolldatei an**
1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus.
1. Wählen Sie den Namen der DB-Instance, welche die anzuzeigende Protokolldatei enthält.
1. Wählen Sie die Registerkarte **Logs & events** (Protokolle und Ereignisse).
1. Scrollen Sie nach unten bis zum Abschnitt **Protokolle**.
1. (Optional) Geben Sie einen Suchbegriff ein, um Ihre Ergebnisse zu filtern.
Im folgenden Beispiel werden Protokolle aufgeführt, die nach dem Text **error** gefiltert wurden.
![\[DB-Protokolle auflisten\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/ListEventsAMS.png)
1. Wählen Sie das gewünschte Protokoll und dann **View** (Anzeigen) aus.
## AWS CLI
Um die verfügbaren Datenbank-Protokolldateien für eine DB-Instance aufzulisten, verwenden Sie den AWS CLI-Befehl [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html).
Das folgende Beispiel gibt eine Liste von Protokolldateien für eine DB-Instance namens zurüc `my-db-instance`.
**Example**
```
1. aws rds describe-db-log-files --db-instance-identifier my-db-instance
```
## RDS-API
Um die verfügbaren Datenbank-Protokolldateien für eine DB-Instance aufzulisten, verwenden Sie die Amazon-RDS-API-Aktion [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html).
# Herunterladen einer Datenbank-Protokolldatei
Sie können die AWS-Managementkonsole, AWS CLI oder API zum Herunterladen einer Datenbank-Protokolldatei verwenden.
## Konsole
**So laden Sie eine Datenbank-Protokolldatei herunter**
1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus.
1. Wählen Sie den Namen der DB-Instance, welche die anzuzeigende Protokolldatei enthält.
1. Wählen Sie die Registerkarte **Logs & events** (Protokolle und Ereignisse).
1. Scrollen Sie nach unten bis zum Abschnitt **Protokolle**.
1. Klicken Sie im Bereich **Protokolle** auf die Schaltfläche neben dem gewünschten Protokoll und wählen Sie **Herunterladen**.
1. Öffnen Sie das Kontextmenü (rechte Maustaste) für den bereitgestellten Link und wählen Sie **Save Link As** (Link speichern unter) aus. Geben Sie den Speicherort für die Protokolldatei ein und klicken Sie dann auf **Speichern**.
![\[Anzeigen der Protokolldatei\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/log_download2.png)
## AWS CLI
Verwenden Sie den AWS CLI-Befehl [https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html](https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html), um eine Datenbank-Protokolldatei herunterzuladen. Standardmäßig lädt dieser Befehl nur den neuesten Teil einer Protokolldatei herunter. Sie können jedoch eine ganze Datei herunterladen, indem Sie den Parameter angebe `--starting-token 0`.
Das folgende Beispiel zeigt, wie man den Inhalt einer Protokolldatei namens *log/ERROR.4* herunterlädt und in einer lokalen Datei namens *errorlog.txt* speichert.
**Example**
Für Linux, macOS oder Unix:
```
1. aws rds download-db-log-file-portion \
2. --db-instance-identifier myexampledb \
3. --starting-token 0 --output text \
4. --log-file-name log/ERROR.4 > errorlog.txt
```
Für Windows:
```
1. aws rds download-db-log-file-portion ^
2. --db-instance-identifier myexampledb ^
3. --starting-token 0 --output text ^
4. --log-file-name log/ERROR.4 > errorlog.txt
```
## RDS-API
Verwenden Sie die Amazon-RDS-API-Aktion [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html), um eine Datenbank-Protokolldatei herunterzuladen.
# Überwachen einer Datenbank-Protokolldatei
Das Überwachen einer Datenbank-Protokolldatei entspricht dem Abrufen der Datei auf einem UNIX- oder Linux-System. Sie können eine Protokolldatei mithilfe der AWS-Managementkonsole überwachen. RDS aktualisiert das Ende des Protokolls alle 5 Sekunden.
**So überwachen Sie eine Datenbank-Protokolldatei**
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus.
1. Wählen Sie den Namen der DB-Instance, welche die anzuzeigende Protokolldatei enthält.
1. Wählen Sie die Registerkarte **Logs & events** (Protokolle und Ereignisse).
![\[Wählen Sie die Registerkarte Logs & events (Protokolle und Ereignisse)\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_logsEvents.png)
1. Wählen Sie im Abschnitt **Protokolle** eine Protokolldatei und wählen Sie dann **Watch (Beobachten)**.
![\[Wählen Sie ein Protokoll\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch.png)
RDS zeigt das Ende des Protokolls an, wie im folgenden MySQL-Beispiel.
![\[Ende einer Protokolldatei\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch_content.png)
# Veröffentlichen von Datenbankprotokollen in Amazon CloudWatch Logs
In einer On-Premises-Datenbank befinden sich die Datenbankprotokolle im Dateisystem. Amazon RDS bietet keinen Host-Zugriff auf die Datenbankprotokolle im Dateisystem Ihres DB-Clusters. Aus diesem Grund ermöglicht Amazon RDS das Exportieren von Datenbankprotokollen in [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). Mit CloudWatch Logs können Sie Echtzeitanalysen der Protokolldaten durchführen. Sie können die Daten auch in einem Speicher mit hoher Beständigkeit speichern und mit dem CloudWatch-Logs-Agenten verwalten.
**Topics**
+ [Überblick über die RDS-Integration mit CloudWatch Logs](#rds-integration-cw-logs)
+ [Entscheiden, welche Protokolle in CloudWatch Logs veröffentlicht werden](#engine-specific-logs)
+ [Angeben der Protokolle, die in CloudWatch Logs veröffentlicht werden sollen](#integrating_cloudwatchlogs.configure)
+ [Suchen und Filtern Ihrer Protokolle in CloudWatch Logs](#accessing-logs-in-cloudwatch)
## Überblick über die RDS-Integration mit CloudWatch Logs
In CloudWatch Logs ist ein *Protokollstream* eine Abfolge von Protokollereignissen, die dieselbe Quelle nutzen. Jede separate Quelle für Protokolle in CloudWatch Logs bildet einen separaten Protokollstream. Eine *Protokollgruppe* ist eine Gruppe von Protokollstreams, die dieselben Einstellungen für die Aufbewahrung, Überwachung und Zugriffskontrolle besitzen.
Amazon Aurora streamt kontinuierlich die Protokolldatensätze Ihres DB-Clusters in eine Protokollgruppe. Sie haben z. B. eine Protokollgruppe `/aws/rds/cluster/cluster_name/log_type` für jeden Protokolltyp, den Sie veröffentlichen. Diese Protokollgruppe befindet sich in derselben AWS-Region wie die Datenbank-Instance, die das Protokoll erzeugt.
AWS bewahrt Protokolldaten, die in CloudWatch Logs veröffentlicht wurden, auf unbegrenzte Dauer auf, wenn keine Aufbewahrungsfrist festgelegt wird. Weitere Informationen finden Sie unter [Ändern der Aufbewahrungszeit von Protokolldaten in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention).
## Entscheiden, welche Protokolle in CloudWatch Logs veröffentlicht werden
Jede RDS-Datenbank-Engine unterstützt einen eigene Gruppe von Protokollen. Lesen Sie die folgenden Themen, um mehr über die Optionen für Ihre Datenbank-Engine zu erfahren:
+ [Veröffentlichen von Amazon Aurora MySQL-Protokollen in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md)
+ [Veröffentlichen von Aurora-PostgreSQL-Protokollen in Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md)
## Angeben der Protokolle, die in CloudWatch Logs veröffentlicht werden sollen
Sie geben an, welche Protokolle in der Konsole veröffentlicht werden sollen. Stellen Sie sicher, dass eine servicegebundene Rolle in AWS Identity and Access Management (IAM) vorhanden ist. Weitere Informationen zu serviceverknüpften Rollen finden Sie unter [Verwenden von serviceverknüpften Rollen für Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md).
**So geben Sie die Protokolle an, die veröffentlicht werden sollen**
1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus.
1. Führen Sie eine der folgenden Aufgaben aus:
+ Wählen Sie **Create database (Datenbank erstellen)** aus.
+ Wählen Sie eine Datenbank in der Liste und dann **Modify** (Ändern) aus.
1. Wählen Sie in **Logs exports** (Protokollexporte) die Protokolle aus, die veröffentlicht werden sollen.
Das folgende Beispiel spezifiziert das Auditprotokoll, die Fehlerprotokolle, das allgemeine Protokoll, das Instance-Protokoll, das Fehlerprotokoll für die IAM-Datenbankauthentifizierung und das Protokoll für langsame Abfragen für einen DB-Cluster von Aurora MySQL .
## Suchen und Filtern Ihrer Protokolle in CloudWatch Logs
Sie können mithilfe der Konsole von CloudWatch Logs nach den Protokolleinträgen suchen, die ein bestimmtes Kriterium erfüllen. Sie können auf die Protokolle entweder über die RDS-Konsole, die Sie zur CloudWatch-Logs-Konsole führt, oder direkt über die CloudWatch-Logs-Konsole zugreifen.
**So suchen Sie Ihre RDS-Protokolle mithilfe der RDS-Konsole**
1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus.
1. Wählen Sie ein DB-Cluster oder eine DB-Instance aus.
1. Wählen Sie **Konfiguration**.
1. Wählen Sie unter **Published logs** (Veröffentlichte Protokolle) das Datenbankprotokoll aus, das Sie anzeigen möchten.
**So suchen Sie Ihre RDS-Protokolle mithilfe der CloudWatch-Logs-Konsole**
1. Öffnen Sie die CloudWatch-Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich **Log groups (Protokollgruppen)** aus.
1. Geben Sie im Filterfeld **/aws/rds** ein.
1. Wählen Sie für **Log Groups** den Namen der Protokollgruppe mit dem Protokoll-Stream aus, nach dem gesucht werden soll.
1. Wählen Sie für **Log Streams** den Namen des zu suchenden Protokoll-Streams.
1. Geben Sie unter **Protokollereignisse** die zu verwendende Filtersyntax ein.
Weitere Informationen finden Sie unter [Suchen und Filtern von Protokolldaten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) im *Benutzerhandbuch von Amazon CloudWatch Logs*. Ein Blog-Tutorial zur Überwachung von RDS-Protokollen finden Sie unter [Erstellen Sie proaktive Datenbanküberwachung für Amazon RDS mit Amazon CloudWatch Logs, AWS Lambda und Amazon SNS](https://aws.amazon.com/blogs/database/build-proactive-database-monitoring-for-amazon-rds-with-amazon-cloudwatch-logs-aws-lambda-and-amazon-sns/).
# Lesen der Protokolldateiinhalte mit REST
Amazon RDS bietet einen REST-Endpunkt, der den Zugriff auf die Protokolldateien der DB-Instance ermöglicht. Dies ist nützlich, wenn Sie eine Anwendung schreiben müssen, um Amazon-RDS-Protokolldateiinhalte zu streamen.
Die Syntax lautet wie folgt:
```
GET /v13/downloadCompleteLogFile/DBInstanceIdentifier/LogFileName HTTP/1.1
Content-type: application/json
host: rds.region.amazonaws.com
```
Die folgenden Parameter sind erforderlich:
+ `DBInstanceIdentifier`: der Name der DB-Instance, welche die Protokolldatei enthält, die Sie herunterladen möchten.
+ `LogFileName`: der Name der Protokolldatei, die heruntergeladen werden soll.
Die Antwort enthält die Inhalte der angeforderten Protokolldatei als Stream zurück.
Im folgenden Beispiel wird die Protokolldatei namens *log/ERROR.6* für die DB-Instance namens *sample-sql* in der Region *us-west-2* heruntergeladen.
```
GET /v13/downloadCompleteLogFile/sample-sql/log/ERROR.6 HTTP/1.1
host: rds.us-west-2.amazonaws.com
X-Amz-Security-Token: AQoDYXdzEIH//////////wEa0AIXLhngC5zp9CyB1R6abwKrXHVR5efnAVN3XvR7IwqKYalFSn6UyJuEFTft9nObglx4QJ+GXV9cpACkETq=
X-Amz-Date: 20140903T233749Z
X-Amz-Algorithm: AWS4-HMAC-SHA256
X-Amz-Credential: AKIADQKE4SARGYLE/20140903/us-west-2/rds/aws4_request
X-Amz-SignedHeaders: host
X-Amz-Content-SHA256: e3b0c44298fc1c229afbf4c8996fb92427ae41e4649b934de495991b7852b855
X-Amz-Expires: 86400
X-Amz-Signature: 353a4f14b3f250142d9afc34f9f9948154d46ce7d4ec091d0cdabbcf8b40c558
```
Wenn Sie eine nicht vorhandene DB-Instance angeben, besteht die Antwort aus dem folgenden Fehler:
+ `DBInstanceNotFound`: `DBInstanceIdentifier` bezieht sich nicht auf eine vorhandene DB-Instance. (HTTP-Statuscode: 404)
# Aurora MySQL-Datenbank-Logdateien
Sie können die Aurora MySQL-Protokolle direkt über die Amazon RDS-Konsole, die Amazon RDS-API AWS CLI, oder überwachen AWS SDKs. Sie können auf MySQL-Protokolle auch direkt zugreifen, indem Sie die Protokolle in eine Datenbank-Tabelle in der Hauptdatenbank weiterleiten und diese Tabelle abfragen. Mit dem Dienstprogramm "mysqlbinlog" können Sie ein binäres Protokoll herunterladen.
Weitere Informationen zum Anzeigen und Herunterladen von dateibasierten Datenbankprotokollen finden Sie unter [Überwachen von Amazon Aurora-Protokolldateien](USER_LogAccess.md).
**Topics**
+ [Überblick über Aurora-MySQL-Datenbankprotokolle](USER_LogAccess.MySQL.LogFileSize.md)
+ [Senden der Aurora-MySQL-Protokollausgabe an Tabellen](Appendix.MySQL.CommonDBATasks.Logs.md)
+ [Konfiguration von Aurora MySQL für Single-AZ-Datenbanken](USER_LogAccess.MySQL.BinaryFormat.md)
+ [Zugriff auf MySQL-Binärprotokolle](USER_LogAccess.MySQL.Binarylog.md)
# Überblick über Aurora-MySQL-Datenbankprotokolle
Sie können die folgenden Arten von Aurora-MySQL-Protokolldateien überwachen:
+ Fehler-log
+ Slow-Query-Protokoll
+ Allgemeines Protokoll
+ Prüfungsprotokoll
+ Instance-Protokoll
+ Fehlerprotokoll zur IAM-Datenbankauthentifizierung
Das Aurora-MySQL-Fehlerprotokoll wird standardmäßig generiert. Sie können die langsamen Abfrage- und allgemeinen Protokolle generieren, indem Sie Parameter in Ihrer DB-Parametergruppe festlegen.
**Topics**
+ [Aurora-MySQL-Fehlerprotokolle](#USER_LogAccess.MySQL.Errorlog)
+ [Aurora-MySQL-Protokolle für langsame Abfragen und allgemeine Protokolle](#USER_LogAccess.MySQL.Generallog)
+ [Aurora-MySQL-Prüfprotokoll](#ams-audit-log)
+ [Instance-Protokoll von Aurora MySQL](#ams-instance-log)
+ [Protokollrotation und -aufbewahrung für Aurora MySQL](#USER_LogAccess.AMS.LogFileSize.retention)
+ [Aurora MySQL-Protokolle auf Amazon CloudWatch Logs veröffentlichen](#USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs)
## Aurora-MySQL-Fehlerprotokolle
Aurora MySQL schreibt Fehler in die `mysql-error.log`-Datei. An den Namen jeder Protokolldatei wird die Stunde ihrer Erstellung (in UTC) angefügt. Die Protokolldateien verfügen auch über einen Zeitstempel, anhand dessen Sie feststellen können, wann die Protokolleinträge geschrieben wurden.
Aurora MySQL schreibt das Fehlerprotokoll nur beim Startup, Herunterfahren und beim Auftreten von Fehlern. Eine DB-Instance kann Stunden oder Tage lang laufen, ohne dass neue Einträge in das Fehlerprotokoll geschrieben werden. Wenn Sie keine neuen Einträge sehen, sind im Server keine Fehler aufgetreten, die zu einem Eintrag in das Protokoll führen würden.
Konstruktionsbedingt werden die Fehlerprotokolle gefiltert, sodass nur unerwartete Ereignisse wie Fehler angezeigt werden. Die Fehlerprotokolle enthalten jedoch auch einige zusätzliche Datenbankinformationen, z. B. den Abfragefortschritt, die nicht angezeigt werden. Daher kann die Größe der Fehlerprotokolle auch ohne tatsächliche Fehler aufgrund laufender Datenbankaktivitäten zunehmen. Und obwohl Sie in den Fehlerprotokollen möglicherweise eine bestimmte Größe in Byte oder Kilobyte sehen AWS-Managementkonsole, haben sie möglicherweise 0 Byte, wenn Sie sie herunterladen.
Aurora MySQL schreibt `mysql-error.log` alle 5 Minuten auf die Festplatte. Es fügt den Inhalt des Protokolls `mysql-error-running.log` an.
Aurora MySQL rotiert die Datei `mysql-error-running.log` stündlich.
**Anmerkung**
Der Aufbewahrungszeitraum für das Protokoll ist zwischen Amazon RDS und unterschiedlich Aurora.
## Aurora-MySQL-Protokolle für langsame Abfragen und allgemeine Protokolle
Das Slow-Query-Protokoll von Aurora MySQL und das allgemeine Protokoll können in eine Datei oder in eine Datenbanktabelle geschrieben werden. Legen Sie dazu die Parameter in Ihrer DB-Parametergruppe fest. Weitere Informationen zum Erstellen und Ändern einer DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). Sie müssen diese Parameter festlegen, bevor Sie das Protokoll für langsame Abfragen oder das allgemeine Protokoll in der Amazon RDS-Konsole oder mithilfe der Amazon RDS-API, Amazon RDS-CLI oder anzeigen können AWS SDKs.
Sie können Aurora-MySQL-Protokolle mithilfe der Parameter in dieser Liste kontrollieren:
+ `slow_query_log` Um das Slow-Query-Protokoll zu erstellen, auf 1 setzen. Der Standardwert ist 0.
+ `general_log` Um das allgemeine Protokoll zu erstellen, auf 1 setzen. Der Standardwert ist 0.
+ `long_query_time`: Damit vermieden wird, dass schnell ausgeführte Abfragen im Slow-Query-Protokoll aufgenommen werden, legen Sie die kürzeste Laufzeit für eine zu protokollierende Abfrage in Sekunden fest. Der Standardwert liegt bei 10 Sekunden, der Mindestwert bei 0. Wenn log\$1output = FILE, können Sie einen Gleitkommawert angeben, der die Mikrosekundenauflösung festlegt. Wenn log\$1output = TABLE, können Sie einen Ganzzahlwert angeben, der die Sekundenauflösung festlegt. Nur Abfragen, deren Laufzeit den `long_query_time`-Wert übersteigt, werden im Protokoll aufgenommen. Wenn Sie beispielsweise `long_query_time` auf 0,1 setzen, verhindert dies Einträge von allen Abfragen, die weniger als 100 Millisekunden lang ausgeführt werden.
+ `log_queries_not_using_indexes`: Um alle Abfragen, die keinen Index für das Slow-Query-Protokoll verwenden im Protokoll aufzunehmen, auf 1 setzen. Abfragen, die keinen Index verwenden, werden protokolliert, auch wenn ihre Laufzeit niedriger als der Wert des Parameters `long_query_time` ist. Der Standardwert ist 0.
+ `log_output option`: Sie können eine der folgenden Optionen für den `log_output`-Parameter festlegen.
+ **TABLE** – schreibt allgemeine Abfragen in die `mysql.general_log`-Tabelle und langsame Abfragen in die `mysql.slow_log`-Tabelle.
+ **FILE**– schreibt Protokolle allgemeiner und langsamer Abfragen in das Dateisystem.
+ **NONE**– Die Protokollierung ist deaktiviert.
Bei Aurora-MySQL-Version 2 und 3 ist der Standardwert für `log_output` `FILE`.
Damit langsame Abfragedaten in Amazon CloudWatch Logs angezeigt werden, müssen die folgenden Bedingungen erfüllt sein:
+ CloudWatch Protokolle müssen so konfiguriert sein, dass sie langsame Abfrageprotokolle enthalten.
+ `slow_query_log` muss aktiviert sein.
+ muss `log_output` auf `FILE` festgelegt sein.
+ Die Abfrage muss länger dauern als die für `long_query_time` konfigurierte Zeit.
Weitere Informationen zu den Slow-Query- und allgemeinen Protokollen finden Sie in den folgenden Themen in der MySQL-Dokumentation:
+ [Das Slow-Query-Protokoll](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html)
+ [Das allgemeine Abfrageprotokoll](https://dev.mysql.com/doc/refman/8.0/en/query-log.html)
## Aurora-MySQL-Prüfprotokoll
Die Auditprotokollierung für Aurora MySQL heißt Advanced Auditing. Zum Aktivieren von Advanced Auditing legen Sie bestimmte DB-Cluster-Parameter fest. Weitere Informationen finden Sie unter [Verwenden von Advanced Auditing in einem Amazon Aurora MySQL DB-Cluster](AuroraMySQL.Auditing.md).
## Instance-Protokoll von Aurora MySQL
Aurora erstellt eine separate Protokolldatei für DB-Instances, bei denen die Auto-Pause-Funktion aktiviert ist. In der Datei instance.log werden alle Gründe aufgezeichnet, warum diese DB-Instances nicht wie erwartet pausiert werden konnten. Weitere Informationen zum Verhalten von Instance-Protokolldateien und zur Auto-Pause-Funktion von Aurora finden Sie unter [Monitoring Aurora Serverless v2 pause and resume activity](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log).
## Protokollrotation und -aufbewahrung für Aurora MySQL
Wenn die Protokollierung aktiviert ist, rotiert oder löscht Amazon Aurora Protokolldateien in regelmäßigen Intervallen. Dies ist eine Vorsichtsmaßnahme, um möglichst zu vermeiden, dass eine umfangreiche Protokolldatei die Datenbanknutzung blockiert oder die Leistung beeinträchtigt. Aurora MySQL behandelt Rotation und Löschen wie folgt:
+ Die Dateigrößen der Aurora-MySQL-Fehlerprotokolle sind auf maximal 15 Prozent des zugewiesenen Speicherplatzes für eine DB-Instance beschränkt. Um diesen Schwellenwert einzuhalten, werden die Protokolle automatisch stündlich gedreht. Aurora MySQL entfernt Protokolle nach 30 Tagen oder wenn 15 % des Festplattenspeichers belegt sind. Wenn die kombinierte Größe der Protokolle nach dem Löschen von alten Protokolldateien den Schwellwert überschreitet, werden die ältesten Protokolldateien gelöscht, bis die Größe den Schwellwert nicht mehr überschreitet.
+ Aurora MySQL entfernt die Audit-, allgemeinen, langsamen Abfrage-Protokolle entweder nach 24 Stunden oder wenn 15 % des Speichers verbraucht wurden.
+ Wenn die `FILE`-Protokollierung aktiviert ist, werden allgemeine Protokolldateien und Protokolldateien für langsame Abfragen stündlich geprüft und Protokolldateien, die älter als 24 Stunden sind, werden gelöscht. In einigen Fällen kann die Größe der verbleibenden kombinierten Protokolldatei nach dem Löschen die Schwelle von 15 % des lokalen Speicherplatzes für eine DB-Instance überschreiten. In diesen Fällen werden die ältesten Protokolldateien gelöscht, bis die Größe den Schwellenwert nicht mehr überschreitet.
+ Wenn die `TABLE`-Protokollierung aktiviert ist, werden Protokolltabellen nicht rotiert oder gelöscht. Protokolltabellen werden abgeschnitten, wenn die Größe aller kombinierten Protokolle zu groß ist. Sie können die Ereigniskategorie `low storage` abonnieren, um Benachrichtigungen zu erhalten, wenn Protokolltabellen manuell rotiert oder gelöscht werden sollen, um Speicherplatz freizugeben. Weitere Informationen finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md).
Sie können die `mysql.general_log`-Tabelle manuell rotieren, indem Sie die Prozedur `mysql.rds_rotate_general_log` aufrufen. Sie können die `mysql.slow_log`-Tabelle rotieren, wenn Sie die Prozedur `mysql.rds_rotate_slow_log` aufrufen.
Wenn Sie Protokolldateien manuell rotieren, wird die aktuelle Protokolltabelle in eine Sicherungsprotokolltabelle kopiert und die Einträge in der aktuellen Protokolltabelle werden entfernt. Sofern bereits eine Sicherungsprotokolltabelle vorhanden ist, wird diese gelöscht, bevor die aktuelle Protokolltabelle ins Backup kopiert wird. Sie können die Sicherungsprotokolltabelle abfragen, wenn dies nötig ist. Die Backup-Protokolltabelle für die `mysql.general_log`-Tabelle ist als `mysql.general_log_backup` benannt. Die Backup-Protokolltabelle für die `mysql.slow_log`-Tabelle ist als `mysql.slow_log_backup` benannt.
+ Die Aurora-MySQL-Überwachungsprotokolle werden rotiert, wenn die Dateigröße 100 MB erreicht, und nach 24 Stunden entfernt.
+ Amazon RDS rotiert Fehlerprotokolldateien für die IAM-Datenbankauthentifizierung, die größer als 10 MB sind. Amazon RDS entfernt Fehlerprotokolldateien für die IAM-Datenbankauthentifizierung, die älter als fünf Tage oder größer als 100 MB sind.
Um mit den Protokollen von der Amazon RDS-Konsole, der Amazon RDS-API, der Amazon RDS-CLI oder zu arbeiten AWS SDKs, setzen Sie den `log_output` Parameter auf FILE. Diese Protokolldateien werden wie das Aurora-MySQL-Fehlerprotokoll stündlich rotiert. Die Protokolldateien, die während der vorherigen 24 Stunden angelegt wurden, werden aufbewahrt. Beachten Sie, dass der Aufbewahrungszeitraum bei Amazon RDS und Aurora jeweils unterschiedlich ist.
## Aurora MySQL-Protokolle auf Amazon CloudWatch Logs veröffentlichen
Sie können Ihren Aurora MySQL-DB-Cluster so konfigurieren, dass Protokolldaten in einer Protokollgruppe in Amazon CloudWatch Logs veröffentlicht werden. Mit CloudWatch Logs können Sie eine Echtzeitanalyse der Protokolldaten durchführen und diese CloudWatch zum Erstellen von Alarmen und zum Anzeigen von Metriken verwenden. Sie können CloudWatch Logs verwenden, um Ihre Protokolldatensätze in einem äußerst langlebigen Speicher zu speichern. Weitere Informationen finden Sie unter [Veröffentlichen von Amazon Aurora MySQL-Protokollen in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md).
# Senden der Aurora-MySQL-Protokollausgabe an Tabellen
Sie können die allgemeinen und Slow-Query-Protokolle an Tabellen in der DB-Instance weiterleiten, indem Sie eine DB-Parametergruppe erstellen und den `log_output`-Serverparameter auf `TABLE` setzen. Allgemeine Abfragen werden anschließend in der `mysql.general_log`-Tabelle und Slow-Queries in der`mysql.slow_log`-Tabelle protokolliert. Sie können die Tabellen abfragen, um auf Protokollinformationen zuzugreifen. Durch Aktivieren dieser Protokollierung wird die Datenmenge erhöht, die in die Datenbank geschrieben wird, was die Performance beeinträchtigen kann.
Das allgemeine Protokoll und das Slow-Query-Protokoll sind standardmäßig deaktiviert. Um die Protokollierung in Tabellen zu aktivieren, müssen Sie auch die Serverparameter `general_log` und `slow_query_log` auf `1` setzen.
Protokolltabellen wachsen stetig, bis die entsprechenden Protokollierungsaktivitäten ausgeschaltet werden, indem der entsprechende Parameter auf gesetzt wir `0`. Mit der Zeit sammelt sich häufig eine große Datenmenge an und belegt einen beträchtlichen Anteil Ihres zugeteilten Speicherplatzes. Amazon Aurora erlaubt Ihnen nicht, die Protokolltabellen zu kürzen, aber Sie können ihre Inhalte verschieben. Beim Rotieren einer Tabelle wird deren Inhalt in einer Sicherungstabelle gespeichert, und anschließend wird eine neue leere Protokolldatei angelegt. Sie können Protokolltabellen mithilfe der folgenden Befehlszeilenprozeduren manuell rotieren, wobei die Eingabeaufforderung mit bezeichnet is `PROMPT>`:
```
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
```
Um alte Daten komplett zu entfernen und den Speicherplatz zurückzugewinnen, rufen Sie die entsprechende Prozedur zweimal nacheinander auf.
# Konfiguration von Aurora MySQL für Single-AZ-Datenbanken
Das *Binärprotokoll* ist eine Reihe von Protokolldateien, die Informationen zu Datenänderungen enthalten, die an einer Aurora-MySQL-Server-Instance vorgenommen wurden. Das Binärprotokoll enthält Informationen wie die folgenden:
+ Ereignisse, die Datenbankänderungen wie Tabellenerstellungen oder Zeilenänderungen beschreiben
+ Informationen über die Dauer jeder Anweisung, durch die Daten aktualisiert wurden
+ Ereignisse für Anweisungen, durch die Daten aktualisieren werden hätten können, aber nicht wurden
Das binäre Protokoll zeichnet Anweisungen auf, die während der Replikation gesendet werden. Es ist auch für einige Wiederherstellungsvorgänge erforderlich. Weitere Informationen finden Sie unter [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) in der MySQL-Dokumentation.
Binäre Protokolle sind nur von der primären DB-Instance aus zugänglich, nicht von den Replicas.
MySQL in Amazon Aurora unterstützt die binären Protokollformate *row-based*, *statement-based* und *mixed*. Wir empfehlen gemischt, sofern Sie kein spezifisches Format des Binärprotokolls benötigen. Einzelheiten zu den verschiedenen Aurora-MySQL-Binärprotokollformaten finden Sie in der MySQL-Dokumentation unter [Binary Logging Formats](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html).
Zur Verwendung der Replikation ist das binäre Protokollierungsformat wichtig, da es den Datensatz der Datenänderungen bestimmt, der in der Quelle aufgezeichnet und an die Replikationsziele gesendet wird. Weitere Informationen über Vor- und Nachteile verschiedener binärer Protokollierungsformate finden Sie unter [Vorteile und Nachteile einer auf Anweisungen und einer auf Zeilen basierenden Replikation](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) in der MySQL-Dokumentation.
**Wichtig**
Mit MySQL 8.0.34 hat MySQL den Parameter `binlog_format` als veraltet eingestuft. In späteren MySQL-Versionen plant MySQL, den Parameter zu entfernen und nur die zeilenbasierte Replikation zu unterstützen. Daher empfehlen wir, für neue MySQL-Replikationseinrichtungen die zeilenbasierte Protokollierung zu verwenden. Weitere Informationen finden Sie unter [binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format) in der MySQL-Dokumentation.
Die MySQL-Versionen 8.0 und 8.4 akzeptieren den Parameter `binlog_format`. Bei Verwendung dieses Parameters gibt MySQL eine Warnmeldung zur Veralterung aus. In einer zukünftigen Hauptversion wird MySQL den Parameter `binlog_format` entfernen.
Die anweisungsbasierte Replikation kann zu Inkonsistenzen zwischen dem Quell-DB--Cluster und einem Lese-Replikat führen. Weitere Informationen finden Sie unter [ Determination of Safe and Unsafe Statements in Binary Logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) in der MySQL-Dokumentation.
Durch die Aktivierung der binären Protokollierung wird die Anzahl der I/O Festplattenschreibvorgänge im erhöht. Sie können die IOPS-Nutzung mit der `` `VolumeWriteIOPs` CloudWatch Metrik überwachen.
**Stellen Sie das MySQL-binäres-Protokollierungsformat wie folgt ein:**
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Parameter groups (Parametergruppen)** aus.
1. Wählen Sie die zu ändernde DB-Cluster-Parametergruppe aus, die dem DB-Cluster zugeordnet ist.
Eine Standard-Parametergruppe kann nicht modifiziert werden. Erstellen Sie eine neue Parametergruppe und ordnen Sie diese dem DB--Cluster zu, wenn der DB--Cluster eine Standardparametergruppe verwendet.
Weitere Informationen zu Parametergruppen finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md).
1. Wählen Sie unter **Aktionen** die Option **Bearbeiten** aus.
1. Legen Sie den Parameter `binlog_format` auf das binäre Protokollierungsformat Ihrer Wahl fest (`ROW`, `STATEMENT` oder `MIXED`). Sie können auch den Wert `OFF` verwenden, um die Binärprotokollierung zu deaktivieren.
**Anmerkung**
Die Einstellung von `binlog_format` auf `OFF` in der DB-Cluster-Parametergruppe deaktiviert die Sitzungsvariable `log_bin`. Dadurch wird die Binärprotokollierung auf dem DB-Cluster von Aurora MySQL deaktiviert, wodurch wiederum die Sitzungsvariable `binlog_format` auf den Standardwert `ROW` in der Datenbank zurückgesetzt wird.
1. Wählen Sie **Save changes (Änderungen speichern)**, um die Aktualisierungen in dieser DB--Cluster-Parametergruppe zu speichern.
Nachdem Sie diese Schritte ausgeführt haben, müssen Sie die Writer-Instance im DB-Cluster neu starten, damit Ihre Änderungen übernommen werden. Wenn Sie in Aurora MySQL Version 2.09 und niedriger die Writer-Instance neu starten, werden auch alle Reader-Instances im DB-Cluster neu gestartet. In Aurora MySQL Version 2.10 und höher müssen Sie alle Reader-Instances manuell neu starten. Weitere Informationen finden Sie unter [Neustart eines Amazon Aurora DB-Clusters oder einer Amazon Aurora DB-Instance](USER_RebootCluster.md).
**Wichtig**
Das Ändern einer DB-Cluster-Parametergruppe wirkt sich auf alle DB-Cluster aus, die diese Parametergruppe verwenden. Wenn Sie unterschiedliche binäre Logging-Formate für verschiedene Aurora MySQL-DB-Cluster in einer AWS Region angeben möchten, müssen die DB-Cluster unterschiedliche DB-Cluster-Parametergruppen verwenden. Diese Parametergruppen identifizieren unterschiedliche Protokollierungsformate. Weisen Sie jedem DB-Cluster die entsprechende DB-Cluster-Parametergruppe zu. Weitere Informationen zu Aurora MySQL-Parametern finden Sie unter [Aurora MySQL Konfigurationsparameter](AuroraMySQL.Reference.ParameterGroups.md).
# Zugriff auf MySQL-Binärprotokolle
Sie können das Dienstprogramm mysqlbinlog verwenden, um Binärprotokolle aus RDS-for-MySQL-DB-Instances herunterzuladen oder zu streamen. Das Binärprotokoll wird auf den lokalen Computer heruntergeladen, von wo aus Sie Aktionen, wie die Wiedergabe eines Protokolls mithilfe des Hilfsprogramms mysql ausführen können. Weitere Informationen über die Verwendung des Dienstprogramms mysqlbinlog finden Sie unter [Verwenden von mysqlbinlog zum Sichern binärer Protokolldateien](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html) in der MySQL-Dokumentation.
Verwenden Sie zum Ausführen des Dienstprogramms mysqlbinlog mit einer Amazon-RDS-Instance die folgenden Optionen:
+ `--read-from-remote-server` – Erforderlich.
+ `--host` – der DNS-Name vom Endpunkt der Instance.
+ `--port` – der von der Instance verwendete Port.
+ `--user` – ein MySQL-Benutzer, dem die Berechtigung `REPLICATION SLAVE` erteilt wurde.
+ `--password` – das Passwort für den MySQL-Benutzer oder lassen Sie einen Passwortwert aus, damit das Dienstprogramm zur Eingabe eines Passworts auffordert.
+ `--raw` – Laden Sie die Datei im Binärformat herunter.
+ `--result-file` – die lokale Datei, die den raw-Output empfangen soll.
+ `--stop-never` – Streamen Sie die binären Protokolldateien.
+ `--verbose` – Wenn Sie das Binlog-Format `ROW` verwenden, schließen Sie diese Option ein, um die Zeilenereignisse als Pseudo-SQL-Anweisungen anzuzeigen. Weitere Informationen zur Option `--verbose` finden Sie unter [mysqlbinlog row event display](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html) in der MySQL-Dokumentation.
+ Geben Sie die Namen einer oder mehrerer Binärprotokolldateien an. Verwenden Sie den SQL-Befehl `SHOW BINARY LOGS`, um eine Liste der verfügbaren Protokolle abzurufen.
Weitere Informationen über mysqlbinlog-Optionen finden Sie unter [mysqlbinlog – Hilfsprogramm für die Verarbeitung binärer Protokolldateien](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) in der MySQL-Dokumentation.
Die folgenden Beispiele veranschaulichen die Verwendung des Dienstprogramms mysqlbinlog.
Für Linux, macOS oder Unix:
```
mysqlbinlog \
--read-from-remote-server \
--host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \
--port=3306 \
--user ReplUser \
--password \
--raw \
--verbose \
--result-file=/tmp/ \
binlog.00098
```
Für Windows:
```
mysqlbinlog ^
--read-from-remote-server ^
--host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com ^
--port=3306 ^
--user ReplUser ^
--password ^
--raw ^
--verbose ^
--result-file=/tmp/ ^
binlog.00098
```
Binärprotokolle müssen auf der DB-Instance verfügbar bleiben, damit das Dienstprogramm „mysqlbinlog“ auf sie zugreifen kann. Verwenden Sie die gespeicherte Prozedur [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) und geben Sie einen Zeitraum mit ausreichend Zeit für den Download der Protokolle an, um die Verfügbarkeit sicherzustellen. Wenn diese Konfiguration nicht festgelegt ist, löscht Amazon RDS die Binärprotokolle so schnell wie möglich, was zu Lücken in den Binärprotokollen führt, die das Dienstprogramm „mysqlbinlog“ abruft.
Das folgende Beispiel setzt den Aufbewahrungszeitraum auf 1 Tag.
```
call mysql.rds_set_configuration('binlog retention hours', 24);
```
Verwenden Sie die gespeicherte Prozedur [mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration), um die aktuelle Einstellung anzeigen zu lassen.
```
call mysql.rds_show_configuration;
```
# Aurora PostgreSQL
Sie können die folgenden Arten von Aurora-PostgreSQL-Protokolldateien überwachen:
+ PostgreSQL-Protokoll
+ Instance-Protokoll
+ Fehlerprotokoll zur IAM-Datenbankauthentifizierung
**Anmerkung**
Um Fehlerprotokolle für die IAM-Datenbankauthentifizierung zu aktivieren, müssen Sie zunächst die IAM-Datenbankauthentifizierung für Ihre DB-Cluster von Aurora PostgreSQL aktivieren. Weitere Informationen zur Aktivierung der IAM-Datenbankauthentifizierung finden Sie unter [Aktivieren und Deaktivieren der IAM-Datenbank-Authentifizierung](UsingWithRDS.IAMDBAuth.Enabling.md).
Aurora PostgreSQL protokolliert Datenbankaktivitäten in der PostgreSQL-Standardprotokolldatei. Bei einer On-Premises PostgreSQL-DB-Instance werden diese Nachrichten in `log/postgresql.log` lokal gespeichert. Für einen DB-Cluster von Aurora PostgreSQL ist die Protokolldatei auf dem Aurora-Cluster verfügbar. Auf diese Protokolle kann auch über die zugegriffen werden AWS-Managementkonsole, wo Sie sie ansehen oder herunterladen können. Die Standardprotokollierungsebene erfasst Anmeldefehler, schwerwiegende Serverfehler, Deadlocks und Abfragefehler.
Weitere Informationen zum Anzeigen, Herunterladen und Überwachen von dateibasierten Datenbankprotokollen finden Sie unter [Überwachen von Amazon Aurora-Protokolldateien](USER_LogAccess.md). Weitere Informationen zu PostgreSQL-Protokollen finden Sie unter [Arbeiten mit Amazon RDS und Aurora-PostgreSQL-Protokollen: Teil 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) und [Arbeiten mit Amazon RDS und Aurora-PostgreSQL-Protokollen: Teil 2](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/).
Zusätzlich zu den in diesem Thema behandelten PostgreSQL-Standardprotokollen unterstützt Aurora PostgreSQL auch die PostgreSQL-Audit-Erweiterung (`pgAudit`). Die meisten regulierten Branchen und Regierungsbehörden müssen ein Auditprotokoll oder einen Audit-Trail für die Änderungen von Daten führen, um die gesetzlichen Bestimmungen zu erfüllen. Weitere Informationen zur Installation und Verwendung von pgAudit finden Sie unter [Verwenden von pgAudit zur Protokollierung der Datenbankaktivität](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
Aurora erstellt eine separate Protokolldatei für DB-Instances, bei denen die Auto-Pause-Funktion aktiviert ist. In der Datei instance.log werden alle Gründe aufgezeichnet, warum diese DB-Instances nicht wie erwartet pausiert werden konnten. Weitere Informationen zum Verhalten von Instance-Protokolldateien und zur Auto-Pause-Funktion von Aurora finden Sie unter [Monitoring Aurora Serverless v2 pause and resume activity](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log).
**Topics**
+ [Parameter für die Protokollierung in Aurora PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md)
+ [Aktivieren der Abfrageprotokollierung für Ihren Aurora PostgreSQL-DB-Cluster](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md)
# Parameter für die Protokollierung in Aurora PostgreSQL
Sie können das Protokollierungsverhalten für Ihren DB-Cluster von Aurora PostgreSQL anpassen, indem Sie verschiedene Parameter ändern. In der folgenden Tabelle finden Sie unter anderem die Parameter, die sich darauf auswirken, wie lange die Protokolle gespeichert werden, wann das Protokoll rotiert werden soll und ob das Protokoll im CSV-Format (Comma-Separated Value) ausgegeben werden soll. Außerdem ist abgesehen von anderen Einstellungen die Textausgabe angegeben, die an STDERR gesendet wurde. Wenn Sie die Einstellungen für die modifizierbaren Parameter ändern möchten, verwenden Sie eine benutzerdefinierte DB-Cluster -Parametergruppe für Ihren DB-Cluster von Aurora PostgreSQL. Weitere Informationen finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md).
| Parameter | Standard | Description |
| --- | --- | --- |
| log\$1destination | stderr | Legt das Ausgabeformat für das Protokoll fest. Die Standardeinstellung ist `stderr`, aber Sie können auch das CSV-Format angeben, indem Sie der Einstellung `csvlog` hinzufügen. Weitere Informationen finden Sie unter [Festlegen des Protokollziels (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format). |
| log\$1filename | postgresql.log.%Y-%m-%d-%H%M | Gibt das Muster für den Namen der Protokolldatei an. Zusätzlich zur Standardeinstellung unterstützt dieser Parameter `postgresql.log.%Y-%m-%d` und `postgresql.log.%Y-%m-%d-%H` für das Dateinamenmuster. Für Aurora-PostgreSQL-Version 17.4 und höher können Sie diesen Parameter nicht ändern. |
| log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | Definiert das Präfix für jede Protokollzeile, die in `stderr` geschrieben wird, um die Uhrzeit (%t), den Remote-Host (%r), den Benutzer (%u), die Datenbank (%d) und die Prozess-ID (%p) anzugeben. |
| log\$1rotation\$1age | 60 | Minuten, nach denen die Protokolldatei automatisch rotiert wird. Sie können diesen Wert im Bereich von 1 Minute bis 1.440 Minuten ändern. Weitere Informationen finden Sie unter [Festlegen der Rotation der Protokolldatei](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| log\$1rotation\$1size | – | Die Größe (kB), bei der das Protokoll automatisch rotiert wird. Sie können diesen Wert im Bereich von 50 000 bis 1 000 000 Kilobyte ändern. Weitere Informationen hierzu finden Sie unter [Festlegen der Rotation der Protokolldatei](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| rds.log\$1retention\$1period | 4320 | PostgreSQL-Protokolle, die älter als die angegebene Anzahl von Minuten sind, werden gelöscht. Mit dem Standardwert von 4.320 Minuten werden Protokolldateien nach 3 Tagen gelöscht. Weitere Informationen finden Sie unter [Festlegen des Aufbewahrungszeitraums für Protokolle](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period). |
Anwendungsprobleme können Sie identifizieren, indem Sie im Protokoll nach Abfragefehlern, Anmeldefehlern, Deadlocks und schwerwiegenden Serverfehlern suchen. Angenommen, Sie haben eine Legacy-Anwendung von Oracle in Aurora PostgreSQL konvertiert, wobei jedoch nicht alle Abfragen ordnungsgemäß umgewandelt wurden. Diese falsch formatierten Abfragen generieren Fehlermeldungen in den Protokollen, mit denen Sie Probleme identifizieren können. Weitere Informationen zur Protokollierung von Abfragen finden Sie unter [Aktivieren der Abfrageprotokollierung für Ihren Aurora PostgreSQL-DB-Cluster ](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md).
In den folgenden Themen finden Sie Informationen darüber, wie Sie verschiedene Parameter festlegen, die die grundlegenden Details Ihrer PostgreSQL-Protokolle steuern.
**Topics**
+ [Festlegen des Aufbewahrungszeitraums für Protokolle](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period)
+ [Festlegen der Rotation der Protokolldatei](#USER_LogAccess.Concepts.PostgreSQL.log_rotation)
+ [Festlegen des Protokollziels (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format)
+ [Grundlagen des Parameters log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix)
## Festlegen des Aufbewahrungszeitraums für Protokolle
Der `rds.log_retention_period`-Parameter gibt an, wie lange Ihr DB-Cluster von Aurora PostgreSQL die entsprechenden Protokolldateien aufbewahrt. Die Standardeinstellung ist 3 Tage (4 320 Minuten). Sie können diese Einstellung jedoch auf einen beliebigen Wert zwischen 1 Tag (1 440 Minuten) und 7 Tagen (10 080 Minuten) festlegen. Stellen Sie sicher, dass Ihr DB-Cluster von Aurora PostgreSQL über ausreichend Speicherplatz verfügt, um die Protokolldateien für diesen Zeitraum zu speichern.
Wir empfehlen, dass Sie Ihre Protokolle routinemäßig in Amazon CloudWatch Logs veröffentlichen, damit Sie Systemdaten noch lange nach dem Entfernen der Protokolle aus Ihrem Aurora PostgreSQL-DB-Cluster anzeigen und analysieren können. Weitere Informationen finden Sie unter [Veröffentlichen von Aurora-PostgreSQL-Protokollen in Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md). Nachdem Sie die CloudWatch Veröffentlichung eingerichtet haben, löscht Aurora ein Protokoll erst, nachdem es in CloudWatch Logs veröffentlicht wurde.
Amazon Aurora komprimiert ältere PostgreSQL Protokolle, wenn der Speicher für die DB-Instance einen Schwellenwert erreicht. Aurora komprimiert die Dateien mit dem gzip-Komprimierungsprogramm. Weitere Informationen finden Sie auf der [gzip](https://www.gzip.org)-Website.
Wenn der Speicher für die DB-Instance niedrig ist und alle verfügbaren Protokolle komprimiert sind, erhalten Sie eine Warnung wie die folgende:
```
Warning: local storage for PostgreSQL log files is critically low for
this Aurora PostgreSQL instance, and could lead to a database outage.
```
Wenn nicht genügend Speicher vorhanden ist, löscht Aurora möglicherweise komprimierte PostgreSQL-Protokolle vor Ablauf des angegebenen Aufbewahrungszeitraums. In diesem Fall wird eine Meldung ähnlich der folgenden angezeigt:
```
The oldest PostgreSQL log files were deleted due to local storage constraints.
```
## Festlegen der Rotation der Protokolldatei
Neue Protokolldateien werden von Aurora standardmäßig jede Stunde erstellt. Das Timing wird vom Parameter `log_rotation_age` kontrolliert. Dieser Parameter hat einen Standardwert von 60 (Minuten). Sie können ihn jedoch auf jeden beliebigen Wert zwischen 1 Minute und 24 Stunden (1 440 Minuten) festlegen. Wenn die Rotation ansteht, wird eine neue eindeutige Protokolldatei erstellt. Die Datei wird nach dem Muster benannt, das durch den Parameter `log_filename` angegeben wird.
Protokolldateien können auch entsprechend ihrer Größe gedreht werden, wie im Parameter `log_rotation_size` angegeben. Dieser Parameter gibt an, dass das Protokoll rotiert werden soll, wenn es die angegebene Größe (in Kilobyte) erreicht. Der Standardwert für `log_rotation_size` ist 100 000 KB (Kilobyte) für einen DB-Cluster von Aurora PostgreSQL. Sie können diesen Parameter jedoch auf einen beliebigen Wert zwischen 50 000 und 1 000 000 Kilobyte festlegen.
Die Protokolldateinamen basieren auf dem Dateinamenmuster des Parameters `log_filename`. Die verfügbaren Einstellungen für diesen Parameter lauten wie folgt:
+ `postgresql.log.%Y-%m-%d` – Standardformat für den Namen der Protokolldatei. Nimmt das Jahr, den Monat und das Datum in den Namen der Protokolldatei auf.
+ `postgresql.log.%Y-%m-%d-%H` – Nimmt die Stunde in das Format des Protokolldateinamens auf.
+ `postgresql.log.%Y-%m-%d-%H%M` – Nimmt die Stunde und die Minuten in das Format des Protokolldateinamens auf.
Wenn Sie den `log_rotation_age`-Parameter auf weniger als 60 Minuten festlegen, stellen Sie für den `log_filename`-Parameter das Minutenformat ein.
Weitere Informationen finden Sie unter [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE) und [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE) in der PostgreSQL-Dokumentation.
## Festlegen des Protokollziels (`stderr`, `csvlog`)
Standardmäßig generiert Aurora PostgreSQL Protokolle im Standardfehlerformat (stderr). Dieses Format ist die Standardeinstellung des Parameters `log_destination`. Jede Nachricht erhält ein Präfix nach dem im `log_line_prefix`-Parameter angegebenen Muster. Weitere Informationen finden Sie unter [Grundlagen des Parameters log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix).
Aurora PostgreSQL kann die Protokolle auch im `csvlog`-Format generieren. Das `csvlog`-Format ist nützlich, um die Protokolldaten als CSV-Daten zu analysieren. Angenommen, Sie verwenden die Erweiterung `log_fdw`, um mit Ihren Protokollen als Fremdtabellen zu arbeiten. Die Fremdtabelle, die für `stderr`-Protokolldateien erstellt wurde, enthält eine einzelne Spalte mit Protokollereignisdaten. Durch Hinzufügen von `csvlog` zum `log_destination`-Parameter erhalten Sie die Protokolldatei im CSV-Format mit Abgrenzungen für die verschiedenen Spalten der Fremdtabelle. Sie können Ihre Protokolle jetzt einfacher sortieren und analysieren.
Wenn Sie `csvlog` für diesen Parameter angeben, beachten Sie, dass sowohl `stderr`- als auch `csvlog`-Dateien generiert werden. Achten Sie auf den von den Protokollen verbrauchten Speicher und berücksichtigen Sie dabei die `rds.log_retention_period`und andere Einstellungen, die sich auf den Protokollspeicher und Turnover auswirken. Wenn Sie `stderr` und `csvlog` verwenden, verdoppelt sich der von den Protokollen verbrauchte Speicher.
Wenn Sie `csvlog` zu `log_destination` hinzufügen und zu `stderr` allein zurückkehren möchten, müssen Sie den Parameter zurücksetzen. Rufen Sie dazu die Amazon-RDS-Konsole auf und öffnen Sie die benutzerdefinierte DB-Cluster-Parametergruppe für Ihre Instance. Wählen Sie den `log_destination`-Parameter, die Option **Edit parameter** (Parameter bearbeiten) und dann **Reset** (Zurücksetzen) aus.
Weitere Informationen zum Konfigurieren der Protokollierung finden Sie unter [Arbeiten mit Amazon-RDS- und Aurora-PostgreSQL-Protokollen: Teil 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/).
## Grundlagen des Parameters log\$1line\$1prefix
Das Protokollformat `stderr` wird jeder Protokollnachricht mit den Details vorangestellt, die durch den Parameter `log_line_prefix` angegeben werden. Der Standardwert ist:
```
%t:%r:%u@%d:[%p]:t
```
Ab Aurora-PostgreSQL-Version 16 können Sie auch Folgendes auswählen:
```
%m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a
```
Jeder Protokolleintrag, der an stderr gesendet wird, enthält die folgenden Informationen, die auf dem ausgewählten Wert basieren:
+ `%t` – Zeitpunkt des Protokolleintrags ohne Millisekunden
+ `%m` – Zeitpunkt des Protokolleintrags mit Millisekunden
+ `%r` – Adresse des Remote-Hosts
+ `%u@%d` – Benutzername und Datenbankname
+ `[%p]` – Prozess-ID, falls verfügbar
+ `%l` – Nummer der Protokollzeile pro Sitzung
+ `%e` – SQL-Fehlercode
+ `%s` – Start-Zeitstempel des Prozesses
+ `%v` – ID der virtuellen Transaktion
+ `%x` – Transaktions-ID
+ `%c` – Sitzungs-ID
+ `%q` – Nicht für Sitzungen vorgesehene Begrenzung
+ `%a` – Anwendungsname
# Aktivieren der Abfrageprotokollierung für Ihren Aurora PostgreSQL-DB-Cluster
Sie können detailliertere Informationen über Ihre Datenbankaktivitäten sammeln, einschließlich Abfragen, Abfragen, die auf Sperren warten, Prüfpunkte und viele andere Details, indem Sie einige der in der folgenden Tabelle aufgeführten Parameter festlegen. Dieses Thema konzentriert sich auf das Protokollieren von Abfragen.
| Parameter | Standard | Description |
| --- | --- | --- |
| log\$1connections | – | Protokolliert jede erfolgreiche Verbindung. Informationen zur Verwendung dieses Parameters mit `log_disconnections` zum Erkennen von Verbindungsproblemen finden Sie unter [Verwaltung der Verbindungsabwanderung von Aurora PostgreSQL mit Pooling](AuroraPostgreSQL.BestPractices.connection_pooling.md). |
| log\$1disconnections | – | Protokolliert das Ende jeder Sitzung und ihre Dauer. Informationen zur Verwendung dieses Parameters mit `log_connections` zum Erkennen von Verbindungsproblemen finden Sie unter [Verwaltung der Verbindungsabwanderung von Aurora PostgreSQL mit Pooling](AuroraPostgreSQL.BestPractices.connection_pooling.md). |
| log\$1checkpoints | – | Gilt nicht für Aurora PostgreSQL |
| log\$1lock\$1waits | – | Protokolliert lange Sperrenwartezeiten. Dieser Parameter ist standardmäßig nicht festgelegt. |
| log\$1min\$1duration\$1sample | – | (ms) Legt die Mindestausführungszeit fest, jenseits der stichprobenartig Anweisungen protokolliert werden. Die Stichprobengröße wird mit dem log\$1statement\$1sample\$1rate-Parameter festgelegt. |
| log\$1min\$1duration\$1statement | – | Jede SQL-Anweisung, die mindestens für die angegebene Zeit oder länger ausgeführt wird, wird protokolliert. Dieser Parameter ist standardmäßig nicht festgelegt. Die Aktivierung dieses Parameters kann Sie dabei unterstützen, nicht optimierte Abfragen zu finden. |
| log\$1statement | – | Legt den Typ der protokollierten Anweisungen fest. Standardmäßig ist dieser Parameter nicht festgelegt, aber Sie können ihn in `all`, `ddl` oder `mod` ändern, um die Typen von SQL-Anweisungen anzugeben, die protokolliert werden sollen. Wenn Sie etwas anderes als `none` für diesen Parameter angeben, sollten Sie auch zusätzliche Maßnahmen ergreifen, um die Offenlegung von Passwörtern in den Protokolldateien zu verhindern. Weitere Informationen finden Sie unter [Reduzieren des Risikos der Offenlegung von Passwörtern bei der Verwendung der AbfrageprotokollierungReduzieren des Risikos der Offenlegung von Passwörtern](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). |
| log\$1statement\$1sample\$1rate | – | Der Prozentsatz der Anweisungen, die die in `log_min_duration_sample` angegebene Zeit bei der Protokollierung überschreiten. Diese Angabe wird als Gleitkommawert zwischen 0,0 und 1,0 ausgedrückt. |
| log\$1statement\$1stats | – | Schreibt kumulative Leistungsstatistiken in das Serverprotokoll. |
## Verwendung der Protokollierung, um Abfragen mit langsamer Ausführung zu suchen
Sie können SQL-Anweisungen und Abfragen protokollieren, um Abfragen zu finden, die langsam ausgeführt werden. Sie aktivieren diese Funktion, indem Sie die Einstellungen der Parameter `log_statement` und `log_min_duration` wie in diesem Abschnitt beschrieben ändern. Bevor Sie die Abfrageprotokollierung für Ihren DB-Cluster von Aurora PostgreSQL aktivieren, sollten Sie sich der möglichen Offenlegung von Passwörtern in den Protokollen bewusst sein und wissen, wie Sie die Risiken minimieren können. Weitere Informationen finden Sie unter [Reduzieren des Risikos der Offenlegung von Passwörtern bei der Verwendung der AbfrageprotokollierungReduzieren des Risikos der Offenlegung von Passwörtern](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
Nachstehend finden Sie Referenzinformationen zu den Parametern `log_statement` und `log_min_duration`.log\$1statement
Dieser Parameter gibt den Typ der SQL-Anweisungen an, die an das Protokoll gesendet werden sollen. Der Standardwert ist `none`. Wenn Sie diesen Parameter in `all`, `ddl` oder `mod` ändern, stellen Sie sicher, dass Sie die empfohlenen Maßnahmen ergreifen, um das Risiko einer Offenlegung von Passwörtern in den Protokollen zu reduzieren. Weitere Informationen finden Sie unter [Reduzieren des Risikos der Offenlegung von Passwörtern bei der Verwendung der AbfrageprotokollierungReduzieren des Risikos der Offenlegung von Passwörtern](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
**all**
Protokolliert alle Anweisungen. Diese Einstellung wird für Debugging-Zwecke empfohlen.
**ddl**
Protokolliert alle Data Definition Language (DDL)-Anweisungen wie CREATE, ALTER, DROP usw.
**mod**
Protokolliert alle DDL-Anweisungen und Data Manipulation Language (DML)-Anweisungen wie INSERT, UPDATE und DELETE, die die Daten modifizieren.
**Keine**
Es werden keine SQL-Anweisungen protokolliert. Wir empfehlen diese Einstellung, um das Risiko zu vermeiden, dass Passwörter in den Protokollen offengelegt werden.log\$1min\$1duration\$1statement
Jede SQL-Anweisung, die mindestens für die angegebene Zeit oder länger ausgeführt wird, wird protokolliert. Dieser Parameter ist standardmäßig nicht festgelegt. Die Aktivierung dieses Parameters kann Sie dabei unterstützen, nicht optimierte Abfragen zu finden.
**–1–2147483647**
Die Laufzeit in Millisekunden (ms), in der eine Anweisung protokolliert wird.
**So richten Sie die Abfrageprotokollierung ein**
Bei diesen Schritten wird davon ausgegangen, dass Ihr DB-Custer von Aurora PostgreSQL eine benutzerdefinierte DB-Cluster-Parametergruppe verwendet.
1. Stellen Sie den Parameter `log_statement` auf `all` ein. Im folgenden Beispiel werden die Informationen gezeigt, die bei dieser Parametereinstellung in die Datei `postgresql.log` geschrieben werden.
```
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: statement: SELECT feedback, s.sentiment,s.confidence
FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s
ORDER BY s.confidence DESC;
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: QUERY STATISTICS
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:DETAIL: ! system usage stats:
! 0.017355 s user, 0.000000 s system, 0.168593 s elapsed
! [0.025146 s user, 0.000000 s system total]
! 36644 kB max resident size
! 0/8 [0/8] filesystem blocks in/out
! 0/733 [0/1364] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 19/0 [27/0] voluntary/involuntary context switches
2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: SELECT feedback, s.sentiment,s.confidence
FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s
ORDER BY s.confidence DESC;
2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:ERROR: syntax error at or near "ORDER" at character 1
2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: ORDER BY s.confidence DESC;
----------------------- END OF LOG ----------------------
```
1. Legen Sie den Parameter `log_min_duration_statement` fest. Im folgenden Beispiel werden die Informationen gezeigt, die in die Datei `postgresql.log` geschrieben werden, wenn der Parameter auf `1` festgelegt wird.
Abfragen, die die im `log_min_duration_statement`-Parameter angegebene Dauer überschreiten, werden protokolliert. Es folgt ein Beispiel. Sie können die Protokolldatei für Ihren DB-Cluster von Aurora PostgreSQL in der Amazon-RDS-Konsole anzeigen.
```
2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: statement: DROP table comments;
2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: duration: 167.754 ms
2022-10-05 19:08:07 UTC::@:[355]:LOG: checkpoint starting: time
2022-10-05 19:08:08 UTC::@:[355]:LOG: checkpoint complete: wrote 11 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.013 s, sync=0.006 s, total=1.033 s; sync files=8, longest=0.004 s, average=0.001 s; distance=131028 kB, estimate=131028 kB
----------------------- END OF LOG ----------------------
```
### Reduzieren des Risikos der Offenlegung von Passwörtern bei der Verwendung der Abfrageprotokollierung
Wir empfehlen, für `log_statement` die Einstellung `none` beizubehalten, um zu vermeiden, dass Passwörter offengelegt werden. Wenn Sie `log_statement` auf `all`, `ddl` oder `mod` festlegen, sollten Sie einen oder mehrere der folgenden Schritte auszuführen.
+ Verschlüsseln Sie vertrauliche Informationen für den Client. Weitere Informationen finden Sie unter [Verschlüsselungsoptionen](https://www.postgresql.org/docs/current/encryption-options.html) der PostgreSQL-Dokumentation. Verwenden Sie die Optionen `ENCRYPTED` und `UNENCRYPTED` der `CREATE`- und `ALTER`-Anweisungen. Weitere Informationen finden Sie im Abschnitt [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) der PostgreSQL-Dokumentation.
+ Richten Sie für Ihren DB-Cluster von Aurora PostgreSQL die PostgreSQL Auditing (PGAudit)-Erweiterung ein und verwenden Sie sie. Diese Erweiterung redigiert sensible Informationen in CREATE- und ALTER-Anweisungen, die an das Protokoll gesendet werden. Weitere Informationen finden Sie unter [Verwenden von pgAudit zur Protokollierung der Datenbankaktivität](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ Beschränkt den Zugriff auf die CloudWatch Protokolle.
+ Verwenden Sie stärkere Authentifizierungsmechanismen wie IAM.