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 (e.g.
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_pod: the name of 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. Please refer to the Kubernetes Logging Architecture documentation.
ts field names can be renamed via the
log-field-timestamp flags of the operator controller, should your log ingestion
system require it. All you have to do is edit the
Deployment definition of the
A log level can be specified in the cluster spec with the option
can be set to any of
At the moment, the log level can only be set when an instance starts and can not be changed at runtime. If the value is changed in the cluster spec after the cluster was started, this will take 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. Please refer to 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.
All you need to do is add the required
pgaudit parameters to the
section in the configuration of the cluster.
It is unnecessary to add the PGAudit library to
The library will be added automatically by EDB Postgres for Kubernetes based on the
pgaudit.* parameters in the postgresql configuration.
The operator will detect and manage 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 command in all databases in the cluster that accept
Here is an example of a PostgreSQL 13
Cluster deployment which will result 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, similar to
logging_collectorlogs - except for
.record.audit, which contains the PGAudit CSV message formatted as a JSON object
See the example below:
Please refer to the PGAudit documentation for more details about each field in a record.
EDB Audit logs
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 accordingly to the process that produced them.
Therefore, all the possible
logger values are the following ones:
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 is