AlloyDB Omni のログ ローテーションを構成する

ドキュメントのバージョンを選択してください。

このドキュメントでは、AlloyDB Omni Kubernetes 演算子を使用するときに AlloyDB Omni 診断ログのローテーションを構成する方法について説明します。

次のログファイルは /obs/diagnostic/ ディレクトリにあります。

  1. postgresql.audit: このログファイルは、セッションとオブジェクト アクセスの監査ログを収集します。監査ログを収集するには、監査ログを有効にする必要があります。

  2. postgresql.log: このログファイルは、PostgreSQL サーバーログを収集します。これらのログは常に収集されるため、有効にする必要はありません。

ログファイルがローテーションされると、次の処理が行われます。

  1. ログファイルは /obs/diagnostic/archive/ ディレクトリにコピーされます。同じ名前のログファイルが存在する場合は、上書きされます。

  2. ローテーションされた元のログファイルの内容は削除され、ファイルは空になります。

  3. ログ情報は、直ちにローテーションされた空のログファイルに書き込まれます。ログ情報は、ファイルのサイズまたは存続期間のしきい値に達するまでログファイルに書き込まれ、その時点で再びローテーションされます。ログがローテーションされるのは、サイズが大きくなりすぎないようにするためです。

デフォルトでは、各ログファイルのサイズが 200 MB に達するとローテーションするように設定されています。デフォルトのローテーションには、存続期間の設定は含まれていません。

アーカイブされたファイルは 7 日間保持されます。7 日以上経過したアーカイブ ファイルは、前回のローテーションでアーカイブされたファイルを除き、自動的に削除されます。たとえば、log_rotation_age が 7 日以上前のものである場合、アーカイブ ファイルは現在のファイルのローテーション前に 7 日のしきい値に達します。この場合、このアーカイブ ファイルは、次のローテーションで新しいアーカイブ ファイルが生成されるまで削除されません。

ローテーションされた各ログのファイル名は postgresql-%Y-%m-%d_%H%M%S.log という形式になります。タイムスタンプはログのローテーション時に決定され、協定世界時（UTC）で表されます。たとえば、UTC の 2024 年 12 月 20 日 13:01:02 にログがローテーションされた場合、アーカイブ ファイル名は postgresql-2024-12-20_130102.log になります。

アーカイブされた各ファイルは、Gzip ファイル形式を使用して個別に圧縮されます。

監査ログを有効にする

セッションとオブジェクト アクセスのロギングを有効にするには、データベース クラスタで pgAudit パラメータを構成し、データベースに拡張機能をインストールする必要があります。

ステップ 1: DBCluster パラメータで pgAudit を構成する

セッションログとオブジェクト アクセスログを postgresql.audit ファイルに収集するには、pgAudit を有効にして、pgaudit.log を使用してログに記録するステートメントを構成する必要があります。

v1_dbcluster_parameters.yaml ファイルの parameters セクションに次の行を追加します。

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

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"

詳細については、サポートされているデータベース拡張機能の pgaudit をご覧ください。

ステップ 2: データベースに pgAudit 拡張機能を作成する

パラメータを構成し、データベースが再起動したことを確認したら、データベースに接続して pgAudit 拡張機能をインストールする必要があります。

CREATE EXTENSION IF NOT EXISTS pgaudit;

このコマンドは、監査ロギングを有効にするすべてのデータベースで実行する必要があります。この手順は、DDL 監査に必要なイベント トリガーをインストールするために必要です。

pgAudit パラメータ（GUC）

次の表に、DBCluster 仕様の parameters セクションで構成できる主要な pgAudit Grand Unified Configuration パラメータ（GUC）を示します。詳細については、pgAudit のドキュメントをご覧ください。

パラメータ 説明 デフォルト値
pgaudit.log セッション監査ロギングでログに記録されるステートメントのクラスを指定します。有効な値は、none、all、read、write、function、role、ddl、misc、misc_set です。 none
pgaudit.log_catalog ステートメント内のすべての関係が pg_catalog にある場合、セッション ロギングが有効になることを指定します。これを無効にすると、データベース クライアントからのログノイズが軽減されます。 on
pgaudit.log_parameter 監査ロギングにステートメントで渡されたパラメータを含めることを指定します。 off
pgaudit.log_relation セッション監査で、SELECT ステートメントまたは DML ステートメントで参照される各リレーション（テーブル、ビューなど）に対して個別のログエントリを作成するかどうかを指定します。 off
pgaudit.log_rows 監査ロギングに、ステートメントによって取得または影響を受けた行数を含めることを指定します。 off
pgaudit.log_statement ロギングにステートメント テキストとパラメータを含めるかどうかを指定します。 on
pgaudit.role オブジェクト監査ロギングに使用するプライマリ ロールを指定します。 なし

PostgreSQL サーバーログは常に postgresql.log ファイルに収集されるため、pgAudit を有効にする必要はありません。

監査ログファイルのパスを表示する

SQL 関数 alloydb_audit_current_logfile を使用して、監査ログファイルのパスを表示します。監査が無効になっている場合、結果は NULL になります。

SELECT alloydb_audit_current_logfile();

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

ログ ローテーションを構成する

ログのローテーションのタイミングをより細かく制御するには、ファイルの最大サイズ、ログ ローテーションの期間、またはその両方を構成します。ログ ローテーションが発生する間隔は、ログの存続期間とも呼ばれます。両方の設定を使用する場合、各ログはいずれかのしきい値に達するとローテーションされます。

ログ ローテーションを構成するには、DBCluster マニフェストの parameters セクションで次のいずれかまたは両方のパラメータを設定します。

  • log_rotation_size: 「SIZE_IN_KB」
  • log_rotation_age: 「AGE_IN_MINUTES」

ログ ローテーションの設定のいずれかを無効にするには、ゼロ（"0"）に設定します。ファイルサイズが 200 MB に達したときにログをローテーションするデフォルト設定を保持するには、どちらのパラメータも設定しないでください。

ログ ローテーションの最大ログサイズと期間の例

次のサンプルでは、ファイルサイズが 400 MB に達したとき、またはログ ローテーションの間隔が 1 日に達したとき（どちらか先に発生したとき）にログをローテーションするように設定します。

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

ログ ローテーションの最大ログサイズの例

次のサンプルでは、ファイルサイズが 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

ログ ローテーションの期間の例

次のサンプルでは、ログを 24 時間ごとにローテーションするように設定します。

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

監査ログを一元化されたシンクに転送する

AlloyDB Omni は、データベース コンテナ内の /obs/diagnostic/postgresql.audit ファイルに監査ログを書き込みます。これらのログを集中型ロギング シンク（Cloud Logging、Datadog、Splunk、Elasticsearch など）に転送する場合は、Sidecar カスタム リソース（CR）を使用してサイドカー コンテナをデプロイできます。

サイドカー コンテナは、データベースと同じ Pod で実行され、ログボリューム（obsdisk）をマウントし、ログファイルをテールしてロギングの宛先に転送します。

例: fluent bit サイドカーを使用してログを転送する

次の例は、Fluent Bit サイドカーを使用して pgAudit ログを追跡し、標準出力に出力する方法を示しています。標準出力に出力されたログは、標準の Kubernetes クラスタ ログコレクタ（Google Kubernetes Engine（GKE）のGoogle Cloud Logging エージェントなど）で収集できます。

  1. Fluent Bit 構成の ConfigMap を作成します。

    監査ログを追跡する Fluent Bit 構成を含む ConfigMap を作成します。

    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        *

    NAMESPACE は、データベース クラスタの名前空間に置き換えます。

  2. Sidecar カスタム リソースを作成します。

    Fluent Bit コンテナを定義し、obsdisk ボリューム（AlloyDB Omni ログを含む）と ConfigMap ボリュームの両方をマウントする Sidecar マニフェストを作成します。

    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. サイドカーをデータベース クラスタに登録します。

    DBCluster マニフェストを更新してサイドカーを参照するか、次のコマンドを使用してクラスタにパッチを適用します。

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

    DB_CLUSTER_NAME は、実際のデータベース クラスタの名前に置き換えます。

    サイドカーの管理の詳細については、サイドカー コンテナを構成するをご覧ください。

次のステップ