Configurer la rotation des journaux AlloyDB Omni

Sélectionnez une version de la documentation :

Ce document explique comment configurer la rotation des journaux de diagnostic AlloyDB Omni lorsque vous utilisez l'opérateur Kubernetes AlloyDB Omni.

Les fichiers journaux suivants se trouvent dans le répertoire /obs/diagnostic/ :

  • postgresql.log : ce fichier journal collecte les journaux de serveur PostgreSQL, tels que les connexions client, les requêtes et les notifications administratives. Ces journaux sont toujours collectés et n'ont pas besoin d'être activés.

  • postgresql.audit : ce fichier journal collecte les journaux d'audit des accès aux sessions et aux objets. Pour collecter les journaux d'audit, consultez Gérer les journaux d'audit avec pgAudit.

  • postgresql.internal : AlloyDB Omni fournit des messages supplémentaires en plus des journaux PostgreSQL standards. Ces messages fournissent des informations techniques supplémentaires qui peuvent vous aider à déboguer les problèmes de base de données.

Comprendre et configurer la rotation des journaux

Découvrez comment AlloyDB Omni gère la rotation des journaux et comment configurer des seuils de rotation en fonction de la taille ou de la durée des fichiers.

Comportement de rotation des journaux

Lorsqu'un fichier journal subit une rotation, les événements suivants se produisent :

  1. Le fichier journal existant est archivé dans le répertoire /obs/diagnostic/archive/.

  2. Le fichier journal actif dans /obs/diagnostic/ est réinitialisé afin que les entrées de journal suivantes commencent à être écrites dans un fichier propre.

  3. Les informations de journalisation continuent d'être écrites dans le fichier journal actif jusqu'à ce que le fichier atteigne un seuil de taille ou d'âge, auquel cas il effectue une nouvelle rotation. Les journaux sont alternés afin que les fichiers journaux actifs ne deviennent pas trop volumineux.

Par défaut, le paramètre de rotation est défini pour que chaque fichier journal soit soumis à une rotation lorsque sa taille atteint 200 Mo. La rotation par défaut n'inclut pas de paramètre d'âge.

Les fichiers archivés sont conservés pendant sept jours. Les fichiers archivés datant de plus de sept jours sont automatiquement supprimés, à l'exception du fichier archivé lors de la dernière rotation. Par exemple, si log_rotation_age date de plus de sept jours, le fichier archivé atteint le seuil de sept jours avant la rotation du fichier actuel. Dans ce cas, ce fichier archivé n'est pas supprimé tant que la rotation suivante ne génère pas un nouveau fichier archivé.

Chaque nom de fichier journal ayant fait l'objet d'une rotation respecte le format postgresql-%Y-%m-%d_%H%M%S.EXTENSION.gz, où EXTENSION correspond à log, audit ou internal. L'heure de rotation détermine le code temporel en temps universel coordonné (UTC). Par exemple, si un fichier journal est soumis à une rotation le 20 décembre 2024 à 13:01:02 UTC, le nom du fichier archivé est postgresql-2024-12-20_130102.log.gz.

Le système compresse chaque fichier archivé individuellement au format de fichier gzip.

Configurer les seuils de rotation

Pour contrôler la rotation des journaux, configurez une taille de fichier maximale, une durée entre les rotations de journaux, ou les deux. La durée entre les rotations de journaux est également appelée l'âge du journal. Si vous utilisez les deux paramètres, chaque journal effectue une rotation lorsqu'il atteint l'un des seuils.

Pour configurer la rotation des journaux, définissez l'un des paramètres suivants ou les deux dans la section parameters du fichier manifeste DBCluster :

  • log_rotation_size : "SIZE_IN_KB"
  • log_rotation_age : "AGE_IN_MINUTES"

Remplacez les éléments suivants :

  • SIZE_IN_KB : taille maximale du fichier, en kilo-octets, avant la rotation des journaux.
  • AGE_IN_MINUTES : durée entre les rotations de journaux, en minutes.

Pour désactiver l'un des paramètres de rotation des journaux, définissez-le sur zéro, "0". Pour conserver le paramètre par défaut qui effectue la rotation des journaux lorsque leur taille de fichier atteint 200 Mo, ne définissez aucun paramètre.

Effectuer une rotation en fonction de la taille et de la durée du journal

L'exemple suivant définit la rotation des journaux lorsque la taille de leur fichier atteint 400 Mo ou lorsque l'intervalle entre les rotations de journaux atteint un jour, selon l'événement qui se produit en premier :

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
spec:
...
  primarySpec:
  ...
    parameters:
      log_rotation_size: "400000" # 400 MB
      log_rotation_age: "1440" # 24 hours * 60 minutes = 1 day

Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données.

Effectuer la rotation en fonction de la taille du journal uniquement

L'exemple suivant définit la rotation des journaux lorsque la taille de leur fichier atteint 400 Mo :

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
spec:
...
  primarySpec:
  ...
    parameters:
      log_rotation_size: "400000" # 400 MB
      log_rotation_age: "0" # Set to 0 to disable

Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données.

Alterner par durée seulement

L'exemple suivant définit la rotation des journaux toutes les 24 heures :

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
spec:
...
  primarySpec:
  ...
    parameters:
      log_rotation_size: "0" # Set to 0 to disable
      log_rotation_age: "1440" # 24 hours * 60 minutes = 1 day

Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données.

Configurer des limites de ressources pour la rotation des journaux

Par défaut, le conteneur logrotate s'exécute avec des paramètres de ressources faibles (50m processeur et 50Mi mémoire). Sur les clusters de bases de données avec des charges de travail importantes ou des volumes de journaux volumineux, la rotation des journaux peut nécessiter de la mémoire supplémentaire, ce qui peut entraîner des redémarrages du conteneur OOMKilled.

Vous pouvez configurer des demandes et des limites de processeur et de mémoire personnalisées pour les agents du plan de contrôle sous spec.primarySpec.controlPlaneAgentsResources dans votre ressource personnalisée DBCluster.

Comportement des ressources et valeurs par défaut

  • Paramètres par défaut : si controlPlaneAgentsResources.logrotate est omis, l'opérateur AlloyDB Omni applique les demandes par défaut de 50m CPU et 50Mi de mémoire, ainsi que les limites par défaut de 50m CPU et 50Mi de mémoire.
  • Champs obligatoires : si vous spécifiez controlPlaneAgentsResources.logrotate, vous devez également spécifier requests.cpu et requests.memory, et ils doivent être supérieurs à 0.
  • Limites : la définition de limites est facultative :
    • Si des limites sont spécifiées, chacune d'elles doit être supérieure ou égale à la requête correspondante.
    • Si les limites sont omises, le conteneur s'exécute uniquement avec les requêtes, sans limite supérieure appliquée. Les limites ne peuvent pas être définies sur 0.

Pour en savoir plus sur les demandes et les limites de ressources des conteneurs Kubernetes, consultez Gestion des ressources pour les pods et les conteneurs.

Exemple de fichier YAML

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
spec:
  databaseVersion: "18.4.0"
  primarySpec:
    # ...
    controlPlaneAgentsResources:
      logrotate:
        requests:
          cpu: 100m
          memory: 100Mi
        limits:
          cpu: 200m
          memory: 250Mi

Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données.

Paramètres de journalisation PostgreSQL compatibles

Vous pouvez configurer les informations envoyées à postgresql.log en définissant les paramètres GUC (Grand Unified Configuration) de journalisation PostgreSQL standards dans la section parameters de votre fichier manifeste DBCluster :

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
spec:
...
  primarySpec:
  ...
    parameters:
      log_min_messages: "warning"
      log_min_duration_statement: "250" # Log queries taking >= 250ms
      log_statement: "ddl" # Log all DDL statements
      log_lock_waits: "on"
      log_checkpoints: "on"
      log_temp_files: "0" # Log all temporary files created
      log_autovacuum_min_duration: "1000" # Log autovacuum runs taking >= 1s

Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données.

Le tableau suivant décrit les paramètres de journalisation PostgreSQL compatibles en fonction de la section Error Reporting and Logging (Rapports d'erreurs et journalisation) de la documentation PostgreSQL.

Paramètre Description
log_min_messages Contrôle les niveaux de message écrits dans le journal du serveur. Les valeurs valides sont debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal et panic. Chaque niveau inclut tous les niveaux de gravité suivants.
log_min_error_statement Contrôle les instructions SQL qui provoquent une condition d'erreur et sont enregistrées dans le journal du serveur. Les valeurs valides sont comprises entre debug5 et panic. Pour désactiver la journalisation des erreurs d'instruction, définissez la valeur sur panic.
log_min_duration_statement Enregistre la durée de chaque instruction terminée si l'instruction a été exécutée pendant au moins le nombre de millisecondes spécifié. Définir ce paramètre sur 0 consigne toutes les instructions et durées. Si vous définissez cette valeur sur -1, la journalisation de la durée est désactivée.
log_min_duration_sample Échantillonne les instructions terminées qui s'exécutent pendant au moins le nombre de millisecondes spécifié, au taux défini par log_statement_sample_rate. Si vous le définissez sur -1, la journalisation de la durée échantillonnée est désactivée.
log_statement_sample_rate Spécifie la fraction des instructions dépassant log_min_duration_sample qui sont consignées (0.0 à 1.0).
log_transaction_sample_rate Spécifie la fraction des transactions dont toutes les instructions sont consignées (0.0 à 1.0), quelle que soit la durée d'exécution de l'instruction.
log_statement Contrôle les instructions SQL qui sont consignées : none (désactivé), ddl (toutes les commandes de définition de données), mod (LDD plus les instructions de modification de données telles que INSERT, UPDATE et DELETE) ou all.
log_duration Enregistre la durée de chaque instruction terminée. Le texte de la requête n'est pas imprimé, sauf si le seuil log_min_duration_statement est également dépassé.
log_line_prefix Spécifie le préfixe de style printf au début de chaque ligne de journal (par exemple, %m pour le code temporel, %p pour l'ID de processus, %u pour l'utilisateur et %d pour la base de données).
log_connections Détermine si les connexions client à la base de données sont consignées.
log_disconnections Détermine si les fins de session et les durées de session sont enregistrées.
log_hostname Contrôle si le nom d'hôte du client qui se connecte est consigné en plus de son adresse IP.
log_error_verbosity Contrôle le niveau de détail des messages de journal du serveur : terse, default ou verbose (inclut le code SQLSTATE et les lignes sources).
log_lock_waits Contrôle si un message est consigné lorsqu'une session attend plus de deadlock_timeout pour acquérir un verrou.
log_lock_failures Détermine si un message est consigné en cas d'échec de l'acquisition d'un verrou (par exemple, lors de l'utilisation de SELECT ... NOWAIT).
log_checkpoints Enregistre les points de contrôle et les points de redémarrage dans le journal, y compris les statistiques d'écriture du tampon et le temps d'exécution.
log_autovacuum_min_duration Enregistre chaque action exécutée par autovacuum si elle a duré au moins le nombre de millisecondes spécifié. Définir ce paramètre sur 0 consigne toutes les actions. La définition de cette valeur sur -1 désactive la journalisation.
log_temp_files Contrôle la journalisation des noms et des tailles des fichiers temporaires en kilo-octets lorsqu'ils sont supprimés (pour les tris, les hachages ou les résultats de requête). Définir ce paramètre sur 0 consigne tous les fichiers temporaires. La définition de cette valeur sur -1 désactive la journalisation.
log_parameter_max_length Réduit les valeurs des paramètres de liaison consignées dans les journaux d'instructions sans erreur à ce nombre d'octets. Si vous définissez ce paramètre sur -1, les valeurs sont enregistrées dans leur intégralité. La définir sur 0 désactive la journalisation des paramètres.
log_parameter_max_length_on_error Réduit les valeurs des paramètres de liaison signalées dans les messages d'erreur à ce nombre d'octets. Définir ce paramètre sur 0 désactive les paramètres dans les messages d'erreur. Si vous la définissez sur -1, les valeurs sont enregistrées dans leur intégralité.
log_replication_commands Contrôle si les commandes de réplication et les actions d'emplacement de réplication sont consignées.
log_recovery_conflict_waits Contrôle si un message est consigné lorsque le processus de démarrage attend plus de deadlock_timeout pour les conflits de récupération.
log_startup_progress_interval Définit le délai en millisecondes entre les messages de progression pour les opérations de démarrage de longue durée. Définir ce paramètre sur 0 le désactive.
log_timezone Définit le fuseau horaire utilisé pour les codes temporels dans les journaux de serveur.

Gérer les journaux d'audit avec pgAudit

Pour activer la journalisation des accès aux sessions et aux objets, vous devez configurer les paramètres pgAudit dans votre cluster de bases de données et installer l'extension dans vos bases de données.

Étape 1 : Configurez les paramètres pgAudit dans le fichier manifeste DBCluster

Pour collecter les journaux d'accès aux sessions et aux objets dans le fichier postgresql.audit, activez pgAudit et configurez les instructions à consigner à l'aide du paramètre pgaudit.log.

Ajoutez les lignes suivantes à la section parameters du fichier v1_dbcluster_parameters.yaml :

alloydb.enable_pgaudit: "on"
pgaudit.log: "all"

L'exemple suivant montre cette configuration dans le fichier manifeste DBCluster :

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
spec:
  databaseVersion: "18.4.0"
  primarySpec:
    ...
    parameters:
      ...
      alloydb.enable_pgaudit: "on"
      pgaudit.log: "all"

Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données.

Pour en savoir plus, consultez pgaudit dans Extensions de base de données compatibles.

Étape 2 : Installez l'extension pgAudit dans chaque base de données

Après avoir configuré les paramètres et redémarré la base de données, connectez-vous à votre base de données et installez l'extension pgAudit :

CREATE EXTENSION IF NOT EXISTS pgaudit;

Exécutez cette commande dans chaque base de données où vous souhaitez activer la journalisation d'audit. Cette commande installe les déclencheurs d'événements requis pour l'audit LDD.

Paramètres pgAudit compatibles

Le tableau suivant décrit les principaux paramètres pgAudit que vous pouvez configurer dans la section parameters de votre spécification DBCluster. Pour en savoir plus, consultez la documentation pgAudit.

Paramètre Description Valeur par défaut
pgaudit.log Spécifie les classes d'instructions consignées par la journalisation d'audit de session. Les valeurs valides sont none, all, read, write, function, role, ddl, misc et misc_set. none
pgaudit.log_catalog Indique que la journalisation de session est activée si toutes les relations d'une instruction se trouvent dans pg_catalog. La désactivation de cette option réduit le bruit des journaux des clients de base de données. on
pgaudit.log_parameter Spécifie que la journalisation d'audit inclut les paramètres transmis avec l'instruction. off
pgaudit.log_relation Indique si l'audit de session crée une entrée de journal distincte pour chaque relation (telle que des tables et des vues) référencée dans une instruction SELECT ou LMD. off
pgaudit.log_rows Spécifie que la journalisation d'audit inclut le nombre de lignes récupérées ou affectées par une instruction. off
pgaudit.log_statement Indique si la journalisation inclut le texte et les paramètres de l'instruction. on
pgaudit.role Spécifie le rôle principal à utiliser pour la journalisation d'audit des objets. Aucun

Les journaux de serveur PostgreSQL sont toujours collectés dans le fichier postgresql.log et ne nécessitent pas l'activation de pgAudit.

Récupérer le chemin d'accès au journal d'audit actif

Utilisez la fonction SQL alloydb_audit_current_logfile pour afficher le chemin d'accès au fichier journal d'audit. Si l'audit est désactivé, le résultat est NULL.

SELECT alloydb_audit_current_logfile();

 alloydb_audit_current_logfile
----------------------------------
 /obs/diagnostic/postgresql.audit

Transférer les journaux de base de données vers un récepteur centralisé

AlloyDB Omni écrit les journaux du serveur de base de données (postgresql.log), les journaux d'audit (postgresql.audit) et les journaux internes (postgresql.internal) dans le répertoire /obs/diagnostic/ du volume obsdisk dans le conteneur de base de données.

Pour transférer ces journaux vers un récepteur de journalisation centralisée (tel que Cloud Logging, Datadog, Splunk ou Elasticsearch), vous pouvez déployer un conteneur side-car à l'aide de la ressource personnalisée (CR) Sidecar.

Le conteneur side-car s'exécute dans le même pod que la base de données, installe le volume de journaux (obsdisk) et suit les fichiers journaux pour les transférer vers votre destination de journalisation.

Exemple : Transférer des journaux à l'aide d'un side-car Fluent Bit

L'exemple suivant montre comment utiliser un side-car Fluent Bit pour suivre tous les fichiers journaux AlloyDB Omni et les écrire dans la sortie standard. Les collecteurs de journaux de cluster Kubernetes standards, tels que l'agent Logging sur Google Kubernetes Engine (GKE), peuvent ensuite collecter ces journaux.

  1. Créez un ConfigMap contenant la configuration Fluent Bit pour suivre les fichiers journaux du serveur, d'audit et internes :

    apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentbit-config
  namespace: NAMESPACE
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush        1
        Daemon       Off
        Log_Level    info

    [INPUT]
        Name         tail
        Path         /obs/diagnostic/postgresql.log,/obs/diagnostic/postgresql.audit,/obs/diagnostic/postgresql.internal
        Tag          alloydb.*
        Path_Key     filename
        DB           /tmp/fluent-bit.db

    [OUTPUT]
        Name         stdout
        Match        *

    Remplacez NAMESPACE par l'espace de noms de votre cluster de base de données.

  2. Créez un fichier manifeste Sidecar qui définit le conteneur Fluent Bit et installe le volume obsdisk (contenant les journaux AlloyDB Omni) et le volume ConfigMap :

    apiVersion: alloydbomni.dbadmin.goog/v1
kind: Sidecar
metadata:
  name: logging-forwarder
  namespace: NAMESPACE
spec:
  additionalVolumes:
  - name: fluentbit-config-volume
    configMap:
      name: fluentbit-config
  sidecars:
  - name: fluent-bit
    image: fluent/fluent-bit:3.0
    command: ["/fluent-bit/bin/fluent-bit"]
    args: ["-c", "/fluent-bit/etc/fluent-bit.conf"]
    volumeMounts:
    - name: obsdisk
      mountPath: /obs
    - name: fluentbit-config-volume
      mountPath: /fluent-bit/etc/

    Remplacez NAMESPACE par l'espace de noms de votre cluster de base de données.

  3. Mettez à jour votre fichier manifeste DBCluster pour référencer le side-car, ou appliquez un correctif au cluster à l'aide de la commande suivante :

    kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -p '{"spec":{"primarySpec":{"sidecarRef":{"name":"logging-forwarder"}}}}' --type=merge

    Remplacez les éléments suivants :

    • DB_CLUSTER_NAME : nom de votre cluster de bases de données.
    • NAMESPACE : espace de noms de votre cluster de bases de données.

    Pour en savoir plus sur la gestion des side-cars, consultez Configurer un conteneur side-car.

Interroger l'historique de rotation des journaux avec SQL

Lors de la rotation des fichiers journaux, l'opérateur stocke les fichiers archivés dans le répertoire /obs/diagnostic/archive/ avec leurs codes temporels de rotation au format postgresql-%Y-%m-%d_%H%M%S.EXTENSION.gz.

Vous pouvez interroger l'heure de la dernière rotation des journaux directement à partir de la base de données à l'aide des fonctions standards du système de fichiers PostgreSQL.

Inspecter les codes temporels de rotation à partir des noms de fichiers journaux archivés

Pour afficher les rotations de journaux les plus récentes et leurs codes temporels de rotation UTC analysés, exécutez la requête suivante :

SELECT
  file,
  to_timestamp(
    substring(file from 'postgresql-([0-9]{4}-[0-9]{2}-[0-9]{2}_[0-9]{6})') || '+00',
    'YYYY-MM-DD_HH24MISS+TZH'
  ) AS rotated_at
FROM pg_ls_dir('/obs/diagnostic/archive') AS file
WHERE file ~ '^postgresql-[0-9]{4}-[0-9]{2}-[0-9]{2}_[0-9]{6}'
ORDER BY rotated_at DESC
LIMIT 5;

Le résultat ressemble à ce qui suit :

                   file                   |       rotated_at
------------------------------------------+------------------------
 postgresql-2026-09-29_171900.internal.gz | 2026-09-29 17:19:00+00
 postgresql-2026-09-29_072800.log.gz      | 2026-09-29 07:28:00+00
 postgresql-2026-09-28_175300.log.gz      | 2026-09-28 17:53:00+00
 postgresql-2026-09-28_093400.log.gz      | 2026-09-28 09:34:00+00
 postgresql-2026-09-28_092000.audit.gz    | 2026-09-28 09:20:00+00
(5 rows)

Étapes suivantes