Fichiers journaux de base de données PostgreSQL - Amazon Relational Database Service

Fichiers journaux de base de données PostgreSQL

RDS for PostgreSQL génère des journaux de requêtes et d'erreurs. Vous pouvez utiliser les messages du journal pour résoudre les problèmes de performances et d'audit lors de l'utilisation de la base de données.

Pour afficher, télécharger et regarder les journaux de base de données sur des fichiers, consultez Surveillance des fichiers journaux Amazon RDS.

Présentation des journaux PostgreSQL

PostgreSQL génère des fichiers journaux d'événements qui contiennent des informations utiles pour les administrateurs de base de données.

Contenu des journaux

Le niveau de journalisation par défaut capture les erreurs qui affectent votre serveur. Par défaut, les paramètres de journalisation de Amazon RDS PostgreSQL capturent toutes les erreurs de serveur, y compris les suivantes :

  • Échecs des requêtes

  • Login failures

  • Erreurs fatales du serveur

  • Deadlocks

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, si vous avez converti une application héritée d'Oracle vers Amazon RDS PostgreSQL, certaines requêtes peuvent ne pas être converties correctement. Ces requêtes mal formatées génèrent des messages d'erreur dans les journaux, que vous pouvez utiliser pour identifier le code problématique.

Vous pouvez modifier les paramètres de journalisation PostgreSQL pour capturer des informations supplémentaires basées sur les catégories suivantes :

  • Connexions et déconnexions

  • Points de contrôle

  • Requêtes de modification de schéma

  • Requêtes en attente de verrous

  • Requêtes consommant du stockage sur disque temporaire

  • Processus auto-vacuum en backend consommant des ressources

En journalisant des informations pour diverses catégories, comme indiqué dans la liste, vous pouvez résoudre les problèmes potentiels de performance et d'audit. Pour plus d'informations, consultez la section Error Reporting and Logging (Rapports d'erreurs et journalisation) dans la documentation PostgreSQL. Pour obtenir un blog AWS utile sur la journalisation PostgreSQL, consultez la section Working with RDS and Aurora PostgreSQL logs: Part 1 (Utilisation des journaux RDS et Aurora PostgreSQL : Partie 1) et Working with RDS and Aurora PostgreSQL logs: Part 2 (Utilisation des journaux RDS et Aurora PostgreSQL : Partie 2).

Paramètres qui affectent le comportement de journalisation

Chaque instance Amazon RDS possède un groupe de paramètres qui spécifie sa configuration, y compris divers aspects de la journalisation. Les paramètres par défaut du groupe s'appliquent à chaque instance de base de données RDS for PostgreSQL dans une Région AWS donnée. Vous ne pouvez pas modifier les valeurs par défaut car elles s'appliquent à toutes les instances d'un moteur donné, même celles qui ne sont pas les vôtres. Pour modifier les valeurs d'un paramètre, vous devez créer un groupe de paramètres personnalisés et modifier ses paramètres. Par exemple, pour définir ou modifier les paramètres de journalisation, vous effectuez des changements dans le groupe de paramètres personnalisés associé à votre instance de base de données RDS for PostgreSQL. Pour savoir comment procéder, veuillez consulter la section Utilisation des groupes de paramètres.

Pour une instance de base de données RDS for PostgreSQL, les paramètres qui affectent le comportement de journalisation sont les suivants :

  • rds.log_retention_period : les journaux PostgreSQL qui sont 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.

  • log_rotation_age : spécifie le nombre de minutes après lequel Amazon RDS renouvelle automatiquement les journaux. La valeur par défaut est de 60 minutes, mais vous pouvez spécifier entre 1 et 1 440 minutes. Pour plus d'informations, consultez Définition de la rotation des fichiers journaux.

  • log_rotation_size : définit la taille, en kilo-octets, à partir de laquelle Amazon RDS doit automatiquement renouveler les journaux. Il n'y a pas de valeur par défaut car la rotation des journaux est basée uniquement sur l'âge, comme spécifié par le paramètre log_rotation_age. Pour plus d'informations, consultez Définition de la rotation des fichiers journaux.

  • log_line_prefix : spécifie les informations qui sont préfixées devant chaque ligne journalisée. La chaîne par défaut de ce paramètre est %t:%r:%u@%d:[%p]:, qui indique l'heure (%t) et d'autres caractéristiques distinctives telles que le nom de la base de données (%d) pour l'entrée du journal. Vous ne pouvez pas modifier ce paramètre. Il s'applique aux messages stderr qui sont journalisés.

  • log_destination : définit le format de sortie des journaux du serveur. La valeur par défaut de ce paramètre est l'erreur standard (stderr), mais le format csvlog (fichiers journaux à valeurs séparées par des virgules) est également pris en charge. Pour plus d'informations, consultez Définition de la destination du journal.

Définition de la période de conservation des journaux

Pour définir la période de conservation des journaux du système, utilisez le paramètre rds.log_retention_period. Vous pouvez trouver rds.log_retention_period dans le groupe de paramètres de base de données associé à votre instance de base de données . L'unité par défaut pour ce paramètre est la minute. Par exemple, la valeur 1 440 conserve les journaux pendant un jour. La valeur par défaut est 4 320 (trois jours). La valeur maximale est 10 080 (sept jours). Votre instance a besoin d'un espace de stockage alloué suffisant pour contenir les fichiers journaux conservés.

Nous vous recommandons de publier régulièrement vos journaux dans Amazon CloudWatch Logs, afin de pouvoir visualiser et analyser les données du système longtemps après que les journaux ont été supprimés de votre instance de base de données RDS for PostgreSQL. Pour de plus amples informations, consultez Publication des journaux PostgreSQL dans Amazon CloudWatch Logs.

Définition de la rotation des fichiers journaux

Les nouveaux fichiers journaux sont créés par Amazon RDS 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). Pour une instance de base de données RDS for PostgreSQL, la valeur log_rotation_size n'est pas définie, c'est-à-dire qu'il n'y a pas de valeur spécifiée. Toutefois, le paramètre permet un réglage de 0 à 2 097 151 ko (kilo-octets).

Les noms de fichier journal sont basés sur le modèle de nom de fichier du paramètre log_filename. Vous pouvez spécifier des noms de fichiers par heure ou par minute, comme suit :

  • postgresql.log.%Y-%m-%d-%H%M : format minute pour le nom du fichier journal. Définit la granularité du journal à moins d'une heure. Pris en charge par la version PostgreSQL et les versions ultérieures uniquement.

  • postgresql.log.%Y-%m-%d-%H : format heure pour le nom du fichier journal. Définit la granularité du journal en heures.

Si vous réglez le paramètre log_rotation_age sur moins de 60 minutes, veillez à régler également le paramètre log_filename sur le format des minutes.

Pour plus d'informations, consultez log_rotation_age et log_rotation_age dans la documentation de PostgreSQL.

Définition de la destination du journal

Par défaut, Amazon RDS PostgreSQL génère des journaux au format d'erreur standard (stderr). Il s'agit de la valeur par défaut du paramètre log_destination. Ce format fait précéder chaque message de journal de l'heure, de la base de données et d'autres détails spécifiés par le paramètre log_line_prefix. La valeur log_line_prefix est définie comme la chaîne de texte suivante, qui ne peut pas être modifiée :

%t:%r:%u@%d:[%p]:t

Ce paramètre spécifie les détails suivants pour chaque entrée de journal :

  • %t : heure de l'entrée du journal.

  • %r : adresse de l'hôte distant.

  • %u@%d : nom de l'utilisateur @ nom de la base de données.

  • [%p] : ID du processus si disponible.

Par exemple, le message d'erreur suivant résulte de l'interrogation d'une colonne avec un nom incorrect.

2019-03-10 03:54:59 UTC:10.0.0.123(52834):postgres@tstdb:[20175]:ERROR: column "wrong" does not exist at character 8

RDS for PostgreSQL peut générer les journaux dans un format csvlog supplémentaire à la valeur stderr spécifiée par défaut par le paramètre log_destination. La valeur csvlog permet d'analyser les données du journal en tant que données CSV. Par exemple, disons 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. Pour le fichier journal au format CSV, la table externe comporte plusieurs colonnes, ce qui vous permet de trier et d'analyser vos journaux beaucoup plus facilement. Pour savoir comment utiliser log_fdw avec csvlog, consultez Utilisation de l'extension log_fdw pour accéder au journal de base de données à l'aide de SQL.

Vous devez utiliser un groupe de paramètres personnalisés pour pouvoir modifier le paramètre log_destination. Le paramètre log_destination est dynamique, c'est-à-dire que la modification prend effet immédiatement, sans redémarrage.

Si vous modifiez ce paramètre, sachez que des fichiers csvlog sont générés en plus des journaux stderr. Nous vous recommandons de prêter attention à l'espace de 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. L'utilisation de stderr et de csvlog fait plus que doubler le stockage consommé par les journaux.

Si vous définissez le paramètre log_destination pour inclure csvlog et que vous décidez par la suite de revenir au paramètre par défaut uniquement (stderr), vous pouvez ouvrir le groupe de paramètres personnalisés de votre instance à l'aide de la AWS Management Console, choisir le paramètre log_destination dans la liste, cliquer sur Edit parameter (Modifier le paramètre), puis choisir Reset (Réinitialiser). Cela ramène le paramètre log_destination à son réglage par défaut, à savoir stderr.

Pour plus d'informations sur la configuration de la journalisation, consultez Working with Amazon RDS and Aurora PostgreSQL logs: Part 1 (Utiliser les journaux d'Amazon RDS et Aurora PostgreSQL : partie 1).

Activation de la journalisation des requêtes

Pour activer la journalisation des requêtes pour votre instance de base de données PostgreSQL, définissez deux paramètres dans le groupe de paramètres de base de données associé à votre instance de base de données : log_statement et log_min_duration_statement.

Le paramètre log_statement contrôle les instructions SQL qui sont enregistrées. La valeur par défaut est none. Lorsque vous déboguez des problèmes sur votre instance de base de données, nous vous recommandons de définir ce paramètre sur all afin de journaliser toutes les instructions. Pour journaliser toutes les instructions DDL (Data Definition Language) (CREATE, ALTER, DROP, etc.), définissez cette valeur sur ddl. Pour journaliser toutes les instructions DDL et DML (Data Manipulation Language) (INSERT, UPDATE, DELETE, etc.), définissez la valeur sur mod.

Avertissement

Des informations sensibles telles que les mots de passe peuvent être exposées si vous définissez le paramètre log_statement sur ddl, mod ou all. Pour éviter ce risque, définissez log_statement sur none. Envisagez les solutions suivantes :

  • Chiffrez les informations sensibles du côté client et utilisez les options ENCRYPTED et UNENCRYPTED des instructions CREATE et ALTER.

  • Limitez l'accès aux journaux CloudWatch.

  • Utilisez des mécanismes d'authentification plus forts tels que IAM.

Pour l'audit, vous pouvez utiliser l'extension Auditing (pgAudit) de PostgreSQL, car elle censure les informations sensibles pour les commandes CREATE et ALTER.

Le paramètre log_min_duration_statement définit la limite en millisecondes pour l'enregistrement d'une instruction. Toutes les instructions SQL s'exécutant plus longtemps que la durée définie pour le paramètre sont enregistrées. Par défaut, ce paramètre est désactivé et défini sur -1. L'activation de ce paramètre vous permet d'identifier les requêtes non optimisées.

Pour configurer la journalisation des requêtes, procédez comme suit :

  1. Définissez le paramètre log_statement sur all. L'exemple suivant illustre les informations écrites dans le fichier postgresql.log.

    2013-11-05 16:48:56 UTC::@:[2952]:LOG: received SIGHUP, reloading configuration files 2013-11-05 16:48:56 UTC::@:[2952]:LOG: parameter "log_statement" changed to "all"

    Des informations supplémentaires sont écrites dans le fichier postgresql.log lorsque vous exécutez une requête. L'exemple suivant illustre le type d'informations écrites dans le fichier après une requête.

    2013-11-05 16:41:07 UTC::@:[2955]:LOG: checkpoint starting: time 2013-11-05 16:41:07 UTC::@:[2955]:LOG: checkpoint complete: wrote 1 buffers (0.3%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=0.000 s, sync=0.003 s, total=0.012 s; sync files=1, longest=0.003 s, average=0.003 s 2013-11-05 16:45:14 UTC:[local]:master@postgres:[8839]:LOG: statement: SELECT d.datname as "Name", pg_catalog.pg_get_userbyid(d.datdba) as "Owner", pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding", d.datcollate as "Collate", d.datctype as "Ctype", pg_catalog.array_to_string(d.datacl, E'\n') AS "Access privileges" FROM pg_catalog.pg_database d ORDER BY 1; 2013-11-05 16:45:
  2. 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.

    2013-11-05 16:48:56 UTC::@:[2952]:LOG: received SIGHUP, reloading configuration files 2013-11-05 16:48:56 UTC::@:[2952]:LOG: parameter "log_min_duration_statement" changed to "1"

    Des informations supplémentaires sont écrites dans le fichier postgresql.log lorsque vous exécutez une requête dont la durée dépasse celle définie dans le paramètre de durée. L'exemple suivant illustre le type d'informations écrites dans le fichier après une requête.

    2013-11-05 16:51:10 UTC:[local]:master@postgres:[9193]:LOG: statement: SELECT c2.relname, i.indisprimary, i.indisunique, i.indisclustered, i.indisvalid, pg_catalog.pg_get_indexdef(i.indexrelid, 0, true), pg_catalog.pg_get_constraintdef(con.oid, true), contype, condeferrable, condeferred, c2.reltablespace FROM pg_catalog.pg_class c, pg_catalog.pg_class c2, pg_catalog.pg_index i LEFT JOIN pg_catalog.pg_constraint con ON (conrelid = i.indrelid AND conindid = i.indexrelid AND contype IN ('p','u','x')) WHERE c.oid = '1255' AND c.oid = i.indrelid AND i.indexrelid = c2.oid ORDER BY i.indisprimary DESC, i.indisunique DESC, c2.relname; 2013-11-05 16:51:10 UTC:[local]:master@postgres:[9193]:LOG: duration: 3.367 ms 2013-11-05 16:51:10 UTC:[local]:master@postgres:[9193]:LOG: statement: SELECT c.oid::pg_catalog.regclass FROM pg_catalog.pg_class c, pg_catalog.pg_inherits i WHERE c.oid=i.inhparent AND i.inhrelid = '1255' ORDER BY inhseqno; 2013-11-05 16:51:10 UTC:[local]:master@postgres:[9193]:LOG: duration: 1.002 ms 2013-11-05 16:51:10 UTC:[local]:master@postgres:[9193]:LOG: statement: SELECT c.oid::pg_catalog.regclass FROM pg_catalog.pg_class c, pg_catalog.pg_inherits i WHERE c.oid=i.inhrelid AND i.inhparent = '1255' ORDER BY c.oid::pg_catalog.regclass::pg_catalog.text; 2013-11-05 16:51:18 UTC:[local]:master@postgres:[9193]:LOG: statement: select proname from pg_proc; 2013-11-05 16:51:18 UTC:[local]:master@postgres:[9193]:LOG: duration: 3.469 ms

Publication des journaux PostgreSQL dans Amazon CloudWatch Logs

Pour stocker vos enregistrements de journaux PostgreSQL dans une solution de stockage hautement durable, vous pouvez utiliser Amazon CloudWatch Logs. CloudWatch Logs vous permet également d'effectuer une analyse en temps réel des données de journaux et d'utiliser CloudWatch pour afficher les métriques et créer des alarmes. Par exemple, si vous définissez log_statements sur ddl, vous pouvez configurer une alarme pour envoyer une alerte chaque fois qu'une instruction DDL est exécutée.

Pour utiliser CloudWatch Logs, configurez votre instance de base de données RDS for PostgreSQL de sorte à publier les données de journaux dans un groupe de journaux.

Note

La publication des fichiers journaux dans CloudWatch Logs est prise en charge pour PostgreSQL version 9.6.6 et ultérieure, PostgreSQL 10.4 et ultérieure, et pour toutes les versions ultérieures.

Vous pouvez publier les types de journaux suivants dans CloudWatch Logs pour RDS for PostgreSQL :

  • Journal PostgreSQL

  • Journal de mise à niveau (non disponible pour Aurora PostgreSQL)

Après avoir terminé la configuration, Amazon RDS publie les événements de journaux dans des flux de journaux au sein d'un groupe de journaux CloudWatch. Par exemple, les données de journaux PostgreSQL sont stockés dans le groupe de journaux /aws/rds/instance/my_instance/postgresql. Pour afficher vos journaux, ouvrez la console CloudWatch à l'adresse https://console.aws.amazon.com/cloudwatch/.

Pour publier des journaux PostgreSQL dans CloudWatch Logs à l'aide de la console

  1. Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans la panneau de navigation, choisissez Databases (Bases de données).

  3. Choisissez l'instance de base de données que vous souhaitez modifier, puis choisissez Modifier.

  4. Dans la section Exportations des journaux, choisissez les journaux que vous voulez commencer à publier dans CloudWatch Logs.

    La section Exportations des journaux est uniquement disponible pour les versions de PostgreSQL qui prennent en charge la publication dans CloudWatch Logs.

  5. Choisissez Continuer, puis Modifier l'instance de base de données sur la page récapitulative.

Vous pouvez publier des journaux PostgreSQL avec AWS CLI. Vous pouvez appeler la commande modify-db-instance avec les paramètres suivants :

  • --db-instance-identifier

  • --cloudwatch-logs-export-configuration

Note

Une modification apportée à l'option --cloudwatch-logs-export-configuration est toujours appliquée immédiatement à l'instance de base de données. Par conséquent, les options --apply-immediately et --no-apply-immediately sont sans effet.

Vous pouvez également publier des journaux PostgreSQL en appelant les commandes de CLI suivantes :

Exécutez l'une de ces commandes de CLI avec les options suivantes :

  • --db-instance-identifier

  • --enable-cloudwatch-logs-exports

  • --db-instance-class

  • --engine

D'autres options peuvent être requises en fonction de la commande de CLI que vous exécutez.

Exemple Modification d'une instance pour publier des journaux dans CloudWatch Logs

L'exemple suivant modifie une instance de base de données PostgreSQL existante pour publier les fichiers journaux sur CloudWatch Logs. La valeur --cloudwatch-logs-export-configuration n'est pas un objet JSON. La clé pour cet objet est EnableLogTypes et sa valeur est un tableau de chaînes avec une combinaison quelconque de postgresql et upgrade.

Pour Linux, macOS ou Unix :

aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql", "upgrade"]}'

Pour Windows :

aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql","upgrade"]}'

Exemple Création d'une instance pour publier des journaux dans CloudWatch Logs

L'exemple suivant crée une instance de base de données PostgreSQL et publie les fichiers journaux sur CloudWatch Logs. La valeur --enable-cloudwatch-logs-exports est un tableau de chaînes JSON. Les chaînes peuvent être une combinaison quelconque de postgresql et upgrade.

Pour Linux, macOS ou Unix :

aws rds create-db-instance \ --db-instance-identifier mydbinstance \ --enable-cloudwatch-logs-exports '["postgresql","upgrade"]' \ --db-instance-class db.m4.large \ --engine postgres

Pour Windows :

aws rds create-db-instance ^ --db-instance-identifier mydbinstance ^ --enable-cloudwatch-logs-exports '["postgresql","upgrade"]' ^ --db-instance-class db.m4.large ^ --engine postgres

Vous pouvez publier des journaux PostgreSQL avec l'API RDS. Vous pouvez appeler l'action ModifyDBInstance avec les paramètres suivants :

  • DBInstanceIdentifier

  • CloudwatchLogsExportConfiguration

Note

Une modification apportée au paramètre CloudwatchLogsExportConfiguration est toujours appliquée immédiatement à l'instance de base de données. Par conséquent, le paramètre ApplyImmediately est sans effet.

Vous pouvez également publier des journaux PostgreSQL en appelant les opérations d'API RDS suivantes :

Exécutez l'une de ces opérations d'API RDS avec les paramètres suivants :

  • DBInstanceIdentifier

  • EnableCloudwatchLogsExports

  • Engine

  • DBInstanceClass

D'autres paramètres peuvent être requis en fonction de l'opération que vous exécutez.