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. # Surveillance des fichiers journaux Amazon Aurora Surveillance des journaux Aurora Chaque moteur de base de données RDS génère des journaux auxquels vous pouvez accéder pour l’audit et le dépannage. Le type de journaux dépend de votre moteur de base de données. Vous pouvez accéder aux journaux de base de données pour les instances de base de données à l’aide de la AWS Management Console, de l’AWS Command Line Interface (AWS CLI) ou de l’API Amazon RDS. Vous ne pouvez pas afficher, visualiser ou télécharger les journaux des transactions. **Note** Dans certains cas, les journaux contiennent des données cachées. L’AWS Management Console peut donc afficher du contenu dans un fichier journal et le fichier journal peut s’avérer vide lorsque vous le téléchargez. **Topics** + [ # Liste et affichage des fichiers journaux de base de données ](USER_LogAccess.Procedural.Viewing.md) + [ # Téléchargement d’un fichier journal de base de données ](USER_LogAccess.Procedural.Downloading.md) + [ # Consultation d’un fichier journal de base de données ](USER_LogAccess.Procedural.Watching.md) + [ # Publication des journaux de base de données dans Amazon CloudWatch Logs ](USER_LogAccess.Procedural.UploadtoCloudWatch.md) + [ # Lecture du contenu des fichiers journaux avec REST ](DownloadCompleteDBLogFile.md) + [ # Fichiers journaux de base de données Aurora MySQL ](USER_LogAccess.Concepts.MySQL.md) + [ # Fichiers journaux de base de données Aurora PostgreSQL PostgreSQL ](USER_LogAccess.Concepts.PostgreSQL.md) # Liste et affichage des fichiers journaux de base de données Vous pouvez afficher les fichiers journaux de la base de données de votre moteur de base de données Amazon Aurora à l’aide de la commande AWS Management Console. Vous pouvez répertorier les fichiers journaux disponibles pour téléchargement ou surveillance à l’aide de l’AWS CLI ou de l’API Amazon RDS. **Note** Vous ne pouvez pas afficher les fichiers journaux des clusters de bases de données Aurora Serverless v1 dans la console RDS. Vous pouvez toutefois les visualiser dans la console Amazon CloudWatch à l’adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). ## Console **Pour afficher un fichier journal de base de données** 1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**. 1. Choisissez le nom de l’instance de base de données qui contient le fichier journal que vous voulez consulter. 1. Choisissez l’onglet **Logs & events** (Journaux et événements). 1. Faites défiler jusqu’à la section **Journaux**. 1. (Facultatif) Entrez un terme de recherche pour filtrer vos résultats. L’exemple suivant liste les journaux filtrés par l’élément de texte **error**. ![\[Lister les journaux de la base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ListEventsAMS.png) 1. Sélectionnez le journal que vous souhaitez afficher, puis cliquez sur **View** (Afficher). ## AWS CLI Pour répertorier les fichiers journaux de base de données disponibles pour une instance de base de données, utilisez la commande [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html) de l’`describe-db-log-files`. L’exemple suivant renvoie une liste des fichiers journaux pour une instance DB nommée `my-db-instance`. **Example** ``` 1. aws rds describe-db-log-files --db-instance-identifier my-db-instance ``` ## API RDS Pour répertorier les fichiers journaux de base de données disponibles pour une instance de base de données, utilisez l’action [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html) de l’API Amazon RDS. # Téléchargement d’un fichier journal de base de données Vous pouvez utiliser la AWS Management Console, AWS CLI ou l’API pour télécharger un fichier journal de base de données. ## Console **Pour télécharger un fichier journal de base de données** 1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**. 1. Choisissez le nom de l’instance de base de données qui contient le fichier journal que vous voulez consulter. 1. Choisissez l’onglet **Logs & events** (Journaux et événements). 1. Faites défiler jusqu’à la section **Journaux**. 1. Dans la section **Journaux**, sélectionnez le bouton en regard du journal que vous voulez télécharger, puis choisissez **Télécharger**. 1. Ouvrez le menu contextuel (clic droit) pour le lien fourni, puis choisissez **Enregistrer le lien sous**. Saisissez l’emplacement souhaité pour l’enregistrement du fichier journal, puis cliquez sur **Enregistrer**. ![\[affichage du fichier journal\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/log_download2.png) ## AWS CLI Pour télécharger un fichier journal de base de données, utilisez la commande [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html) de l’`download-db-log-file-portion`. Par défaut, cette commande télécharge uniquement la portion la plus récente d’un fichier journal. Vous pouvez toutefois télécharger un fichier complet en spécifiant le paramètre `--starting-token 0`. L’exemple suivant montre comment télécharger le contenu d’un fichier journal appelé *log/ERROR.4* et le stocker dans un fichier local appelé *errorlog.txt*. **Example** Pour Linux, macOS ou 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 ``` Pour 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 ``` ## API RDS Pour télécharger un fichier journal de base de données, utilisez l’action [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html) de l’API Amazon RDS. # Consultation d’un fichier journal de base de données Surveiller un fichier journal de base de données revient à suivre le fichier sur un système UNIX ou Linux. Vous pouvez afficher un fichier journal en utilisant la AWS Management Console. RDS rafraîchit la queue du journal toutes les cinq secondes. **Pour consulter un fichier journal de base de données** 1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**. 1. Choisissez le nom de l’instance de base de données qui contient le fichier journal que vous voulez consulter. 1. Choisissez l’onglet **Logs & events** (Journaux et événements). ![\[Choisissez l’onglet Logs & events (Journaux et événements)\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_logsEvents.png) 1. Dans la section **Journaux**, choisissez un fichier journal, puis **Consulter**. ![\[Choisissez un journal\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch.png) RDS affiche la queue du journal, comme dans l’exemple MySQL suivant. ![\[Queue d’un fichier journal\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch_content.png) # Publication des journaux de base de données dans Amazon CloudWatch Logs Publication dans CloudWatch Logs. Dans une base de données sur site, les journaux de la base de données résident sur le système de fichiers. Amazon RDS ne fournit pas d’accès hôte aux journaux de la base de données sur le système de fichiers de votre cluster de bases de données. Pour cette raison, Amazon RDS vous permet d’exporter les journaux de la base de données vers [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). CloudWatch Logs vous permet d’effectuer une analyse en temps réel des données de journaux. Vous pouvez également stocker les données dans un stockage hautement durable et gérer les données grâce à l’agent CloudWatch Logs. **Topics** + [ ## Présentation de l’intégration de RDS avec CloudWatch Logs ](#rds-integration-cw-logs) + [ ## Décider des journaux à publier dans CloudWatch Logs ](#engine-specific-logs) + [ ## Spécification des journaux à publier dans CloudWatch Logs ](#integrating_cloudwatchlogs.configure) + [ ## Recherche et filtrage de vos journaux dans CloudWatch Logs ](#accessing-logs-in-cloudwatch) ## Présentation de l’intégration de RDS avec CloudWatch Logs Dans CloudWatch Logs, un *flux de journaux* est une séquence d’événements de journaux qui partagent la même source. Chaque source distincte de journaux dans CloudWatch Logs constitue un flux de journaux distinct. Un *groupe de journaux* est un groupe de flux de journaux qui partagent les mêmes paramètres de conservation, de surveillance et de contrôle d’accès. Amazon Aurora diffuse en continu les enregistrements des journaux de votre cluster de bases de données vers un groupe de journaux. Par exemple, vous possédez un groupe de journaux `/aws/rds/cluster/cluster_name/log_type` pour chaque type de journaux que vous publiez. Ce groupe de journaux se trouve dans la même région AWS que l’instance de base de données qui génère le journal. AWS conserve les données de journaux publiées dans CloudWatch Logs pendant une période indéterminée, sauf si vous précisez une durée de conservation. Pour plus d’informations, consultez [Modification de la conservation des données de journaux dans CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention). ## Décider des journaux à publier dans CloudWatch Logs Chaque moteur de base de données RDS prend en charge son propre ensemble de journaux. Pour en savoir plus sur les options de votre moteur de base de données, consultez les rubriques suivantes : + [Publication de journaux Amazon Aurora MySQL dans Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md) + [Publication de journaux Aurora PostgreSQL sur Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md) ## Spécification des journaux à publier dans CloudWatch Logs Vous spécifiez les journaux à publier dans la console. Assurez-vous que vous avez un rôle lié au service dans Gestion des identités et des accès AWS (IAM). Pour plus d’informations sur les rôles liés à un service, consultez [Utilisation des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md). **Pour spécifier les journaux à publier** 1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Dans la panneau de navigation, choisissez **Bases de données**. 1. Effectuez l’une des actions suivantes : + Choisissez **Create database (Créer une base de données)**. + Choisissez une base de données dans la liste, puis sélectionnez **Modify** (Modifier). 1. Dans **Logs exports** (Exportations de journaux), choisissez les journaux à publier. L’exemple suivant spécifie le journal d’audit, les journaux d’erreurs, le journal général, le journal d’instance, le journal d’erreurs d’authentification de base de données IAM, et le journal des requêtes lentes pour un cluster de bases de données Aurora MySQL. ## Recherche et filtrage de vos journaux dans CloudWatch Logs Vous pouvez rechercher des entrées de journal qui correspondent à des critères spécifiés à partir de la console CloudWatch Logs. Vous pouvez accéder aux journaux soit par la console RDS, qui vous conduit à la console CloudWatch Logs, soit directement à partir de la console CloudWatch Logs. **Pour rechercher les journaux de votre RDS à l’aide de la console RDS** 1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Dans la panneau de navigation, choisissez **Bases de données**. 1. Choisissez un cluster de bases de données ou une instance de base de données. 1. Choisissez **Configuration**. 1. Sous **Published logs** (Journaux publiés), choisissez le journal de la base de données que vous souhaitez afficher. **Pour effectuer une recherche dans vos journaux RDS à l’aide de la console CloudWatch Logs** 1. Ouvrez la console CloudWatch à l’adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Dans le panneau de navigation, choisissez **Groupes de journaux**. 1. Dans la zone de filtre, entrez **/aws/rds**. 1. Pour **Log Groups**, choisissez le nom du groupe de journaux contenant le flux de journal devant faire l’objet de la recherche. 1. Pour **Log Streams**, choisissez le nom du flux de journal devant faire l’objet de la recherche. 1. Sous **Journal des événements**, saisissez la syntaxe du filtre à utiliser. Pour plus d’informations, consultez [Searching and filtering log data](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) (Recherche et filtrage des données de journal) dans le *Guide de l’utilisateur d’Amazon CloudWatch Logs* Pour obtenir un tutoriel de blog expliquant comment surveiller les journaux RDS, consultez [Création d’une surveillance proactive des bases de données pour Amazon RDS avec Amazon CloudWatch Logs, AWS Lambda et Amazon SNS](https://aws.amazon.com/blogs/database/build-proactive-database-monitoring-for-amazon-rds-with-amazon-cloudwatch-logs-aws-lambda-and-amazon-sns/). # Lecture du contenu des fichiers journaux avec REST Amazon RDS fournit un point de terminaison REST qui permet d’accéder aux fichiers journaux des instances de base de données. Ceci est utile si vous devez écrire une application pour diffuser en continu le contenu de fichiers journaux Amazon RDS. La syntaxe est la suivante : ``` GET /v13/downloadCompleteLogFile/DBInstanceIdentifier/LogFileName HTTP/1.1 Content-type: application/json host: rds.region.amazonaws.com ``` Les paramètres suivants sont obligatoires : + `DBInstanceIdentifier`—le nom assigné par le client de l’instance de base de données qui contient le fichier journal que vous souhaitez télécharger. + `LogFileName`—le nom du fichier journal à télécharger. La réponse contient les contenus du fichier journal demandé, en tant que flux. L’exemple suivant télécharge le fichier journal appelé *log/ERROR.6* pour l’instance de base de données appelée *sample-sql* dans la région *us-west-2*. ``` 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 ``` Si vous spécifiez une instance de base de données qui n’existe pas, la réponse se compose de l’erreur suivante : + `DBInstanceNotFound`—`DBInstanceIdentifier` ne fait pas référence à une instance de base de données existante. (HTTP status code: 404) # Fichiers journaux de base de données Aurora MySQL Fichiers journaux de base de données MySQL Vous pouvez surveiller les journaux Aurora MySQL directement via la console Amazon RDS, l'API Amazon RDS ou AWS CLI. AWS SDKs Vous pouvez également accéder aux journaux MySQL en dirigeant les journaux vers une table de base de données de la base de données principale et interroger cette table. Vous pouvez utiliser l'utilitaire mysqlbinlog pour télécharger un journal binaire. Pour plus d’informations sur l’affichage, le téléchargement ou la consultation des journaux de base de données basés sur des fichiers, consultez [Surveillance des fichiers journaux Amazon Aurora](USER_LogAccess.md). **Topics** + [ # Présentation des journaux de base de données Aurora MySQL ](USER_LogAccess.MySQL.LogFileSize.md) + [ # Envoi de la sortie du journal Aurora MySQL à des tables ](Appendix.MySQL.CommonDBATasks.Logs.md) + [ # Configuration d'Aurora MySQL les bases de données mono-AZ ](USER_LogAccess.MySQL.BinaryFormat.md) + [ # Accès aux journaux binaires MySQL ](USER_LogAccess.MySQL.Binarylog.md) # Présentation des journaux de base de données Aurora MySQL Vous pouvez surveiller les types de fichiers journaux Aurora MySQL suivants : + Journal des erreurs + Journal des requêtes lentes + Journal général + Journal d’audit + Journal d’instance + Journal des erreurs d’authentification de base de données IAM Le journal des erreurs Aurora MySQL est généré par défaut. Vous pouvez générer le journal des requêtes lentes et le journal général en définissant les paramètres nécessaires dans votre groupe de paramètres de base de données. **Topics** + [ ## Journaux des erreurs Aurora MySQL ](#USER_LogAccess.MySQL.Errorlog) + [ ## Journal des requêtes lentes et journal général Aurora MySQL ](#USER_LogAccess.MySQL.Generallog) + [ ## Journal d’audit Aurora MySQL ](#ams-audit-log) + [ ## Journal d’instance Aurora MySQL ](#ams-instance-log) + [ ## Renouvellement et rétention des journaux pour Aurora MySQL ](#USER_LogAccess.AMS.LogFileSize.retention) + [ ## Publication de journaux Aurora MySQL sur Amazon CloudWatch Logs ](#USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs) ## Journaux des erreurs Aurora MySQL Aurora MySQL écrit les erreurs dans le fichier `mysql-error.log`. Le nom du fichier journal comporte l’heure à laquelle le fichier a été généré (au format UTC). Les fichiers journaux comportent également un horodatage permettant de déterminer le moment où les entrées du journal ont été écrites. Aurora MySQL écrit dans le journal des erreurs uniquement au moment du démarrage, de l’arrêt et lorsqu’une erreur survient. Une instance de base de données peut fonctionner pendant des heures ou des jours sans qu’aucune nouvelle entrée soit écrite dans le journal des erreurs. Si aucune entrée récente ne figure, cela signifie que le serveur n’a pas rencontré d’erreur justifiant une entrée de journal. Par défaut, les journaux des erreurs sont filtrés de sorte que seuls les événements inattendus tels que les erreurs soient affichés. Toutefois, les journaux des erreurs contiennent également des informations supplémentaires sur la base de données, comme la progression des requêtes, qui ne sont pas affichées. Par conséquent, même en l’absence d’erreurs réelles, la taille des journaux des erreurs peut augmenter en raison des activités en cours sur la base de données. Et même si vous pouvez voir une certaine taille en octets ou en kilo-octets pour les journaux d'erreurs dans le AWS Management Console, ils peuvent contenir 0 octet lorsque vous les téléchargez. Aurora MySQL écrit `mysql-error.log` sur le disque toutes les 5 minutes. Il ajoute le contenu du journal à `mysql-error-running.log`. Aurora MySQL assure la rotation du fichier `mysql-error-running.log` toutes les heures. **Note** La période de conservation des journaux est différente pour Amazon RDS et Aurora. ## Journal des requêtes lentes et journal général Aurora MySQL Vous pouvez écrire le journal des requêtes lentes et le journal général Aurora MySQL dans un fichier ou dans une table de base de données. Pour ce faire, définissez les paramètres de votre groupe de paramètres de base de données. Pour plus d’informations sur la création et la modification d’un groupe de paramètres DB, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). Vous devez définir ces paramètres avant de pouvoir consulter le journal des requêtes lentes ou le journal général dans la console Amazon RDS ou à l'aide de l'API Amazon RDS, de la CLI Amazon RDS ou. AWS SDKs Vous pouvez contrôler la journalisation Aurora MySQL à l’aide des paramètres de cette liste : + `slow_query_log` : Pour créer le journal des requêtes lentes, définir sur 1. La valeur par défaut est 0. + `general_log` : Pour créer le journal général, définir sur 1. La valeur par défaut est 0. + `long_query_time` : Pour empêcher l’enregistrement des requêtes rapides dans le journal des requêtes lentes, indiquez la valeur de la durée d’exécution de requête la plus courte devant être journalisée, en secondes. La valeur par défaut est de 10 secondes et la valeur minimum est 0. Si log\$1output = FILE, vous pouvez indiquer une valeur à virgule flottante avec une résolution en microseconde. Si log\$1output = TABLE, vous devez indiquer un nombre entier avec une résolution en seconde. Seules les requêtes dont la durée d’exécution dépasse la valeur `long_query_time` sont journalisées. Par exemple, si vous définissez `long_query_time` sur 0,1, les requêtes s’exécutant pendant moins de 100 millisecondes ne sont pas enregistrées. + `log_queries_not_using_indexes` : Pour enregistrer toutes les requêtes n’utilisant pas d’index dans le journal des requêtes lentes, définir sur 1. Les requêtes n’utilisant pas d’index sont journalisées même si la durée de leur exécution est inférieure à la valeur du paramètre `long_query_time`. La valeur par défaut est 0. + `log_output option` : Vous pouvez spécifier l’une des options suivantes pour le paramètre `log_output`. + **TABLEAU** – Écrit les requêtes générales dans le tableau `mysql.general_log` et les requêtes lentes dans le tableau `mysql.slow_log`. + **FICHIER** – Écrit les fichiers des requêtes générales et lentes dans le fichier système. + **AUCUNE**– Désactive la journalisation. Pour Aurora MySQL versions 2 et 3, la valeur par défaut pour `log_output` est `FILE`. Pour que les données de requête lentes apparaissent dans Amazon CloudWatch Logs, les conditions suivantes doivent être remplies : + CloudWatch Les journaux doivent être configurés pour inclure les journaux des requêtes lentes. + `slow_query_log` doit être activé. + `log_output` doit être défini sur `FILE`. + La durée de la requête doit être plus longue que celle configurée pour `long_query_time`. Pour plus d’informations sur le journal des requêtes lentes et le journal général, accédez aux rubriques suivantes dans la documentation MySQL : + [Journal des requêtes lentes](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html) + [Journal des requêtes générales](https://dev.mysql.com/doc/refman/8.0/en/query-log.html) ## Journal d’audit Aurora MySQL La journalisation d’audit pour Aurora MySQL se nomme « audit avancé ». Pour activer l’audit avancé, définissez certains paramètres de cluster de bases de données. Pour plus d’informations, consultez [Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Auditing.md). ## Journal d’instance Aurora MySQL 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). ## Renouvellement et rétention des journaux pour Aurora MySQL Lorsque la journalisation est activée, Amazon Aurora procède à la rotation ou à la suppression des fichiers journaux à intervalles réguliers. Cette précaution permet de limiter la possibilité qu’un fichier journal volumineux ne bloque l’utilisation de la base de données ou n’affecte les performances. Aurora MySQL gère la rotation et la suppression des journaux comme suit : + La taille des fichiers journaux des erreurs Aurora MySQL est limitée à 15 % maximum de l’espace de stockage local pour une instance de base de données. Pour maintenir ce seuil, les journaux sont automatiquement renouvelés toutes les heures. Aurora MySQL supprime les journaux au bout de 30 jours ou lorsque 15 % de l’espace disque est atteint. Si la taille de l’ensemble des fichiers journaux après la suppression dépasse le seuil, les fichiers journaux les plus anciens sont supprimés jusqu’à ce que la taille des fichiers journaux ne soit plus supérieure au seuil. + Aurora MySQL supprime les journaux d’audit, généraux et de requêtes lentes au bout de 24 heures ou lorsque 15 % du stockage est utilisé. + Lorsque la journalisation `FILE` est activée, les fichiers journaux généraux et les fichiers journaux des requêtes lentes sont examinés toutes les heures et ceux datant de plus de 24 heures sont supprimés. Dans certains cas, la taille des fichiers journaux combinés restant après la suppression peut dépasser le seuil de 15 % de l’espace local d’une instance de base de données. Le cas échéant, les fichiers journaux les plus anciens sont supprimés jusqu’à ce que la taille des fichiers journaux ne soit plus supérieure au seuil. + Lorsque la journalisation `TABLE` est activée, les tables des journaux ne font l’objet d’aucune rotation ou suppression. Les tables des journaux sont tronquées lorsque la taille de tous les journaux combinés est trop grande. Vous pouvez vous abonner à la catégorie d’événement `low storage` pour être informé lorsque les tables de journaux doivent faire l’objet d’une rotation ou d’une suppression manuelle pour libérer de l’espace. Pour plus d’informations, consultez [Utiliser la notification d’événements d’Amazon RDS](USER_Events.md). Vous pouvez effectuer une rotation manuelle de la table `mysql.general_log` en appelant la procédure `mysql.rds_rotate_general_log`. Vous pouvez effectuer une rotation de la table `mysql.slow_log` en appelant la procédure `mysql.rds_rotate_slow_log`. Lors de la rotation manuelle des tables de journaux, la table de journal actuelle est copiée vers une table de journal de sauvegarde et les entrées de la table de journal actuelle sont supprimées. Si la table de journal de sauvegarde existe déjà, elle est supprimée avant que la table de journal actuelle ne soit copiée dans la sauvegarde. Si besoin, vous pouvez interroger la table de journal de sauvegarde. La table de journal de sauvegarde de la table `mysql.general_log` est nommée `mysql.general_log_backup`. La table de journal de sauvegarde de la table `mysql.slow_log` est nommée `mysql.slow_log_backup`. + Les journaux d’audit Aurora MySQL font l’objet d’une rotation lorsque la taille des fichiers atteint 100 Mo. Ils sont supprimés au bout de 24 heures. + Amazon RDS fait pivoter les fichiers journaux d’erreurs d’authentification de base de données IAM supérieurs à 10 Mo. Amazon RDS supprime les fichiers journaux d’erreurs d’authentification de base de données IAM datant de plus de cinq jours ou de plus de 100 Mo. Pour utiliser les journaux de la console Amazon RDS, de l'API Amazon RDS, de l'interface de ligne de commande Amazon RDS, AWS SDKs ou définissez `log_output` le paramètre sur FILE. A l’instar du journal des erreurs Aurora MySQL, ces fichiers journaux font l’objet d’une rotation horaire. Les fichiers journaux qui ont été générés au cours des dernières 24 heures sont conservés. Veuillez noter que la période de rétention est différente pour Amazon RDS et pour Aurora. ## Publication de journaux Aurora MySQL sur Amazon CloudWatch Logs Vous pouvez configurer votre cluster de base de données Aurora MySQL pour publier les données de journal dans un groupe de CloudWatch journaux dans Amazon Logs. Avec CloudWatch Logs, vous pouvez effectuer une analyse en temps réel des données du journal, puis les utiliser CloudWatch pour créer des alarmes et afficher des métriques. Vous pouvez utiliser CloudWatch les journaux pour stocker vos enregistrements de journal dans un espace de stockage hautement durable. Pour de plus amples informations, veuillez consulter [Publication de journaux Amazon Aurora MySQL dans Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). # Envoi de la sortie du journal Aurora MySQL à des tables Vous pouvez diriger le journal des requêtes lentes et le journal général vers des tables sur l’instance de base de données en créant un groupe de paramètres DB et en définissant le paramètre du serveur `log_output` sur `TABLE`. Les requêtes générales sont ensuite enregistrées dans la table `mysql.general_log` et les requêtes lentes dans la table `mysql.slow_log`. Vous pouvez interroger les tables pour accéder aux informations des journaux. L’activation de cette journalisation augmente le volume de données écrites dans la base de données, ce qui peut dégrader les performances. Par défaut, le journal général et le journal des requêtes lentes sont désactivés. Afin d’activer la journalisation dans les tables, vous devez également définir les paramètres `general_log` et `slow_query_log` sur `1`. Les tables de journaux continuent de grossir jusqu’à ce que les activités de journalisation correspondantes soient désactivées en redéfinissant le paramètre approprié sur `0`. Avec le temps, une grande quantité de données s’accumule et risque d’utiliser une part considérable de l’espace de stockage alloué. Amazon Aurora ne vous permet pas de tronquer les tables de journaux, mais vous pouvez déplacer leurs contenus. Lorsque vous procédez à la rotation d’une table, son contenu est enregistré dans une table de sauvegarde et une nouvelle table de journal vide est créée. Vous pouvez effectuer une rotation manuelle des tables de journaux avec les procédures de ligne de commande suivantes, dans lesquelles l’invite de commande est indiquée par `PROMPT>` : ``` PROMPT> CALL mysql.rds_rotate_slow_log; PROMPT> CALL mysql.rds_rotate_general_log; ``` Pour supprimer totalement les anciennes données et récupérer l’espace de disque, appelez deux fois à la suite la procédure appropriée. # Configuration d'Aurora MySQL les bases de données mono-AZ Le *journal binaire* est un jeu de fichiers journaux contenant des informations sur les modifications de données apportées à une instance de serveur Aurora MySQL. Le journal binaire contient des informations telles que les suivantes : + Événements décrivant les modifications apportées à la base de données telles que la création de tables ou les modifications de lignes + Informations sur la durée de chaque instruction qui a mis à jour les données + Événements pour des instructions pouvant mettre à jour des données mais ne l’ayant pas fait Le journal binaire enregistre les instructions envoyées pendant la réplication. Il est également requis pour certaines opérations de récupération. Pour plus d’informations, consultez [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) dans la documentation MySQL. Les journaux binaires sont accessibles uniquement à partir de l’instance de base de données principale, et non à partir des réplicas. MySQL on Amazon Aurora prend en charge les formats de journalisation binaire *basés sur les lignes*, *basés sur les instructions* et *mixtes*. Nous recommandons le format mixte, sauf si vous avez besoin d’un format binlog spécifique. Pour plus de détails sur les différents formats de journalisation binaire Aurora MySQL, consultez [Formats de journalisation binaire](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html) dans la documentation MySQL. Si vous prévoyez d’utiliser la réplication, le format de journalisation binaire est important, car il détermine le dossier de modifications de données qui est enregistré dans la source et envoyés aux cibles de réplication. Pour plus d’informations sur les avantages et les désavantages des différents formats de journalisation binaire pour la réplication, consultez [Advantages and Disadvantages of Statement-Based and Row-Based Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) dans la documentation MySQL. **Important** Avec MySQL 8.0.34, MySQL a rendu le paramètre `binlog_format` obsolète. Dans les versions ultérieures de MySQL, MySQL prévoit de supprimer le paramètre et de ne prendre en charge que la réplication basée sur les lignes. Par conséquent, nous recommandons d’utiliser la journalisation basée sur les lignes pour les nouvelles configurations de réplication MySQL. Pour plus d’informations, consultez [binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format) dans la documentation MySQL. Les versions 8.0 et 8.4 de MySQL acceptent le paramètre `binlog_format`. Lors de l’utilisation de ce paramètre, MySQL émet un avertissement d’obsolescence. Dans une future version majeure, MySQL supprimera le paramètre `binlog_format`. La réplication basée sur les instructions peut provoquer des incohérences entre le cluster de bases de données source et un réplica en lecture. Pour plus d’informations, consultez [Determination of Safe and Unsafe Statements in Binary Logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) dans la documentation MySQL. L'activation de la journalisation binaire augmente le nombre d' I/O opérations d'écriture sur le disque sur le cluster d' de base de données. Vous pouvez surveiller l'utilisation des IOPS à l'aide de cette `` `VolumeWriteIOPs` CloudWatch métrique. **Pour définir le format de journalisation binaire MySQL** 1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Dans le panneau de navigation, choisissez **Groupes de paramètres**. 1. Choisissez le groupe de paramètres de cluster de bases de données, associé au cluster de bases de données, que vous voulez modifier. Vous ne pouvez pas modifier un groupe de paramètres par défaut. Si le cluster de bases de données utilise un groupe de paramètres par défaut, créez un nouveau groupe et associez-le à au cluster. Pour plus d’informations sur les groupes de paramètres, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). 1. Pour **Actions**, choisissez **Modifier**. 1. Définissez le paramètre `binlog_format` au format de journalisation binaire de votre choix (`ROW`, `STATEMENT` ou `MIXED`). Vous pouvez également utiliser la valeur `OFF` pour désactiver la journalisation binaire. **Note** Le réglage de `binlog_format` sur `OFF` dans le groupe de paramètres du cluster de bases de données désactive la variable de session `log_bin`. Cela désactive la journalisation binaire sur le cluster de bases de données Aurora MySQL, lequel à son tour réinitialise la variable de session `binlog_format` à la valeur par défaut `ROW` dans la base de données. 1. Choisissez **Save changes** (Enregistrer les modifications)pour enregistrer les mises à jour apportées au groupe de paramètres de cluster de bases de données. Après avoir effectué ces étapes, vous devez redémarrer l’instance d’enregistreur dans le cluster de bases de données pour que vos modifications s’appliquent. Dans Aurora MySQL version 2.09 et inférieures, lorsque vous redémarrez l’instance d’enregistreur, toutes les instances de lecteur du cluster de bases de données sont également redémarrées. Dans Aurora MySQL version 2.10 et ultérieures, vous devez redémarrer toutes les instances de lecteur manuellement. Pour plus d’informations, consultez [Redémarrage d'un cluster de bases de données Amazon Aurora ou d'une instance de base de données Amazon Aurora](USER_RebootCluster.md). **Important** La modification d’un groupe de paramètres de cluster de bases de données affecte tous les clusters de bases de données qui utilisent ce dernier. Si vous souhaitez spécifier différents formats de journalisation binaire pour différents clusters de base de données Aurora MySQL dans une AWS région, les clusters de base de données doivent utiliser différents groupes de paramètres de cluster de base de données. Ces groupes de paramètres identifient différents formats de journalisation. Affectez le groupe de paramètres de cluster de bases de données approprié à chaque cluster de bases de données. Pour plus d’informations sur les paramètres Aurora MySQL, consultez [Paramètres de configuration d’Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md). # Accès aux journaux binaires MySQL Vous pouvez utiliser l’utilitaire mysqlbinlog pour télécharger ou diffuser des journaux binaires à partir des instances de base de données RDS for MySQL. Le journal binaire est téléchargé dans votre ordinateur local et vous pouvez effectuer des actions comme relire le journal à l’aide de l’utilitaire mysql. Pour plus d’informations sur l’utilisation de l’utilitaire mysqlbinlog, consultez [Using mysqlbinlog to back up binary log files](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html) (Utilisation de mysqlbinlog pour sauvegarder les fichiers journaux binaires) dans la documentation MySQL. Pour exécuter à nouveau l’utilitaire mysqlbinlog sur une instance Amazon RDS, utilisez les options suivantes : + `--read-from-remote-server` : obligatoire. + `--host` : le nom DNS du point de terminaison de l’instance. + `--port` : le port utilisé par l’instance. + `--user` : un utilisateur MySQL ayant l’autorisation `REPLICATION SLAVE`. + `--password` : le mot de passe de l’utilisateur MySQL ou omettez la valeur de mot de passe pour que l’utilitaire vous invite à saisir un mot de passe. + `--raw` : téléchargez le fichier au format binaire. + `--result-file` : le fichier local qui recevra la sortie brute. + `--stop-never` : diffusez les fichiers journaux binaires. + `--verbose` : lorsque vous utilisez le format binlog `ROW`, incluez cette option pour afficher les événements de ligne sous forme d’instructions pseudo-SQL. Pour plus d’informations sur l’option `--verbose`, consultez [mysqlbinlog row event display](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html) (Affichage d’événements de ligne mysqlbinlog) dans la documentation MySQL. + Spécifiez les noms pour un ou plusieurs fichiers journaux binaires. Pour obtenir la liste des journaux disponibles, utilisez la commande SQL `SHOW BINARY LOGS`. Pour plus d’informations sur les options mysqlbinlog, consultez [mysqlbinlog — Utility for processing binary log files](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) (mysqlbinlog : utilitaire de traitement des fichiers journaux binaires) dans la documentation MySQL. Les exemples suivants montrent comment utiliser l’utilitaire mysqlbinlog. Pour Linux, macOS ou 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 ``` Pour 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 ``` Les journaux binaires doivent rester disponibles sur l’instance de base de données pour que l’utilitaire mysqlbinlog puisse y accéder. Pour garantir leur disponibilité, utilisez la procédure [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) stockée et spécifiez une période suffisamment longue pour télécharger les journaux. Si cette configuration n’est pas définie, Amazon RDS purge les journaux binaires dès que possible, ce qui entraîne des lacunes dans les journaux binaires récupérés par l’utilitaire mysqlbinlog. L’exemple suivant définit la période de conservation sur 1 jour. ``` call mysql.rds_set_configuration('binlog retention hours', 24); ``` Pour afficher les paramètres actuels, utilisez la procédure stockée [mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration). ``` call mysql.rds_show_configuration; ``` # Fichiers journaux de base de données Aurora PostgreSQL PostgreSQL Fichiers journaux de base de données 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 paramètres de journalisation 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 Activer la journalisation des requêtes 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 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 Atténuation du risque d’exposition des mots de passe 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.