The operator is designed to log in JSON format directly to standard output, including PostgreSQL logs.
Each log entry has the following fields:
level– Log level (
ts– The timestamp (epoch with microseconds).
logger– The type of the record (for example,
msg– The actual message or the keyword
recordin case the message is parsed in JSON format.
record– The actual record with structure that varies depending on the
logging_podName– The pod where the log was created.
Long-term storage and management of logs is outside the operator's purview, and needs to be provided at the level of the Kubernetes installation. See the Kubernetes Logging Architecture documentation.
If your log ingestion system requires it, you can rename the
ts field names using the
log-field-timestamp flags of the operator controller. Edit the
Deployment definition of the
You can specify a log level in the cluster spec with the option
You can set it to
Currently, you can set the log level only when an instance starts. You can't change it at runtime. If you change the value in the cluster spec after the cluster was started, it takes effect only in the new pods and not the old ones.
Each entry in the PostgreSQL log is a JSON object having the
logger key set
postgres and the structure described in the following example:
Internally, the operator relies on the PostgreSQL CSV log format. See the PostgreSQL documentation for more information about the CSV log format.
EDB Postgres for Kubernetes has transparent and native support for PGAudit on PostgreSQL clusters.
To enable this support, add the required
pgaudit parameters to the
section in the configuration of the cluster.
You need to add the PGAudit library to
EDB Postgres for Kubernetes adds the library based on the
pgaudit.* parameters in the postgresql configuration.
The operator detects and manages the addition and removal of the
The operator also takes care of creating and removing the extension from all the available databases in the cluster.
EDB Postgres for Kubernetes runs the
CREATE EXTENSION and
DROP EXTENSION commands in all databases in the cluster that accept
This example shows a PostgreSQL 13
Cluster deployment that results in
pgaudit being enabled with the requested configuration:
The audit CSV logs entries returned by PGAudit are then parsed and routed to stdout in JSON format, similarly to all the remaining logs:
.loggeris set to
.msgis set to
.recordcontains the whole parsed record as a JSON object. This is similar to
logging_collectorlogs, except for
.record.audit, which contains the PGAudit CSV message formatted as a JSON object.
This example shows sample log entries:
See the PGAudit documentation for more details about each field in a record.
Clusters that are running on EDB Postgres Advanced Server (EPAS) can enable EDB Audit as follows:
.spec.postgresql.epas.audit: true enforces the following parameters:
Other parameters can be passed via
.spec.postgresql.parameters as usual.
The audit CSV logs are parsed and routed to stdout in JSON format, similarly to all the remaining logs:
.recordcontaining the whole parsed record as a JSON object
See the example below:
See EDB Audit file for more details about the records' fields.
All logs that are produced by the operator and its instances are in JSON
logger set according to the process that produced them.
Therefore, all the possible
logger values are the following:
edb_audit: from the EDB Audit extension
initdb: from running
pg_basebackup: from running
pg_controldata: from running
pg_ctl: from running any
pg_rewind: from running
pgaudit: from PGAudit extension
postgres: from the
wal-archive: from the
wal-archivesubcommand of the instance manager
wal-restore: from the
wal-restoresubcommand of the instance manager
edb_audit that have the aforementioned structures,
all other possible values just have
msg set to the escaped message that's