Configura la rotazione dei log di AlloyDB Omni

Seleziona una versione della documentazione:

Questo documento descrive come configurare la rotazione dei log di diagnostica di AlloyDB Omni quando utilizzi l'operatore Kubernetes di AlloyDB Omni.

I seguenti file di log si trovano nella directory /obs/diagnostic/:

  1. postgresql.audit: Questo file di log raccoglie i log di controllo dell'accesso a sessioni e oggetti. Per raccogliere i log di controllo, devi abilitarli.

  2. postgresql.log: questo file di log raccoglie i log del server PostgreSQL. Questi log vengono sempre raccolti e non devono essere abilitati.

Quando un file di log viene ruotato, si verifica quanto segue:

  1. Il file di log viene copiato nella directory /obs/diagnostic/archive/. Se in quella directory esiste un file di log con lo stesso nome, questo viene sovrascritto.

  2. I contenuti del file di log ruotato originale vengono eliminati in modo che il file sia vuoto.

  3. Le informazioni del log iniziano immediatamente a essere scritte nel file di log ruotato vuoto. Le informazioni di log vengono scritte nel file di log fino a quando il file non raggiunge una soglia di dimensione o età, a quel punto viene nuovamente ruotato. I log vengono ruotati in modo che non diventino troppo grandi.

Per impostazione predefinita, l'impostazione di rotazione prevede che ogni file di log ruoti quando le sue dimensioni raggiungono i 200 MB. La rotazione predefinita non include un'impostazione dell'età.

I file archiviati vengono conservati per 7 giorni. I file archiviati più vecchi di 7 giorni vengono rimossi automaticamente, ad eccezione del file archiviato durante l'ultima rotazione. Ad esempio, se log_rotation_age ha più di 7 giorni, il file archiviato raggiunge la soglia di 7 giorni prima della rotazione del file corrente. In questo caso, il file archiviato non viene rimosso finché la rotazione successiva non genera un nuovo file archiviato.

Ogni nome file di log ruotato segue questo formato: postgresql-%Y-%m-%d_%H%M%S.log. Il timestamp viene determinato al momento della rotazione dei log ed è espresso in Coordinated Universal Time (UTC). Ad esempio, se il log viene ruotato alle 13:01:02 del 20/12/2024 UTC, il nome del file archiviato è postgresql-2024-12-20_130102.log.

Ogni file archiviato viene compresso singolarmente utilizzando il formato di file Gzip.

Abilita audit log

Per attivare la registrazione dell'accesso a sessioni e oggetti, devi configurare i parametri pgAudit nel cluster di database e installare l'estensione nei tuoi database.

Passaggio 1: configura pgAudit nei parametri DBCluster

Affinché i log di accesso a sessioni e oggetti vengano raccolti nel file postgresql.audit, devi abilitare pgAudit e configurare le istruzioni da registrare utilizzando pgaudit.log.

Aggiungi le seguenti righe alla sezione parameters del file v1_dbcluster_parameters.yaml:

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

Di seguito è riportato un esempio di come appare nel manifest 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"

Per ulteriori informazioni, vedi pgaudit in Estensioni di database supportate.

Passaggio 2: crea l'estensione pgAudit nel database

Dopo aver configurato i parametri e verificato il riavvio del database, devi connetterti al database e installare l'estensione pgAudit:

CREATE EXTENSION IF NOT EXISTS pgaudit;

Devi eseguire questo comando in ogni database in cui vuoi abilitare la registrazione audit. Questo passaggio è necessario per installare i trigger evento necessari per il controllo DDL.

Parametri pgAudit (GUC)

La tabella seguente descrive i parametri GUC (Grand Unified Configuration) principali di pgAudit che puoi configurare nella sezione parameters della specifica DBCluster. Per saperne di più, consulta la documentazione di pgAudit.

Parametro Descrizione Valore predefinito
pgaudit.log Specifica quali classi di istruzioni vengono registrate dalla registrazione di controllo della sessione. I valori validi sono none, all, read, write, function, role, ddl, misc, misc_set. none
pgaudit.log_catalog Specifica che la registrazione della sessione è abilitata se tutte le relazioni in un'istruzione si trovano in pg_catalog. La disattivazione di questa opzione riduce il rumore dei log dei client di database. on
pgaudit.log_parameter Specifica che l'audit logging include i parametri passati con l'istruzione. off
pgaudit.log_relation Specifica se il controllo della sessione crea una voce di log separata per ogni relazione (tabella, vista e così via) a cui viene fatto riferimento in un'istruzione SELECT o DML. off
pgaudit.log_rows Specifica che la registrazione degli audit includa il numero di righe recuperate o interessate da un'istruzione. off
pgaudit.log_statement Specifica se la registrazione include il testo e i parametri dell'istruzione. on
pgaudit.role Specifica il ruolo principale da utilizzare per la registrazione degli audit log degli oggetti. Nessuno

I log del server PostgreSQL vengono sempre raccolti nel file postgresql.log e non richiedono l'attivazione di pgAudit.

Visualizzare il percorso del file di log di controllo

Utilizza la funzione SQL alloydb_audit_current_logfile per visualizzare il percorso del file di log di controllo. Se il controllo è disattivato, il risultato è NULL.

SELECT alloydb_audit_current_logfile();

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

Configura la rotazione log

Se vuoi avere un maggiore controllo sulla rotazione dei log, configura una dimensione massima del file, una durata tra le rotazioni dei log o entrambe. La durata tra le rotazioni dei log è chiamata anche età del log. Se utilizzi entrambe le impostazioni, ogni log viene ruotato quando raggiunge una delle soglie.

Per configurare la rotazione dei log, imposta uno o entrambi i seguenti parametri nella sezione parameters del manifest DBCluster:

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

Per disattivare una delle impostazioni di rotazione dei log, impostala su zero, "0". Per mantenere l'impostazione predefinita che ruota i log quando le dimensioni del file raggiungono i 200 MB, non impostare alcun parametro.

Esempio di dimensione e durata massime della rotazione dei log

I seguenti set di esempio impostano la rotazione dei log quando la dimensione del file raggiunge 400 MB o quando il tempo tra le rotazioni dei log raggiunge un giorno, a seconda dell'evento che si verifica per primo:

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

Esempio di dimensione massima del log di rotazione log

Il seguente esempio imposta la rotazione dei log quando le dimensioni del file raggiungono 400 MB:

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

Esempio di durata della rotazione dei log

Il seguente esempio imposta la rotazione dei log una volta ogni 24 ore:

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

Inoltrare gli audit log a un sink centralizzato

AlloyDB Omni scrive i log di controllo nel file /obs/diagnostic/postgresql.audit all'interno del container del database. Se vuoi inoltrare questi log a un sink di logging centralizzato (come Cloud Logging, Datadog, Splunk o Elasticsearch), puoi eseguire il deployment di un container sidecar utilizzando la risorsa personalizzata (CR) Sidecar.

Il container sidecar viene eseguito nello stesso pod del database, monta il volume dei log (obsdisk) e segue il file di log per inoltrarlo alla destinazione di logging.

Esempio: inoltro dei log utilizzando un sidecar fluent bit

L'esempio seguente mostra come utilizzare un sidecar Fluent Bit per seguire i log pgAudit e inviarli all'output standard, dove possono essere raccolti dai raccoglitori di log del cluster Kubernetes standard (come l'agente Logging su Google Kubernetes Engine (GKE)).Google Cloud

  1. Crea un ConfigMap per la configurazione di Fluent Bit:

    Crea un oggetto ConfigMap contenente la configurazione di Fluent Bit per seguire il log di controllo.

    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        *

    Sostituisci NAMESPACE con lo spazio dei nomi del cluster di database.

  2. Crea la risorsa personalizzata Sidecar:

    Crea un manifest Sidecar che definisce il container Fluent Bit e monta sia il volume obsdisk (contenente i log di AlloyDB Omni) sia il 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/

  3. Registra il sidecar con il cluster di database:

    Aggiorna il manifest DBCluster in modo che faccia riferimento al sidecar o applica una patch al cluster utilizzando il seguente comando:

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

    Sostituisci DB_CLUSTER_NAME con il nome del cluster di database.

    Per saperne di più sulla gestione dei sidecar, consulta Configurare un container sidecar.

Passaggi successivi