Esta página documenta a versão 17.7.0 do AlloyDB Omni usando a opção de implantação do orquestrador de contêineres. Escolha outra opção de implantação.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Configurar a rotação de registro do AlloyDB Omni

Selecione uma versão da documentação:

Neste documento, descrevemos como configurar a rotação dos registros de diagnóstico do AlloyDB Omni ao usar o operador do AlloyDB Omni no Kubernetes.

Os seguintes arquivos de registro estão localizados no diretório /obs/diagnostic/:

postgresql.audit: esse arquivo de registro coleta registros de auditoria de acesso a sessões e objetos. Para coletar registros de auditoria, é necessário ativá-los.
postgresql.log: esse arquivo de registro coleta registros do servidor PostgreSQL. Esses registros são sempre coletados e não precisam ser ativados.

Quando um arquivo de registro é rotacionado, acontece o seguinte:

O arquivo de registro é copiado para o diretório /obs/diagnostic/archive/. Se houver um arquivo de registro com o mesmo nome nesse diretório, ele será substituído.
O conteúdo do arquivo de registro rotacionado original é excluído para que o arquivo fique vazio.
As informações de registro começam a ser gravadas imediatamente no arquivo de registro rotacionado vazio. As informações de registro são gravadas no arquivo de registro até que ele atinja um tamanho ou limite de idade, momento em que ele é rotacionado novamente. Os registros são rotacionados para que não fiquem muito grandes.

Por padrão, a configuração de rotação é para cada arquivo de registro ser rotacionado quando o tamanho atinge 200 MB. A rotação padrão não inclui uma configuração de idade.

Os arquivos arquivados são retidos por sete dias. Os arquivos arquivados com mais de sete dias são removidos automaticamente, exceto o arquivo arquivado durante a última rotação. Por exemplo, se log_rotation_age tiver mais de sete dias, o arquivo arquivado vai atingir o limite de sete dias antes da rotação do arquivo atual. Nesse caso, o arquivo arquivado não será removido até que a próxima rotação gere um novo arquivo arquivado.

Cada nome de arquivo de registro rotacionado segue este formato: postgresql-%Y-%m-%d_%H%M%S.log. O carimbo de data/hora é determinado no momento da rotação de registro e é expresso em Tempo Universal Coordenado (UTC). Por exemplo, se o registro for rotacionado às 13h0min02s de 20/12/2024 UTC, o nome de arquivo arquivado será postgresql-2024-12-20_130102.log.

Cada arquivo arquivado é compactado individualmente usando o formato do arquivo Gzip.

Ativar registros de auditoria

Para ativar o registro de acesso a sessões e objetos, configure os parâmetros do pgAudit no cluster de banco de dados e instale a extensão nos bancos de dados.

Etapa 1: configurar o pgAudit nos parâmetros do DBCluster

Para que os registros de acesso a sessões e objetos sejam coletados no arquivo postgresql.audit, é necessário ativar o pgAudit e configurar quais instruções registrar usando pgaudit.log.

Adicione as seguintes linhas à seção parameters do arquivo v1_dbcluster_parameters.yaml:

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

Confira abaixo um exemplo de como isso aparece no manifesto do 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 mais informações, consulte pgaudit em Extensões de banco de dados compatíveis.

Etapa 2: criar a extensão pgAudit no banco de dados

Depois de configurar os parâmetros e garantir que o banco de dados foi reiniciado, você precisa se conectar ao banco de dados e instalar a extensão pgAudit:

CREATE EXTENSION IF NOT EXISTS pgaudit;

Execute esse comando em todos os bancos de dados em que você quer ativar o registro de auditoria. Essa etapa é necessária para instalar os gatilhos de eventos necessários para a auditoria de DDL.

Parâmetros do pgAudit (GUCs)

A tabela a seguir descreve os principais parâmetros de configuração unificada (GUCs, na sigla em inglês) do pgAudit que podem ser configurados na seção parameters da especificação DBCluster. Para mais informações, consulte a documentação do pgAudit.

Parâmetro	Descrição	Valor padrão
`pgaudit.log`	Especifica quais classes de instruções são registradas pelo registro de auditoria de sessão. Os valores válidos são `none`, `all`, `read`, `write`, `function`, `role`, `ddl`, `misc`, `misc_set`.	`none`
`pgaudit.log_catalog`	Especifica que o registro de sessão será ativado se todas as relações em uma instrução estiverem em `pg_catalog`. A desativação disso reduz o ruído de registro dos clientes do banco de dados.	`on`
`pgaudit.log_parameter`	Especifica que o registro de auditoria inclui os parâmetros transmitidos com a instrução.	`off`
`pgaudit.log_relation`	Especifica se a auditoria de sessão cria uma entrada de registro separada para cada relação (tabela, visualização etc.) referenciada em uma instrução `SELECT` ou DML.	`off`
`pgaudit.log_rows`	Especifica que o registro de auditoria inclua o número de linhas recuperadas ou afetadas por uma instrução.	`off`
`pgaudit.log_statement`	Especifica se o registro em log inclui o texto e os parâmetros da instrução.	`on`
`pgaudit.role`	Especifica a função principal a ser usada para o registro de auditoria de objetos.	Nenhum

Os registros do servidor PostgreSQL são sempre coletados no arquivo postgresql.log e não exigem a ativação do pgAudit.

Visualizar o caminho do arquivo de registro de auditoria

Use a função SQL alloydb_audit_current_logfile para visualizar o caminho do arquivo de registro de auditoria. Se a auditoria estiver desativada, o resultado será NULL.

SELECT alloydb_audit_current_logfile();

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

Configurar a rotação de registro

Se você quiser ter mais controle sobre quando os registros são rotacionados, configure um tamanho máximo de arquivo, uma duração entre as rotações de registro ou ambos. A duração entre as rotações de registro também é chamada de idade do registro. Se você usar as duas configurações, cada registro será rotacionado quando atingir um dos limites.

Para configurar a rotação de registro, defina um ou ambos os parâmetros a seguir na seção parameters do manifesto DBCluster:

log_rotation_size: "SIZE_IN_KB"
log_rotation_age: "AGE_IN_MINUTES"

Para desativar uma das configurações de rotação de registro, defina-a como zero, "0". Para manter a configuração padrão que rotaciona os registros quando o tamanho do arquivo atinge 200 MB, não defina nenhum parâmetro.

Exemplo de tamanho máximo e duração do registro da rotação de registro

O seguinte exemplo define a rotação dos registros quando o tamanho do arquivo atinge 400 MB ou quando o tempo entre as rotações atinge um dia, o que acontecer primeiro:

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

Exemplo de tamanho máximo do registro da rotação de registro

O seguinte exemplo define a rotação dos registros quando o tamanho do arquivo atinge 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

Exemplo de duração da rotação de registro

O seguinte exemplo define a rotação dos registros a 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

Encaminhar registros de auditoria para um coletor centralizado

O AlloyDB Omni grava registros de auditoria no arquivo /obs/diagnostic/postgresql.audit dentro do contêiner do banco de dados. Se você quiser encaminhar esses registros para um coletor de registros centralizado (como o Cloud Logging, Datadog, Splunk ou Elasticsearch), implante um contêiner sidecar usando o recurso personalizado (CR) Sidecar.

O contêiner secundário é executado no mesmo pod que o banco de dados, monta o volume de registro (obsdisk) e acompanha o arquivo de registro para encaminhá-lo ao destino de geração de registros.

Exemplo: encaminhamento de registros usando um sidecar do Fluent Bit

O exemplo a seguir demonstra como usar um sidecar do Fluent Bit para rastrear registros do pgAudit e enviá-los para a saída padrão, onde podem ser coletados por coletores de registros de cluster padrão do Kubernetes, como o agente doGoogle Cloud Logging no Google Kubernetes Engine (GKE).

Crie um ConfigMap para a configuração do Fluent Bit:

Crie um ConfigMap que contenha a configuração do Fluent Bit para rastrear o registro de auditoria.

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        *

Substitua NAMESPACE pelo namespace do cluster de banco de dados.

Crie o recurso personalizado Sidecar:

Crie um manifesto Sidecar que defina o contêiner do Fluent Bit e monte o volume obsdisk (que contém os registros do AlloyDB Omni) e o volume do 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/

Registre o arquivo secundário com o cluster de banco de dados:

Atualize o manifesto DBCluster para referenciar o sidecar ou faça um patch no cluster usando o seguinte comando:
```
kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"primarySpec":{"sidecarRef":{"name":"pgaudit-forwarder"}}}}' --type=merge
```
Substitua DB_CLUSTER_NAME pelo nome do cluster de banco de dados.

Para mais informações sobre como gerenciar sidecars, consulte Configurar um contêiner secundário.