AlloyDB Omni-Protokollrotation konfigurieren

Wählen Sie eine Dokumentationsversion aus:

In diesem Dokument wird beschrieben, wie Sie die Rotation von AlloyDB Omni-Diagnoseprotokollen konfigurieren, wenn Sie den AlloyDB Omni Kubernetes-Operator verwenden.

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

  • postgresql.log: In dieser Logdatei werden PostgreSQL-Serverlogs wie Clientverbindungen, Abfragen und administrative Hinweise erfasst. Diese Logs werden immer erfasst und müssen nicht aktiviert werden.

  • postgresql.audit: In dieser Logdatei werden Audit-Logs für Sitzungen und Objektzugriffe erfasst. Informationen zum Erfassen von Audit-Logs finden Sie unter Audit-Logs mit pgAudit verwalten.

  • postgresql.internal: AlloyDB Omni bietet zusätzlich zu den regulären PostgreSQL-Logs weitere Meldungen. Diese Meldungen enthalten zusätzliche technische Informationen, die bei der Fehlerbehebung von Datenbankproblemen hilfreich sein können.

Logrotation verstehen und konfigurieren

Hier erfahren Sie, wie AlloyDB Omni den Protokollwechsel handhabt und wie Sie Grenzwerte für den Wechsel basierend auf Dateigröße oder Dauer konfigurieren.

Verhalten bei der Logrotation

Wenn eine Logdatei rotiert, geschieht Folgendes:

  1. Die vorhandene Logdatei wird im Verzeichnis /obs/diagnostic/archive/ archiviert.

  2. Die aktive Logdatei in /obs/diagnostic/ wird zurückgesetzt, sodass nachfolgende Logeinträge in eine neue Datei geschrieben werden.

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

Standardmäßig wird jede Logdatei rotiert, wenn sie eine Größe von 200 MB erreicht. Die Standardrotation enthält keine Alterseinstellung.

Archivierte Dateien werden 7 Tage lang aufbewahrt. Archivierte Dateien, die älter als 7 Tage sind, werden automatisch entfernt, mit Ausnahme der Datei, die während der letzten Rotation archiviert wurde. Wenn log_rotation_age beispielsweise älter als 7 Tage ist, erreicht die archivierte Datei den Schwellenwert von 7 Tagen vor der Rotation der aktuellen Datei. In diesem Fall wird diese archivierte Datei erst entfernt, wenn bei der nächsten Rotation eine neue archivierte Datei generiert wird.

Jeder rotierte Logdateiname folgt dem Format postgresql-%Y-%m-%d_%H%M%S.EXTENSION.gz, wobei EXTENSION log, audit oder internal ist. Die Rotationszeit bestimmt den Zeitstempel in koordinierter Weltzeit (UTC). Wenn eine Logdatei beispielsweise am 20. Dezember 2024 um 13:01:02 Uhr UTC rotiert, lautet der Name der archivierten Datei postgresql-2024-12-20_130102.log.gz.

Das System komprimiert jede archivierte Datei einzeln im gzip-Dateiformat.

Rotationsschwellenwerte konfigurieren

Wenn Sie festlegen möchten, wann Logs rotiert werden, konfigurieren Sie eine maximale Dateigröße, eine Dauer zwischen Logrotationen oder beides. Die Dauer zwischen Protokollwechseln wird auch als Alter des Logs bezeichnet. Wenn Sie beide Einstellungen verwenden, wird jedes Protokoll rotiert, wenn es einen der Schwellenwerte 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“

Ersetzen Sie Folgendes:

  • SIZE_IN_KB: die maximale Dateigröße in Kilobyte, bevor Logs rotiert werden.
  • AGE_IN_MINUTES: Die Dauer zwischen Log-Rotationen in Minuten.

Wenn Sie eine der Einstellungen für die Logrotation deaktivieren möchten, legen Sie sie auf null fest: "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.

Nach Loggröße und Dauer rotieren

Im folgenden Beispiel werden Logs rotiert, 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

Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters.

Nur nach Loggröße rotieren

Im folgenden Beispiel werden Logs so konfiguriert, dass sie 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

Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters.

Nur nach Dauer rotieren

Im folgenden Beispiel wird festgelegt, dass Logs alle 24 Stunden rotiert werden:

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

Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters.

Ressourcenlimits für die Logrotation konfigurieren

Standardmäßig wird der Container logrotate mit niedrigen Ressourceneinstellungen (50m CPU und 50Mi Arbeitsspeicher) ausgeführt. Bei Datenbankclustern mit hohen Arbeitslasten oder großen Logmengen kann die Logrotation zusätzlichen Arbeitsspeicher erfordern, was zu OOMKilled-Containerneustarts führen kann.

Sie können benutzerdefinierte CPU- und Speicheranforderungen und -limits für Agents der Steuerungsebene unter spec.primarySpec.controlPlaneAgentsResources in Ihrer benutzerdefinierten Ressource DBCluster konfigurieren.

Ressourcenverhalten und Standardwerte

  • Standardeinstellungen: Wenn controlPlaneAgentsResources.logrotate weggelassen wird, wendet der AlloyDB Omni-Operator Standardanfragen von 50m CPU und 50Mi Arbeitsspeicher sowie Standardlimits von 50m CPU und 50Mi Arbeitsspeicher an.
  • Erforderliche Felder: Wenn Sie controlPlaneAgentsResources.logrotate angeben, müssen sowohl requests.cpu als auch requests.memory angegeben werden und größer als 0 sein.
  • Limits: Das Festlegen von Limits ist optional:
    • Wenn Limits angegeben werden, muss jedes Limit größer oder gleich der entsprechenden Anfrage sein.
    • Wenn Limits weggelassen werden, wird der Container nur mit Anfragen ausgeführt, ohne dass ein oberes Limit erzwungen wird. Limits können nicht auf 0 festgelegt werden.

Weitere Informationen zu Kubernetes-Containerressourcenanfragen und -limits finden Sie unter Ressourcenverwaltung für Pods und Container.

Beispiel-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

Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters.

Unterstützte PostgreSQL-Logging-Parameter

Sie können konfigurieren, welche Informationen an postgresql.log ausgegeben werden, indem Sie die GUC-Parameter (Grand Unified Configuration) für das Standard-PostgreSQL-Logging im Abschnitt parameters Ihres DBCluster-Manifests festlegen:

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

Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters.

In der folgenden Tabelle werden die unterstützten PostgreSQL-Logging-Parameter basierend auf Error Reporting and Logging in der PostgreSQL-Dokumentation beschrieben.

Parameter Beschreibung
log_min_messages Steuert, welche Meldungsebenen in das Serverlog geschrieben werden. Gültige Werte sind debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal und panic. Jede Stufe umfasst alle folgenden Schweregrade.
log_min_error_statement Steuert, welche SQL-Anweisungen, die eine Fehlerbedingung verursachen, in den Server-Logs aufgezeichnet werden. Gültige Werte sind debug5 bis panic. Wenn Sie das Logging von Anweisungsfehlern deaktivieren möchten, legen Sie den Wert auf panic fest.
log_min_duration_statement Protokolliert die Dauer jeder abgeschlossenen Anweisung, wenn die Anweisung mindestens die angegebene Anzahl von Millisekunden ausgeführt wurde. Wenn Sie diesen Parameter auf 0 setzen, werden alle Anweisungen und Dauern protokolliert. Wenn Sie -1 festlegen, wird das Logging der Dauer deaktiviert.
log_min_duration_sample Es werden Stichproben von abgeschlossenen Anweisungen erfasst, die mindestens die angegebene Anzahl von Millisekunden ausgeführt wurden, und zwar mit der Rate, die durch log_statement_sample_rate festgelegt ist. Wenn Sie den Wert auf -1 setzen, wird das Logging der Stichprobendauer deaktiviert.
log_statement_sample_rate Gibt den Anteil der Anweisungen an, die log_min_duration_sample überschreiten und protokolliert werden (0.0 bis 1.0).
log_transaction_sample_rate Gibt den Anteil der Transaktionen an, deren Anweisungen alle protokolliert werden (0.0 bis 1.0), unabhängig von der Ausführungsdauer der Anweisung.
log_statement Steuert, welche SQL-Anweisungen protokolliert werden: none (aus), ddl (alle Datendefinitionsbefehle), mod (DDL plus datenändernde Anweisungen wie INSERT, UPDATE und DELETE) oder all.
log_duration Protokolliert die Dauer jeder abgeschlossenen Anweisung. Der Abfragetext wird nur ausgegeben, wenn auch der Schwellenwert log_min_duration_statement überschritten wird.
log_line_prefix Gibt die printf-Präfixausgabe am Anfang jeder Protokollzeile an (z. B. %m für Zeitstempel, %p für Prozess-ID, %u für Nutzer und %d für Datenbank).
log_connections Steuert, ob Clientverbindungen zur Datenbank protokolliert werden.
log_disconnections Steuert, ob Sitzungsbeendigungen und Sitzungsdauern protokolliert werden.
log_hostname Steuert, ob der Hostname des verbindenden Clients zusätzlich zu seiner IP-Adresse protokolliert wird.
log_error_verbosity Steuert den Detaillierungsgrad in Server-Logeinträgen: terse, default oder verbose (enthält SQLSTATE-Code und Quellzeilen).
log_lock_waits Steuert, ob eine Meldung protokolliert wird, wenn eine Sitzung länger als deadlock_timeout auf eine Sperre wartet.
log_lock_failures Steuert, ob eine Nachricht protokolliert wird, wenn eine Sperre nicht erworben werden kann (z. B. bei Verwendung von SELECT ... NOWAIT).
log_checkpoints Zeichnet Prüfpunkte und Neustartpunkte im Log auf, einschließlich Statistiken zum Schreiben von Zwischenspeichern und Zeitangaben.
log_autovacuum_min_duration Protokolliert jede von Autovacuum ausgeführte Aktion, wenn sie mindestens die angegebene Anzahl von Millisekunden ausgeführt wurde. Wenn Sie diesen Parameter auf 0 festlegen, werden alle Aktionen protokolliert. Wenn Sie -1 festlegen, wird das Logging deaktiviert.
log_temp_files Steuert die Protokollierung temporärer Dateinamen und ‑größen in Kilobyte beim Löschen (für Sortierungen, Hashes oder Abfrageergebnisse). Wenn Sie diesen Parameter auf 0 setzen, werden alle temporären Dateien protokolliert. Wenn Sie -1 festlegen, wird das Logging deaktiviert.
log_parameter_max_length Kürzt die in Nicht-Fehler-Anweisungslogs protokollierten Bindungsparameterwerte auf diese Anzahl von Byte. Wenn Sie diesen Parameter auf -1 festlegen, werden Werte vollständig protokolliert. Wenn Sie 0 festlegen, wird das Parameter-Logging deaktiviert.
log_parameter_max_length_on_error Schneidet Bindungsparameterwerte, die in Fehlermeldungen gemeldet werden, auf diese Anzahl von Bytes zu. Wenn Sie diesen Parameter auf 0 festlegen, werden Parameter in Fehlermeldungen deaktiviert. Wenn Sie den Wert auf -1 setzen, werden die Werte vollständig protokolliert.
log_replication_commands Steuert, ob Replikationsbefehle und Replikationsslot-Aktionen protokolliert werden.
log_recovery_conflict_waits Steuert, ob eine Nachricht protokolliert wird, wenn der Startvorgang länger als deadlock_timeout auf Wiederherstellungskonflikte wartet.
log_startup_progress_interval Legt die Zeit in Millisekunden zwischen Fortschrittsmeldungen für lang andauernde Startvorgänge fest. Wenn Sie diesen Parameter auf 0 setzen, wird er deaktiviert.
log_timezone Legt die Zeitzone fest, die für Zeitstempel im Serverlog verwendet wird.

Audit-Logs mit pgAudit verwalten

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-Parameter im DBCluster-Manifest konfigurieren

Wenn Sie Sitzungs- und Objektzugriffsprotokolle in der Datei postgresql.audit erfassen möchten, aktivieren Sie pgAudit und konfigurieren Sie mit dem Parameter pgaudit.log, welche Anweisungen protokolliert werden sollen.

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

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

Das folgende Beispiel zeigt diese Konfiguration im DBCluster-Manifest:

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"

Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters.

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

Schritt 2: pgAudit-Erweiterung in jeder Datenbank installieren

Nachdem Sie die Parameter konfiguriert haben und die Datenbank neu gestartet wurde, stellen Sie eine Verbindung zu Ihrer Datenbank her und installieren Sie die pgAudit-Erweiterung:

CREATE EXTENSION IF NOT EXISTS pgaudit;

Führen Sie diesen Befehl in jeder Datenbank aus, in der Sie das Audit-Logging aktivieren möchten. Mit diesem Befehl werden die für die DDL-Überwachung erforderlichen Ereignistrigger installiert.

Unterstützte pgAudit-Parameter

In der folgenden Tabelle werden die wichtigsten pgAudit-Parameter 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 das Audit-Logging von Sitzungen protokolliert werden. Gültige Werte sind none, all, read, write, function, role, ddl, misc und misc_set. none
pgaudit.log_catalog Gibt an, dass das Sitzungs-Logging aktiviert ist, wenn alle Beziehungen in einer Anweisung in pg_catalog enthalten sind. Durch Deaktivieren dieser Option wird das Log-Rauschen von Datenbankclients reduziert. on
pgaudit.log_parameter Gibt an, dass das Audit-Logging die mit der Anweisung übergebenen Parameter enthält. off
pgaudit.log_relation Gibt an, ob bei der Sitzungsüberwachung für jede Beziehung (z. B. Tabellen und Ansichten), 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 von einer Anweisung abgerufen oder betroffen sind. off
pgaudit.log_statement Gibt an, ob das Logging den Anweisungstext und die Parameter enthält. on
pgaudit.role Gibt die primäre Rolle an, die für das Audit-Logging von Objekten verwendet werden soll. Keine

PostgreSQL-Server-Logs werden immer in der Datei postgresql.log erfasst. pgAudit muss dafür nicht aktiviert werden.

Aktiven Audit-Log-Pfad abrufen

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

Datenbanklogs an eine zentrale Senke weiterleiten

AlloyDB Omni schreibt Datenbankserver-Logs (postgresql.log), Audit-Logs (postgresql.audit) und interne Logs (postgresql.internal) in das Verzeichnis /obs/diagnostic/ auf dem Volume obsdisk 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 mithilfe der benutzerdefinierten Ressource (CR) Sidecar bereitstellen.

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

Beispiel: Logs mit einem Fluent Bit-Sidecar weiterleiten

Im folgenden Beispiel wird gezeigt, wie Sie mit einem Fluent Bit-Sidecar alle AlloyDB Omni-Logdateien verfolgen und in die Standardausgabe schreiben. Standardmäßige Kubernetes-Cluster-Log-Collector, z. B. der Logging-Agent in Google Kubernetes Engine (GKE), können diese Logs dann erfassen.

  1. Erstellen Sie eine ConfigMap mit der Fluent Bit-Konfiguration, um Server-, Audit- und interne Logdateien zu verfolgen:

    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        *

    Ersetzen Sie NAMESPACE durch den Namespace Ihres Datenbankclusters.

  2. 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: 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/

    Ersetzen Sie NAMESPACE durch den Namespace Ihres Datenbankclusters.

  3. 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 -n NAMESPACE -p '{"spec":{"primarySpec":{"sidecarRef":{"name":"logging-forwarder"}}}}' --type=merge

    Ersetzen Sie Folgendes:

    • DB_CLUSTER_NAME: der Name Ihres Datenbankclusters.
    • NAMESPACE: der Namespace Ihres Datenbankclusters.

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

Verlauf der Protokollrotation mit SQL abfragen

Wenn Logdateien rotiert werden, speichert der Operator die archivierten Dateien im Verzeichnis /obs/diagnostic/archive/ mit ihren Rotationszeitstempeln im Format postgresql-%Y-%m-%d_%H%M%S.EXTENSION.gz.

Sie können die letzte Logrotation direkt aus der Datenbank abfragen, indem Sie Standard-PostgreSQL-Dateisystemfunktionen verwenden.

Rotationszeitstempel aus archivierten Logdateinamen prüfen

Führen Sie die folgende Abfrage aus, um die letzten Protokollwechsel und die zugehörigen geparsten UTC-Wechselzeitstempel aufzurufen:

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;

Die Ausgabe sieht etwa so aus:

                   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)

Nächste Schritte