Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Fichiers journaux de base de données Aurora PostgreSQL PostgreSQL
Vous pouvez surveiller les types de fichiers journaux Aurora PostgreSQL suivants :
+ Journal PostgreSQL
+ Journal d’instance
+ Journal des erreurs d’authentification de base de données IAM
**Note**
Pour activer les journaux d’erreurs d’authentification de base de données IAM, vous devez d’abord activer l’authentification de base de données IAM pour votre cluster de bases de données Aurora PostgreSQL. Pour plus d’informations sur l’authentification de la base de données IAM, consultez [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
Aurora PostgreSQL consigne les activités de base de données dans le fichier journal PostgreSQL par défaut. Pour une instance de base de données PostgreSQL sur site, ces messages sont stockés localement dans `log/postgresql.log`. Pour un cluster de bases de données Aurora PostgreSQL, le fichier journal est disponible sur le cluster Aurora. Ces journaux sont également accessibles via le AWS Management Console, où vous pouvez les consulter ou les télécharger. Le niveau de journalisation par défaut capture les échecs de connexion, les erreurs de serveur fatales, les blocages et les échecs de requête.
Pour plus d’informations sur l’affichage, le téléchargement et la consultation des journaux de base de données basés sur des fichiers, consultez [Surveillance des fichiers journaux Amazon Aurora](USER_LogAccess.md). Pour en savoir plus sur les journaux PostgreSQL, consultez la section [Working with Amazon RDS and Aurora PostgreSQL logs: Part 1 (Utilisation des journaux Amazon RDS et Aurora PostgreSQL : Partie 1)](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) et [Working with Amazon RDS and Aurora PostgreSQL logs: Part 2 (Utilisation des journaux Amazon RDS et Aurora PostgreSQL : Partie 2)](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/).
Outre les journaux PostgreSQL standard décrits dans cette rubrique, Aurora PostgreSQL prend également en charge l’extension PostgreSQL Audit (`pgAudit`). La plupart des secteurs réglementés et des agences gouvernementales doivent conserver un journal d’audit ou une piste d’audit des modifications apportées aux données afin de se conformer aux exigences légales. Pour plus d’informations sur l’installation et l’utilisation de pgAudit, consultez [Utilisation de pgAudit pour journaliser l'activité de la base de données](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
Aurora crée un fichier journal distinct pour les instances de base de données pour lesquelles la pause automatique est activée. le fichier instance.log enregistre toutes les raisons pour lesquelles ces instances de base de données n’ont pas pu être mises en pause comme prévu. Pour plus d’informations sur le comportement des fichiers journaux d’instance et la fonctionnalité de pause automatique d’Aurora, consultez [Surveillance des activités de Aurora sans serveur v2 pause et de reprise](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log).
**Topics**
+ [
# Paramètres de journalisation dans Aurora PostgreSQL
](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md)
+ [
# Activation de la journalisation des requêtes pour votre instance de base de données Aurora PostgreSQL pour PostgreSQL
](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md)
# Paramètres de journalisation dans Aurora PostgreSQL
Vous pouvez personnaliser le comportement de journalisation de votre cluster de bases de données Aurora PostgreSQL en modifiant divers paramètres. Dans le tableau suivant, vous trouverez les paramètres qui affectent combien de temps les journaux sont stockés, quand effectuer la rotation du journal et s’il convient de fournir en sortie le journal au format CSV (valeurs séparées par des virgules). Vous pouvez également trouver le texte de sortie envoyé à STDERR, entre autres paramètres. Pour modifier les valeurs des paramètres modifiables, utilisez un groupe de paramètres de cluster de bases de données pour votre cluster de bases de données Aurora PostgreSQL. Pour plus d’informations, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md).
| Paramètre | Par défaut | Description |
| --- | --- | --- |
| log\$1destination | stderr | Définit le format de sortie pour le journal. La valeur par défaut est `stderr`, mais vous pouvez également spécifier une valeur séparée par des virgules (CSV) en ajoutant `csvlog` au paramètre. Pour plus d’informations, consultez [Définition de la destination du journal (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format). |
| log\$1filename | postgresql.log.%Y-%m-%d-%H%M | Spécifie le modèle du nom de fichier journal. Outre la valeur par défaut, ce paramètre prend en charge `postgresql.log.%Y-%m-%d` et `postgresql.log.%Y-%m-%d-%H` pour le modèle de nom de fichier. Pour Aurora PostgreSQL version 17.4 et versions ultérieures, vous ne pouvez pas modifier ce paramètre. |
| log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | Définit le préfixe pour chaque ligne de journal qui est écrite sur `stderr`, afin de noter l’heure (%t), l’hôte distant (%r), l’utilisateur (%u), la base de données (%d) et l’ID du processus (%p). |
| log\$1rotation\$1age | 60 | Minutes après lesquelles la rotation automatique du fichier journal est effectuée. Vous pouvez remplacer cette valeur par toute valeur comprise entre 1 et 1 440 minutes. Pour plus d’informations, consultez [Définition de la rotation des fichiers journaux](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| log\$1rotation\$1size | – | Taille (en Ko) à laquelle la rotation automatique du fichier journal est effectuée. Vous pouvez modifier cette valeur dans une plage comprise entre 50 000 et 1 000 000 kilo-octets. Pour en savoir plus, consultez [Définition de la rotation des fichiers journaux](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). |
| rds.log\$1retention\$1period | 4320 | Les journaux PostgreSQL plus anciens que le nombre de minutes spécifié sont supprimés. La valeur par défaut de 4 320 minutes supprime les fichiers journaux après trois jours. Pour plus d’informations, consultez [Définition de la période de conservation des journaux](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period). |
Pour identifier les problèmes d’application, vous pouvez rechercher dans le journal les échecs de requête, les échecs de connexion, les interblocages et les erreurs fatales du serveur. Par exemple, supposons que vous avez converti une application héritée d’Oracle vers Aurora, mais que certaines requêtes n’ont pas été converties correctement. Ces requêtes mal formatées génèrent des messages d’erreur que vous pouvez trouver dans les journaux pour aider à identifier les problèmes. Pour plus d’informations sur la journalisation des requêtes, consultez [Activation de la journalisation des requêtes pour votre instance de base de données Aurora PostgreSQL pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md).
Dans les rubriques suivantes, vous pouvez trouver des informations sur la manière de définir les différents paramètres qui contrôlent les détails de base de vos journaux PostgreSQL.
**Topics**
+ [
## Définition de la période de conservation des journaux
](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period)
+ [
## Définition de la rotation des fichiers journaux
](#USER_LogAccess.Concepts.PostgreSQL.log_rotation)
+ [
## Définition de la destination du journal (`stderr`, `csvlog`)
](#USER_LogAccess.Concepts.PostgreSQL.Log_Format)
+ [
## Compréhension du paramètre log\$1line\$1prefix
](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix)
## Définition de la période de conservation des journaux
Le paramètre `rds.log_retention_period` indique la durée pendant laquelle votre cluster de bases de données Aurora PostgreSQL conserve ses fichiers journaux. La valeur par défaut est de 3 jours (4 320 minutes), mais vous pouvez définir une valeur comprise entre 1 jour (1 440 minutes) et 7 jours (10 080 minutes). Assurez-vous que votre instance de base de données Aurora PostgreSQL dispose d’un espace de stockage suffisant pour contenir les fichiers journaux pendant cette période.
Nous vous recommandons de publier régulièrement vos CloudWatch journaux sur Amazon Logs afin de pouvoir consulter et analyser les données système longtemps après leur suppression de votre cluster de base de données Aurora PostgreSQL. Pour plus d’informations, consultez [Publication de journaux Aurora PostgreSQL sur Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md). Une fois que vous avez configuré la CloudWatch publication, Aurora ne supprime pas un journal tant qu'il n'est pas publié dans CloudWatch Logs.
Quand la capacité de stockage de l’instance de base de données atteint un seuil, Amazon Aurora compresse les journaux PostgreSQL plus anciens. Aurora compresse les fichiers en utilisant l’utilitaire de compression gzip. Pour plus d’informations, consultez le site Web de [gzip](https://www.gzip.org).
Lorsque le stockage de l’instance de base de données est faible et que tous les journaux disponibles sont compressés, vous obtenez un avertissement qui ressemble à l’exemple suivant :
```
Warning: local storage for PostgreSQL log files is critically low for
this Aurora PostgreSQL instance, and could lead to a database outage.
```
S’il n’y a pas assez de stockage, Aurora peut supprimer les journaux PostgreSQL compressés avant la fin de la période de conservation spécifiée. Si c’est le cas, vous verrez apparaître un message similaire au suivant :
```
The oldest PostgreSQL log files were deleted due to local storage constraints.
```
## Définition de la rotation des fichiers journaux
Aurora crée de nouveaux fichiers journaux toutes les heures, par défaut. Le timing est contrôlé par le paramètre `log_rotation_age`. Ce paramètre a une valeur par défaut de 60 (minutes), mais vous pouvez le régler sur une valeur comprise entre 1 minute et 24 heures (1 440 minutes). Au moment de la rotation, un fichier journal distinct est créé. Le fichier est nommé selon le modèle spécifié par le paramètre `log_filename`.
Les fichiers journaux peuvent également faire l’objet d’une rotation en fonction de leur taille, comme indiqué dans le paramètre `log_rotation_size`. Ce paramètre indique que le journal doit faire l’objet d’une rotation lorsqu’il atteint la taille spécifiée (en kilo-octets). La valeur `log_rotation_size` par défaut est de 100 000 Ko (kilo-octets) pour un cluster de bases de données Aurora PostgreSQL, mais vous pouvez la définir entre 50 000 et 1 000 000 de kilo-octets.
Les noms de fichier journal sont basés sur le modèle de nom de fichier spécifié dans le paramètre `log_filename`. Les valeurs disponibles pour ce paramètre sont les suivantes :
+ `postgresql.log.%Y-%m-%d` : format par défaut du nom de fichier journal. Inclut l’année, le mois et la date dans le nom du fichier journal.
+ `postgresql.log.%Y-%m-%d-%H` : inclut l’heure dans le format du nom de fichier journal.
+ `postgresql.log.%Y-%m-%d-%H%M` : inclut l’heure:minute dans le format du nom de fichier journal.
Si vous définissez le paramètre `log_rotation_age` sur une valeur inférieure à 60 minutes, définissez également le paramètre `log_filename` au format minute.
Pour plus d’informations, consultez [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) et [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) dans la documentation de PostgreSQL.
## Définition de la destination du journal (`stderr`, `csvlog`)
Par défaut, Aurora PostgreSQL génère des journaux au format d’erreur standard (stderr). Ce format correspond au réglage par défaut du paramètre `log_destination`. Chaque message est préfixé selon le modèle spécifié dans le paramètre `log_line_prefix`. Pour plus d’informations, consultez [Compréhension du paramètre log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix).
Aurora PostgreSQL peut également générer les journaux au format `csvlog`. La valeur `csvlog` permet d’analyser les données du journal en tant que données CSV (valeurs séparées par des virgules). Par exemple, supposons que vous utilisez l’extension `log_fdw` pour travailler avec vos journaux en tant que tables externes. La table externe créée sur les fichiers journaux `stderr` contient une seule colonne avec les données des événements de journal. En ajoutant `csvlog` au paramètre `log_destination`, vous obtenez le fichier journal au format CSV avec des démarcations pour les différentes colonnes de la table externe. Vous pouvez désormais trier et analyser vos journaux plus facilement.
Si vous spécifiez `csvlog` pour ce paramètre, sachez que les deux fichiers `stderr` et `csvlog` sont générés. Assurez-vous de surveiller le stockage consommé par les journaux, en tenant compte de `rds.log_retention_period` et des autres paramètres qui affectent le stockage et la rotation des journaux. Utiliser `stderr` et `csvlog` fait plus que doubler le stockage consommé par les journaux.
Si vous ajoutez `csvlog` à `log_destination` et que vous souhaitez revenir au paramètre `stderr` seul, vous devez réinitialiser le paramètre. Pour ce faire, ouvrez la console Amazon RDS, puis ouvrez le groupe de paramètres personnalisé du cluster de bases de données pour votre instance. Choisissez le paramètre `log_destination`, choisissez **Edit parameter** (Modifier le paramètre), puis **Reset** (Réinitialiser).
Pour plus d’informations sur la configuration de la journalisation, consultez [Working with Amazon RDS and Aurora PostgreSQL logs: Part 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) (Utiliser les journaux d’Amazon RDS et Aurora PostgreSQL : partie 1).
## Compréhension du paramètre log\$1line\$1prefix
Le format du journal `stderr` précède chaque message du journal des détails spécifiés par le paramètre `log_line_prefix`. La valeur par défaut est :
```
%t:%r:%u@%d:[%p]:t
```
À partir de la version 16 d’Aurora PostgreSQL, vous pouvez également choisir :
```
%m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a
```
Chaque entrée de journal envoyée à stderr inclut les informations suivantes en fonction de la valeur sélectionnée :
+ `%t` : heure de l’entrée du journal sans millisecondes
+ `%m` : heure de l’entrée du journal, en millisecondes
+ `%r` : adresse de l’hôte distant
+ `%u@%d` : nom d’utilisateur @ nom de base de données
+ `[%p]` : ID de processus si disponible
+ `%l` : numéro de ligne de journal par session
+ `%e` : code d’erreur SQL
+ `%s` : horodatage de début du processus
+ `%v` : identifiant de transaction virtuel
+ `%x` : ID de transaction
+ `%c` : ID de session
+ `%q` : délimiteur non session
+ `%a` : nom de l’application
# Activation de la journalisation des requêtes pour votre instance de base de données Aurora PostgreSQL pour PostgreSQL
Vous pouvez collecter des informations plus détaillées sur les activités de votre base de données, notamment les requêtes, les requêtes en attente de verrouillage, les points de contrôle et de nombreux autres détails en définissant certains des paramètres répertoriés dans le tableau suivant. Cette rubrique se concentre sur la journalisation des requêtes.
| Paramètre | Par défaut | Description |
| --- | --- | --- |
| log\$1connections | – | Enregistre toutes les connexions réussies. Pour savoir comment utiliser ce paramètre avec `log_disconnections` pour détecter les pertes de connexion, consultez [Gestion du taux de désabonnement des connexions Aurora PostgreSQL avec mise en pool](AuroraPostgreSQL.BestPractices.connection_pooling.md). |
| log\$1disconnections | – | Journalise la fin de chaque session et sa durée. Pour savoir comment utiliser ce paramètre avec `log_connections` pour détecter les pertes de connexion, consultez [Gestion du taux de désabonnement des connexions Aurora PostgreSQL avec mise en pool](AuroraPostgreSQL.BestPractices.connection_pooling.md). |
| log\$1checkpoints | – | Non applicable à Aurora PostgreSQL |
| log\$1lock\$1waits | – | Enregistre les longs temps d’attente pour l’acquisition d’un verrou. Ce paramètre n’est pas défini par défaut. |
| log\$1min\$1duration\$1sample | – | (ms) Définit la durée minimum d’exécution au-delà de laquelle les instructions sont journalisées. La taille de l’échantillon est définie à l’aide du paramètre log\$1statement\$1sample\$1rate. |
| log\$1min\$1duration\$1statement | – | Toute instruction SQL exécutée au moins pendant la durée spécifiée ou plus est journalisée. Ce paramètre n’est pas défini par défaut. L’activation de ce paramètre peut vous aider à identifier les requêtes non optimisées. |
| log\$1statement | – | Définit le type d’instructions enregistrées. Par défaut, ce paramètre n’est pas défini, mais vous pouvez le modifier pour `all`, `ddl` ou `mod` afin de spécifier les types d’instructions SQL que vous souhaitez journaliser. Si vous spécifiez autre chose que `none` pour ce paramètre, vous devez également prendre des mesures supplémentaires pour empêcher l’exposition des mots de passe dans les fichiers journaux. Pour plus d’informations, consultez [Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtesAtténuation du risque d’exposition des mots de passe](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). |
| log\$1statement\$1sample\$1rate | – | Le pourcentage d’instructions dépassant la durée spécifiée dans `log_min_duration_sample` pour être journalisées, exprimé sous la forme d’une valeur à virgule flottante comprise entre 0,0 et 1,0. |
| log\$1statement\$1stats | – | Ecrit les statistiques de performance cumulées dans le journal du serveur. |
## Utilisation de la journalisation pour détecter les requêtes lentes
Vous pouvez journaliser les instructions et les requêtes SQL pour favoriser la recherche des requêtes lentes. Vous pouvez activer cette fonctionnalité en modifiant les valeurs des paramètres `log_statement` et `log_min_duration`, comme indiqué dans cette section. Avant d’activer la journalisation des requêtes pour votre cluster de bases de données Aurora PostgreSQL, vous devez être conscient de l’exposition possible à des mots de passe dans les journaux et de la manière d’atténuer les risques. Pour plus d’informations, consultez [Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtesAtténuation du risque d’exposition des mots de passe](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
Vous trouverez ci-dessous des informations de référence sur les paramètres `log_statement` et `log_min_duration`.log\$1statement
Ce paramètre indique le type d’instructions SQL qui doivent être envoyées au journal. La valeur par défaut est `none`. Si vous remplacez ce paramètre par `all`, `ddl` ou `mod`, veillez à prendre les mesures recommandées pour réduire le risque d’exposition des mots de passe dans les journaux. Pour plus d’informations, consultez [Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtesAtténuation du risque d’exposition des mots de passe](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk).
**tout**
Journalise toutes les instructions. Ce paramètre est recommandé à des fins de débogage.
**ddl**
Journalise toutes les instructions DDL (Data Definition Language), telles que CREATE, ALTER, DROP, etc.
**mod**
Journalise toutes les instructions DDL et les instructions de langage de manipulation des données (DML) telles que INSERT, UPDATE et DELETE, qui modifient les données.
**Aucune**
Aucune instruction SQL n’est journalisée. Nous recommandons ce paramètre pour éviter le risque d’exposer des mots de passe dans les journaux.log\$1min\$1duration\$1statement
Toute instruction SQL exécutée au moins pendant la durée spécifiée ou plus est journalisée. Ce paramètre n’est pas défini par défaut. L’activation de ce paramètre peut vous aider à identifier les requêtes non optimisées.
**–1–2147483647**
Le nombre de millisecondes (ms) d’exécution pendant lequel une instruction est journalisée.
**Configurer la journalisation des requêtes**
Ces étapes supposent que votre cluster de bases de données Aurora PostgreSQL utilise un groupe de paramètres de cluster de bases de données personnalisé.
1. Définissez le paramètre `log_statement` sur `all`. L’exemple suivant illustre les informations écrites dans le fichier `postgresql.log` avec cette définition de paramètre.
```
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. Définissez le paramètre `log_min_duration_statement`. L’exemple suivant illustre les informations écrites dans le fichier `postgresql.log` lorsque le paramètre est défini sur `1`.
Les requêtes qui dépassent la durée spécifiée dans le paramètre `log_min_duration_statement` sont enregistrées. Vous en trouverez un exemple ci-dessous. Vous pouvez consulter le fichier journal de votre cluster de bases de données Aurora PostgreSQL dans la console Amazon RDS.
```
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 ----------------------
```
### Atténuation du risque d’exposition des mots de passe lors de l’utilisation de la journalisation de requêtes
Nous vous recommandons de garder `log_statement` sur `none` pour éviter de dévoiler les mots de passe. Si vous avez réglé `log_statement` sur `all`, `ddl` ou `mod`, nous vous recommandons de suivre une ou plusieurs des étapes suivantes.
+ Pour le client, chiffrez les informations sensibles. Pour plus d’informations, consultez [Options de chiffrement](https://www.postgresql.org/docs/current/encryption-options.html) dans la documentation PostgreSQL. Utilisez les options `ENCRYPTED` (et `UNENCRYPTED`) des instructions `CREATE` et `ALTER`. Pour plus d’informations, consultez [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) dans la documentation PostgreSQL.
+ Pour votre cluster de bases de données Aurora PostgreSQL, configurez et utilisez l’extension PostgreSQL Auditing (pgAudit). Cette extension supprime les informations sensibles dans les instructions CREATE et ALTER envoyées au journal. Pour de plus amples informations, veuillez consulter [Utilisation de pgAudit pour journaliser l'activité de la base de données](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ Limitez l'accès aux CloudWatch journaux.
+ Utilisez des mécanismes d’authentification plus forts tels que IAM.