Logging#
CloudNativePG™クラスターのEDB Postgres® AIは、セキュリティ上の理由からストレージに永続化せずに、JSON形式でログをPostgreSQLログを含む標準出力に直接出力します。このデザインにより、 stern のようなコマンドラインのものを含む、ほとんどのKubernetes互換ログ管理ツールとのシームレスな統合が促進されます。
Kubernetes Logging Architecture を参照してください。
ドキュメント。
各ログエントリには、次のフィールドが含まれます。
level– ログレベルたとえばinfo、notice。ts– タイムスタンプ。logger– ログのタイプpostgres、pg_controldataなど。msg– ログメッセージ、またはメッセージがJSON形式の場合はキーワードrecordrecord– 実際のレコード。loggerタイプに応じて異なる構造。logging_pod– ログが生成されたポッドの名前。
注釈
ログ取り込みシステムでカスタムフィールド名が必要な場合、オペレーターコントローラの`log-field-level` および`log-field-timestamp` フラグを使用して、level および`ts` フィールドの名前を変更できます。これは、 cloudnative-pg オペレーターの`Deployment` 定義を編集することにより構成できます。
クラスターログ#
logLevel
オプションを使用して、クラスター仕様でインスタンスポッドのログレベルを構成できます。使用可能なログレベルはerror
、warning 、info デフォルト、debug 、およびtrace
です。
オペレーターログ#
オペレーターポッドによって生成されるログは、インスタンスポッドと同じログレベルで構成できます。error
、warning 、info デフォルト、debug 、およびtrace
。
オペレーターのログレベルは、オペレーターのDeployment
定義を編集し、--log-level
コマンドライン引数を目的の値に設定することにより、構成できます。
PostgreSQLログ#
各PostgreSQLログエントリは、 logger キーがpostgres
に設定されたJSONオブジェクトです。ログエントリの構造は次のとおりです。
{
"level": "info",
"ts": 1619781249.7188137,
"logger": "postgres",
"msg": "record",
"record": {
"log_time": "2021-04-30 11:14:09.718 UTC",
"user_name": "",
"database_name": "",
"process_id": "25",
"connection_from": "",
"session_id": "608be681.19",
"session_line_num": "1",
"command_tag": "",
"session_start_time": "2021-04-30 11:14:09 UTC",
"virtual_transaction_id": "",
"transaction_id": "0",
"error_severity": "LOG",
"sql_state_code": "00000",
"message": "database system was interrupted; last known up at 2021-04-30 11:14:07 UTC",
"detail": "",
"hint": "",
"internal_query": "",
"internal_query_pos": "",
"context": "",
"query": "",
"query_pos": "",
"location": "",
"application_name": "",
"backend_type": "startup"
},
"logging_pod": "cluster-example-1",
}
注釈
内部的に、オペレーターはPostgreSQLのCSVログ形式を使用します。詳細については、
PostgreSQL documentation on CSV log format を参照してください。
PG監査ログ#
CloudNativePG™クラスターのEDB Postgres® AIは、 PostgreSQLクラスターで PGAudit のシームレスなネイティブサポートを提供します。
PGAuditを有効にするには、クラスター構成のpostgresql
セクションに必要なpgaudit パラメーターを追加します。
さらに、オペレーターは、クラスター内のすべてのデータベースでPGAudit拡張機能の作成と削除を管理します。
次の例は、PGAuditが有効および構成されたPostgreSQL Cluster
展開を示しています。
apiVersion: postgresql.k8s.enterprisedb.io/v1
kind: Cluster
metadata:
name: cluster-example
spec:
instances: 3
postgresql:
parameters:
"pgaudit.log": "all, -misc"
"pgaudit.log_catalog": "off"
"pgaudit.log_parameter": "on"
"pgaudit.log_relation": "on"
storage:
size: 1Gi
PGAuditによって生成された監査CSVログエントリは解析され、他のすべてのログと同様に、JSON形式で標準出力にルーティングされます。
.loggerはpgauditに設定されます。.msgはrecordに設定されます。.recordには、解析されたレコード全体がJSONオブジェクトとして含まれています。この構造は、JSONオブジェクトとしてフォーマットされたPGAudit CSVメッセージを含む.record.auditを除きlogging_collectorログの構造に似ています。
この例は、サンプルログエントリを示しています。
{
"level": "info",
"ts": 1627394507.8814096,
"logger": "pgaudit",
"msg": "record",
"record": {
"log_time": "2021-07-27 14:01:47.881 UTC",
"user_name": "postgres",
"database_name": "postgres",
"process_id": "203",
"connection_from": "[local]",
"session_id": "610011cb.cb",
"session_line_num": "1",
"command_tag": "SELECT",
"session_start_time": "2021-07-27 14:01:47 UTC",
"virtual_transaction_id": "3/336",
"transaction_id": "0",
"error_severity": "LOG",
"sql_state_code": "00000",
"backend_type": "client backend",
"audit": {
"audit_type": "SESSION",
"statement_id": "1",
"substatement_id": "1",
"class": "READ",
"command": "SELECT FOR KEY SHARE",
"statement": "SELECT pg_current_wal_lsn()",
"parameter": "<none>"
}
},
"logging_pod": "cluster-example-1",
}
レコードの各フィールドの詳細については、 PGAudit documentation を参照してください。
EDB Audit log#
EDB Postgres Advanced Serverで実行されているクラスターは、次のように EDB Audit を有効にできます。
apiVersion: postgresql.k8s.enterprisedb.io/v1
kind: Cluster
metadata:
name: cluster-example
spec:
instances: 3
imageName: docker.enterprisedb.com/k8s/edb-postgres-advanced:18-standard-ubi9
postgresql:
epas:
audit: true
storage:
size: 1Gi
.spec.postgresql.epas.audit: true
を設定すると、次のパラメーターが適用されます。
edb_audit = csv
edb_audit_destination = file
edb_audit_directory = /controller/log
edb_audit_filename = edb_audit
edb_audit_rotation_day = none
edb_audit_rotation_seconds = 0
edb_audit_rotation_size = 0
edb_audit_tag =
edb_log_every_bulk_value = false
他のパラメーターは、通常のように.spec.postgresql.parameters
を介して渡すことができます。
監査CSVログは、残りのすべてのログと同様に、解析され、JSON形式でstdoutにルーティングされます。
.loggerをedb_auditに設定.msgをrecordに設定解析されたレコード全体をJSONオブジェクトとして含む
.record
以下の例を参照してください。
{
"level": "info",
"ts": 1624629110.7641866,
"logger": "edb_audit",
"msg": "record",
"record": {
"log_time": "2021-06-25 13:51:50.763 UTC",
"user_name": "postgres",
"database_name": "postgres",
"process_id": "68",
"connection_from": "[local]",
"session_id": "60d5df76.44",
"session_line_num": "5",
"process_status": "idle in transaction",
"session_start_time": "2021-06-25 13:51:50 UTC",
"virtual_transaction_id": "3/93",
"transaction_id": "1183",
"error_severity": "AUDIT",
"sql_state_code": "00000",
"message": "statement: GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO \"streaming_replica\"",
"detail": "",
"hint": "",
"internal_query": "",
"internal_query_pos": "",
"context": "",
"query": "",
"query_pos": "",
"location": "",
"application_name": "",
"backend_type": "client backend",
"command_tag": "GRANT",
"audit_tag": "",
"type": "grant"
},
"logging_pod": "cluster-example-1",
}
EDB Audit file を参照してください
レコードのフィールドの詳細については、
その他のログ#
オペレーターとそのインスタンスによって生成されたすべてのログはJSON形式であり、
logger
フィールドは、それらを生成したプロセスを示します。使用可能なlogger
値は次のとおりです。
barman-cloud-wal-archivebarman-cloud-wal-archiveからのログbarman-cloud-wal-restorebarman-cloud-wal-restoreからのログedb_auditEDB Audit拡張機能からinitdbinitdbの実行からのログpg_basebackuppg_basebackupの実行からのログpg_controldatapg_controldataの実行からのログpg_ctlpg_ctlサブコマンドの実行からのログpg_rewindpg_rewindの実行からのログpgauditPGAudit拡張機能からのログpostgrespostgresインスタンスからのログmsgはrecordとは異なりますwal-archiveインスタンスマネージャーのwal-archiveサブコマンドからのログwal-restoreインスタンスマネージャーのwal-restoreサブコマンドからのログinstance-managerPostgreSQL instance manager から
特定の構造に従うpostgres およびedb_audit を除き
、他のすべてのlogger
値には、ログに記録されるエスケープメッセージを含むmsg
フィールドが含まれます。