Cette page décrit la version 17.7.0 d'AlloyDB Omni à l'aide de l'option de déploiement orchestrateur de conteneurs. Choisissez une autre option de déploiement.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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 AlloyDB Omni Kubernetes.

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

postgresql.audit : Ce fichier journal collecte les journaux d'audit des accès aux sessions et aux objets. Pour collecter les journaux d'audit, vous devez les activer.
postgresql.log : ce fichier journal collecte les journaux du serveur PostgreSQL. Ces journaux sont toujours collectés et n'ont pas besoin d'être activés.

Lorsqu'un fichier journal est permuté, les événements suivants se produisent :

Le fichier journal est copié dans le répertoire /obs/diagnostic/archive/. Si un fichier journal portant le même nom existe dans ce répertoire, il est écrasé.
Le contenu du fichier journal permuté d'origine est supprimé pour que le fichier soit vide.
Les informations de journal sont immédiatement écrites dans le fichier journal vide et permuté. Les informations de journal sont écrites dans le fichier journal jusqu'à ce que le fichier atteigne un seuil de taille ou d'âge, auquel cas il est à nouveau alterné. Les journaux sont soumis à une rotation pour ne pas devenir trop volumineux.

Par défaut, le paramètre de rotation est défini de sorte que chaque fichier journal effectue 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 de plus de sept jours sont automatiquement supprimés, à l'exception de celui qui a été archivé lors de la dernière rotation. Par exemple, si log_rotation_age a plus de sept jours, le fichier archivé atteint le seuil de sept jours avant la rotation du fichier actuel. Dans ce cas, le fichier archivé n'est pas supprimé tant que la rotation suivante ne génère pas un nouveau fichier archivé.

Le nom de fichier de chaque journal permuté suit le format postgresql-%Y-%m-%d_%H%M%S.log. L'horodatage est déterminé au moment de la rotation des journaux et est exprimé en temps universel coordonné (UTC). Par exemple, si le journal est permuté le 20/12/2024 à 13:01:02 UTC, le nom de fichier archivé est postgresql-2024-12-20_130102.log.

Chaque fichier archivé est compressé individuellement au format Gzip.

Activer les journaux d'audit

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 pgAudit dans les paramètres DBCluster

Pour que les journaux d'accès aux sessions et aux objets soient collectés dans le fichier postgresql.audit, vous devez activer pgAudit et configurer les instructions à enregistrer à l'aide de pgaudit.log.

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

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

Voici un exemple de ce à quoi cela ressemble dans le fichier manifeste DBCluster :

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

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

Étape 2 : Créer l'extension pgAudit dans la base de données

Après avoir configuré les paramètres et vous être assuré que la base de données a redémarré, vous devez vous connecter à votre base de données et installer l'extension pgAudit :

CREATE EXTENSION IF NOT EXISTS pgaudit;

Vous devez exécuter cette commande dans chaque base de données pour laquelle vous souhaitez activer la journalisation d'audit. Cette étape est nécessaire pour installer les déclencheurs d'événements requis pour l'audit LDD.

Paramètres pgAudit (GUC)

Le tableau suivant décrit les principaux paramètres GUC (Grand Unified Configuration) 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`	Spécifie 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`	Indique 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 (table, vue, etc.) référencée dans une instruction `SELECT` ou LMD.	`off`
`pgaudit.log_rows`	Indique que la journalisation d'audit inclut le nombre de lignes récupérées ou affectées par une instruction.	`off`
`pgaudit.log_statement`	Spécifie 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 du serveur PostgreSQL sont toujours collectés dans le fichier postgresql.log et ne nécessitent pas l'activation de pgAudit.

Afficher le chemin d'accès au fichier journal d'audit

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

Configurer la rotation des journaux

Si vous souhaitez mieux contrôler le moment où les journaux sont permutés, configurez une taille de fichier maximale, une durée entre les permutations de journaux, ou les deux. La durée entre les rotations des journaux est également appelée l'âge du journal. Si vous utilisez les deux paramètres, chaque journal est permuté lorsqu'il atteint l'un des seuils.

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

log_rotation_size : "SIZE_IN_KB"
log_rotation_age : "AGE_IN_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.

Exemple de taille et de durée maximales de la rotation des journaux

Les exemples suivants définissent la rotation des journaux lorsque la taille de leur fichier atteint 400 Mo ou lorsque le temps entre les rotations de journaux atteint un jour, selon ce 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

Exemple de taille maximale du journal pour la rotation des journaux

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

Exemple de durée de rotation des journaux

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

Transférer les journaux d'audit vers un récepteur centralisé

AlloyDB Omni écrit les journaux d'audit dans le fichier /obs/diagnostic/postgresql.audit à l'intérieur du conteneur de base de données. Si vous souhaitez transférer ces journaux vers un récepteur de journaux centralisé (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, monte le volume de journaux (obsdisk) et suit le fichier journal pour le 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 les journaux pgAudit et les afficher dans la sortie standard, où ils peuvent être collectés par les collecteurs de journaux de cluster Kubernetes standards (tels que l'agent de journalisationGoogle Cloud sur Google Kubernetes Engine (GKE)).

Créez un ConfigMap pour la configuration Fluent Bit :

Créez un ConfigMap contenant la configuration Fluent Bit pour suivre le journal d'audit.

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.audit
        Tag          pgaudit
        DB           /tmp/fluent-bit-pgaudit.db

    [OUTPUT]
        Name         stdout
        Match        *

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

Créez la ressource personnalisée Sidecar :

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: pgaudit-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/

Enregistrez le side-car avec votre cluster de bases de données :

Mettez à jour votre fichier manifeste DBCluster pour référencer le side-car ou corrigez le cluster à l'aide de la commande suivante :
```
kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"primarySpec":{"sidecarRef":{"name":"pgaudit-forwarder"}}}}' --type=merge
```
Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données.

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