En esta página, se documenta la versión 17.7.0 de AlloyDB Omni con la opción de implementación del orquestador de contenedores. Elige otra opción de implementación.

Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Configura la rotación de registros de AlloyDB Omni

Selecciona una versión de la documentación:

En este documento, se describe cómo configurar la rotación de los registros de diagnóstico de AlloyDB Omni cuando usas el operador de Kubernetes de AlloyDB Omni.

Los siguientes archivos de registro se encuentran en el directorio /obs/diagnostic/:

postgresql.audit: Este archivo de registro recopila registros de auditoría de acceso a objetos y sesiones. Para recopilar registros de auditoría, debes habilitarlos.
postgresql.log: Este archivo de registro recopila registros del servidor de PostgreSQL. Estos registros siempre se recopilan y no es necesario habilitarlos.

Cuando se rota un archivo de registro, sucede lo siguiente:

El archivo de registro se copia en el directorio /obs/diagnostic/archive/. Si existe un archivo de registro con el mismo nombre en ese directorio, se reemplazará.
Se borra el contenido del archivo de registro rotado original para que el archivo esté vacío.
La información de registro comienza a escribirse de inmediato en el archivo de registro rotado vacío. La información de registro se escribe en el archivo de registro hasta que este alcanza un umbral de tamaño o antigüedad, momento en el que vuelve a rotar. Los registros rotan para que no se vuelvan demasiado grandes.

De forma predeterminada, la configuración de rotación es para que cada archivo de registro rote cuando su tamaño alcanza los 200 MB. La rotación predeterminada no incluye una configuración de antigüedad.

Los archivos archivados se conservan durante 7 días. Los archivos archivados que tienen más de 7 días se quitan automáticamente, excepto el archivo que se archivó durante la última rotación. Por ejemplo, si log_rotation_age tiene más de 7 días, el archivo archivado alcanza el umbral de 7 días antes de la rotación del archivo actual. En este caso, este archivo archivado no se quita hasta que la próxima rotación genere un archivo archivado nuevo.

Cada nombre de archivo de registro rotado sigue este formato: postgresql-%Y-%m-%d_%H%M%S.log. La marca de tiempo se determina en el momento de la rotación del registro y se expresa en la hora universal coordinada (UTC). Por ejemplo, si el registro se rota a las 13:01:02 del 20/12/2024 UTC, el nombre de archivo archivado es postgresql-2024-12-20_130102.log.

Cada archivo archivado se comprime de forma individual con el formato de archivo Gzip.

Habilita registros de auditoría

Para habilitar el registro de acceso a objetos y sesiones, debes configurar los parámetros de pgAudit en tu clúster de base de datos y, luego, instalar la extensión en tus bases de datos.

Paso 1: Configura pgAudit en los parámetros de DBCluster

Para que los registros de acceso a objetos y sesiones se recopilen en el archivo postgresql.audit, debes habilitar pgAudit y configurar qué instrucciones registrar con pgaudit.log.

Agrega las siguientes líneas a la parameters sección del v1_dbcluster_parameters.yaml archivo:

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

El siguiente es un ejemplo de cómo se ve esto en el manifiesto de 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"

Para obtener más información, consulta pgaudit en Extensiones de bases de datos compatibles.

Paso 2: Crea la extensión pgAudit en la base de datos

Después de configurar los parámetros y asegurarte de que se reinició la base de datos, debes conectarte a ella y, luego, instalar la extensión pgAudit:

CREATE EXTENSION IF NOT EXISTS pgaudit;

Debes ejecutar este comando en cada base de datos en la que quieras habilitar el registro de auditoría. Este paso es necesario para instalar los activadores de eventos necesarios para la auditoría de DDL.

Parámetros de pgAudit (GUCs)

En la siguiente tabla, se describen los parámetros clave de configuración unificada general (GUC) de pgAudit que puedes configurar en la sección parameters de tu especificaciónDBCluster Para obtener más información, consulta la documentación de pgAudit.

Parámetro	Descripción	Valor predeterminado
`pgaudit.log`	Especifica qué clases de instrucciones se registran mediante el registro de auditoría de sesión. Los valores válidos son `none`, `all`, `read`, `write`, `function`, `role`, `ddl`, `misc`, `misc_set`.	`none`
`pgaudit.log_catalog`	Especifica que el registro de sesión está habilitado si todas las relaciones de una instrucción están en `pg_catalog`. Si inhabilitas esta opción, se reduce el ruido de registro de los clientes de la base de datos.	`on`
`pgaudit.log_parameter`	Especifica que el registro de auditoría incluye los parámetros que se pasan con la instrucción.	`off`
`pgaudit.log_relation`	Especifica si la auditoría de sesión crea una entrada de registro separada para cada relación (tabla, vista, etcétera) a la que se hace referencia en una instrucción `SELECT` o sentencia DML.	`off`
`pgaudit.log_rows`	Especifica que el registro de auditoría incluye la cantidad de filas recuperadas o afectadas por una instrucción.	`off`
`pgaudit.log_statement`	Especifica si el registro incluye el texto y los parámetros de la instrucción.	`on`
`pgaudit.role`	Especifica el rol principal que se usará para el registro de auditoría de objetos.	Ninguno

Los registros del servidor de PostgreSQL siempre se recopilan en el archivo postgresql.log y no requieren habilitar pgAudit.

Consulta la ruta de acceso del archivo de registro de auditoría

Usa la función SQL alloydb_audit_current_logfile para ver la ruta de acceso del archivo de registro de auditoría. Si la auditoría está inhabilitada, el resultado es NULL.

SELECT alloydb_audit_current_logfile();

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

Configura la rotación del registro

Si deseas tener más control sobre cuándo rotan los registros, configura un tamaño máximo de archivo, una duración entre las rotaciones de registros o ambos. La duración entre las rotaciones de registros también se denomina antigüedad del registro. Si usas ambas configuraciones, cada registro rota cuando alcanza uno de los umbrales.

Para configurar la rotación del registro, establece uno o ambos de los siguientes parámetros en la sección parameters del manifiesto de DBCluster:

log_rotation_size: "SIZE_IN_KB"
log_rotation_age: "AGE_IN_MINUTES"

Para inhabilitar una de las configuraciones de rotación del registro, establécela en cero, "0". Para conservar la configuración predeterminada que rota los registros cuando su tamaño de archivo alcanza los 200 MB, no establezcas ningún parámetro.

Ejemplo de tamaño máximo y duración de la rotación de registros

En el siguiente ejemplo, se establece que los registros roten cuando su tamaño de archivo alcance los 400 MB o cuando el tiempo entre las rotaciones de registros alcance un día, lo que ocurra primero:

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

Ejemplo de tamaño máximo de la rotación de registros

En el siguiente ejemplo, se establece que los registros roten cuando su tamaño de archivo alcance los 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

Ejemplo de duración de la rotación de registros

En el siguiente ejemplo, se establece que los registros roten una vez cada 24 horas:

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

Reenvía registros de auditoría a un receptor centralizado

AlloyDB Omni escribe registros de auditoría en el archivo /obs/diagnostic/postgresql.audit dentro del contenedor de la base de datos. Si deseas reenviar estos registros a un receptor de registro centralizado (como Cloud Logging, Datadog, Splunk o Elasticsearch), puedes implementar un contenedor de sidecar con el recurso personalizado (CR) Sidecar.

El contenedor sidecar se ejecuta en el mismo Pod que la base de datos, activa el volumen de registro (obsdisk) y visualiza el archivo de registro para reenviarlo a tu destino de registro.

Ejemplo: Reenvío de registros con un sidecar de Fluent Bit

En el siguiente ejemplo, se muestra cómo usar un sidecar de Fluent Bit para visualizar los registros de pgAudit y enviarlos a la salida estándar, donde los recopiladores de registros de clústeres de Kubernetes estándar (como el Google Cloud agente de Logging en Google Kubernetes Engine (GKE)) pueden recopilarlos.

Crea un ConfigMap para la configuración de Fluent Bit:

Crea un ConfigMap que contenga la configuración de Fluent Bit para visualizar el registro de auditoría.

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        *

Reemplaza NAMESPACE por el espacio de nombres de tu clúster de base de datos.

Crea el recurso personalizado Sidecar Custom Resource:

Crea un manifiesto de Sidecar que defina el contenedor de Fluent Bit y active el volumen obsdisk (que contiene registros de AlloyDB Omni) y el volumen de 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/

Registra el sidecar con tu clúster de base de datos:

Actualiza tu manifiesto de DBCluster para hacer referencia al sidecar o aplica un parche al clúster con el siguiente comando:
```
kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"primarySpec":{"sidecarRef":{"name":"pgaudit-forwarder"}}}}' --type=merge
```
Reemplaza DB_CLUSTER_NAME por el nombre de tu clúster de base de datos.

Para obtener más información sobre la administración de sidecars, consulta Configura un contenedor sidecar.