AlloyDB Omni-Protokollrotation konfigurieren

Wählen Sie eine Dokumentationsversion aus:

In diesem Dokument wird beschrieben, wie Sie den Wechsel von AlloyDB Omni-Diagnoselogs konfigurieren, wenn Sie den AlloyDB Omni Kubernetes-Operator verwenden.

Die folgenden Protokolldateien befinden sich im Verzeichnis /obs/diagnostic/:

  1. postgresql.audit: In dieser Logdatei werden Audit-Logs für Sitzungs- und Objektzugriff erfasst. Damit Audit-Logs erfasst werden können, müssen Sie Audit-Logs aktivieren.

  2. postgresql.log: In dieser Logdatei werden PostgreSQL-Serverlogs erfasst. Diese Logs werden immer erfasst und müssen nicht aktiviert werden.

Wenn eine Logdatei rotiert wird, geschieht Folgendes:

  1. Die Logdatei wird in das Verzeichnis /obs/diagnostic/archive/ kopiert. Wenn in diesem Verzeichnis eine Logdatei mit demselben Namen vorhanden ist, wird sie überschrieben.

  2. Der Inhalt der ursprünglichen rotierten Protokolldatei wird gelöscht, sodass die Datei leer ist.

  3. Loginformationen werden sofort in die leere rotierte Logdatei geschrieben. Loginformationen werden in die Logdatei geschrieben, bis die Datei einen Größen- oder Altersgrenzwert erreicht. Dann wird sie wieder rotiert. Logs werden rotiert, damit sie nicht zu groß werden.

Standardmäßig wird jede Logdatei rotiert, wenn ihre Größe 200 MB erreicht. Die Standardrotation enthält keine Altersangabe.

Archivierte Dateien werden 7 Tage lang aufbewahrt. Archivierte Dateien, die älter als 7 Tage sind, werden automatisch entfernt. Das gilt jedoch nicht für die Datei, die bei der letzten Rotation archiviert wurde. Wenn log_rotation_age beispielsweise älter als 7 Tage ist, wird die 7-Tage-Grenze für die archivierte Datei vor der Rotation der aktuellen Datei erreicht. In diesem Fall wird die archivierte Datei erst entfernt, wenn bei der nächsten Rotation eine neue archivierte Datei generiert wird.

Jeder rotierte Logdateiname folgt diesem Format: postgresql-%Y-%m-%d_%H%M%S.log. Der Zeitstempel wird zum Zeitpunkt der Logrotation ermittelt und in koordinierter Weltzeit (UTC) angegeben. Wenn das Log beispielsweise am 20.12.2024 um 13:01:02 Uhr UTC rotiert wird, lautet der archivierte Dateiname postgresql-2024-12-20_130102.log.

Jede archivierte Datei wird einzeln mit dem Gzip-Dateiformat komprimiert.

Audit-Logs aktivieren

Wenn Sie das Logging von Sitzungs- und Objektzugriffen aktivieren möchten, müssen Sie pgAudit-Parameter in Ihrem Datenbankcluster konfigurieren und die Erweiterung in Ihren Datenbanken installieren.

Schritt 1: pgAudit in den DBCluster-Parametern konfigurieren

Damit Sitzungs- und Objektzugriffsprotokolle in der Datei postgresql.audit erfasst werden, müssen Sie pgAudit aktivieren und konfigurieren, welche Anweisungen protokolliert werden sollen. Verwenden Sie dazu pgaudit.log.

Fügen Sie dem parameters-Abschnitt der Datei v1_dbcluster_parameters.yaml die folgenden Zeilen hinzu:

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

Das folgende Beispiel zeigt, wie dies im DBCluster-Manifest aussieht:

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"

Weitere Informationen finden Sie unter pgaudit in Unterstützte Datenbankerweiterungen.

Schritt 2: pgAudit-Erweiterung in der Datenbank erstellen

Nachdem Sie die Parameter konfiguriert und dafür gesorgt haben, dass die Datenbank neu gestartet wurde, müssen Sie eine Verbindung zu Ihrer Datenbank herstellen und die pgAudit-Erweiterung installieren:

CREATE EXTENSION IF NOT EXISTS pgaudit;

Sie müssen diesen Befehl in jeder Datenbank ausführen, in der Sie die Überwachungsprotokollierung aktivieren möchten. Dieser Schritt ist erforderlich, um die für die DDL-Prüfung erforderlichen Ereignistrigger zu installieren.

pgAudit-Parameter (GUCs)

In der folgenden Tabelle werden wichtige GUC-Parameter (Grand Unified Configuration) für pgAudit beschrieben, die Sie im Abschnitt parameters Ihrer DBCluster-Spezifikation konfigurieren können. Weitere Informationen finden Sie in der pgAudit-Dokumentation.

Parameter Beschreibung Standardwert
pgaudit.log Gibt an, welche Klassen von Anweisungen durch die Sitzungsprotokollierung protokolliert werden. Gültige Werte sind none, all, read, write, function, role, ddl, misc, misc_set. none
pgaudit.log_catalog Gibt an, dass die Sitzungsprotokollierung aktiviert ist, wenn alle Beziehungen in einer Anweisung in pg_catalog sind. Wenn Sie diese Option deaktivieren, wird die Anzahl der Logeinträge von Datenbankclients reduziert. on
pgaudit.log_parameter Gibt an, dass das Audit-Logging die mit der Anweisung übergebenen Parameter umfasst. off
pgaudit.log_relation Gibt an, ob bei der Sitzungsüberprüfung für jede Beziehung (Tabelle, Ansicht usw.), auf die in einer SELECT- oder DML-Anweisung verwiesen wird, ein separater Logeintrag erstellt wird. off
pgaudit.log_rows Gibt an, dass das Audit-Logging die Anzahl der Zeilen enthält, die durch eine Anweisung abgerufen oder betroffen sind. off
pgaudit.log_statement Gibt an, ob die Protokollierung den Anweisungstext und die Parameter umfasst. on
pgaudit.role Gibt die primäre Rolle an, die für die Objekt-Audit-Protokollierung verwendet werden soll. Keine

PostgreSQL-Serverlogs werden immer in der Datei postgresql.log erfasst und erfordern keine Aktivierung von pgAudit.

Pfad der Audit-Logdatei ansehen

Verwenden Sie die SQL-Funktion alloydb_audit_current_logfile, um den Pfad der Audit-Logdatei aufzurufen. Wenn die Prüfung deaktiviert ist, ist das Ergebnis NULL.

SELECT alloydb_audit_current_logfile();

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

Logrotation konfigurieren

Wenn Sie mehr Kontrolle darüber haben möchten, wann Logs rotiert werden, können Sie eine maximale Dateigröße, eine Dauer zwischen Logrotationen oder beides konfigurieren. Die Dauer zwischen Log-Rotationen wird auch als Alter des Logs bezeichnet. Wenn Sie beide Einstellungen verwenden, wird jedes Log rotiert, wenn es einen der Grenzwerte erreicht.

Um die Logrotation zu konfigurieren, legen Sie einen oder beide der folgenden Parameter im Abschnitt parameters des DBCluster-Manifests fest:

  • log_rotation_size: „SIZE_IN_KB“
  • log_rotation_age: „AGE_IN_MINUTES“

Wenn Sie eine der Einstellungen für die Logrotation deaktivieren möchten, setzen Sie sie auf null ("0"). Wenn Sie die Standardeinstellung beibehalten möchten, dass Logs rotiert werden, wenn ihre Dateigröße 200 MB erreicht, legen Sie keinen der beiden Parameter fest.

Beispiel für maximale Loggröße und ‑dauer bei der Logrotation

Im folgenden Beispiel werden Logs so festgelegt, dass sie rotiert werden, wenn ihre Dateigröße 400 MB erreicht oder wenn die Zeit zwischen den Logrotationen einen Tag erreicht, je nachdem, was zuerst eintritt:

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

Beispiel für die maximale Loggröße bei der Logrotation

Im folgenden Beispiel wird festgelegt, dass Logs rotiert werden, wenn ihre Dateigröße 400 MB erreicht:

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

Beispiel für die Dauer der Logrotation

Im folgenden Beispiel werden Logs alle 24 Stunden rotiert:

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

Audit-Logs an eine zentrale Senke weiterleiten

AlloyDB Omni schreibt Audit-Logs in die Datei /obs/diagnostic/postgresql.audit im Datenbankcontainer. Wenn Sie diese Logs an eine zentrale Logging-Senke (z. B. Cloud Logging, Datadog, Splunk oder Elasticsearch) weiterleiten möchten, können Sie einen Sidecar-Container mit der benutzerdefinierten Ressource (Custom Resource, CR) Sidecar bereitstellen.

Der Sidecar-Container wird im selben Pod wie die Datenbank ausgeführt, stellt das Log-Volume (obsdisk) bereit und liest die Logdatei, um sie an Ihr Logziel weiterzuleiten.

Beispiel: Logs mit einem Fluent Bit-Sidecar weiterleiten

Im folgenden Beispiel wird gezeigt, wie Sie einen Fluent Bit-Sidecar verwenden, um pgAudit-Logs zu erfassen und in die Standardausgabe auszugeben, wo sie von Standard-Kubernetes-Cluster-Log-Collectors (z. B. demGoogle Cloud Logging-Agent in Google Kubernetes Engine (GKE)) erfasst werden können.

  1. ConfigMap für die Fluent Bit-Konfiguration erstellen:

    Erstellen Sie eine ConfigMap mit der Fluent Bit-Konfiguration zum Tailen des Audit-Logs.

    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        *

    Ersetzen Sie NAMESPACE durch den Namespace Ihres Datenbankclusters.

  2. Benutzerdefinierte Sidecar-Ressource erstellen:

    Erstellen Sie ein Sidecar-Manifest, das den Fluent Bit-Container definiert und sowohl das obsdisk-Volume (mit AlloyDB Omni-Logs) als auch das ConfigMap-Volume bereitstellt.

    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. Sidecar-Container beim Datenbankcluster registrieren:

    Aktualisieren Sie Ihr DBCluster-Manifest, um auf den Sidecar zu verweisen, oder patchen Sie den Cluster mit dem folgenden Befehl:

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

    Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters.

    Weitere Informationen zum Verwalten von Sidecars finden Sie unter Sidecar-Container konfigurieren.

Nächste Schritte