Audit Logs

Ververica Platform records user activity through Audit Logs, providing a complete capture of actions you perform through the UI or API. Each action appears twice in the audit log. The first entry is marked ISSUED when the platform receives the action, and the second is marked EXECUTED when the platform processes it. Both entries share a traceId you can use to link them together and correlate with application-level logs.

Log Schema

Ververica Platform writes each audit log entry in JSON format. Each entry contains the following fields:

Logged Events

The following events are captured by the audit logging system:

Enable Audit Logs

Audit log collection is disabled by default. To enable it, set the following in your api-gateway Helm chart values:

1audit:
2  enabled: true

Configure Storage

Ververica Platform writes audit logs to a local directory on the cluster. The following parameters control log storage behavior:

To customize storage settings, add them to your api-gateway Helm chart values alongside audit.enabled:

1audit:
2  enabled: true
3  logDirectory: /var/log/vvp-audit
4  auditLogMaxFileSize: 100MB
5  auditLogMaxSize: 1GB
6  auditLogMaxRetentionDays: 30

Write Audit Logs to Standard Output

File-based storage keeps audit logs inside the pod, so they are lost when the pod is replaced unless the directory is backed by a persistent volume. As an alternative, Ververica Platform can write audit events to standard output, which makes the existing cluster log pipeline the durable store.

Set audit.output to stdout in the api-gateway values:

1audit:
2  enabled: true
3  output: stdout

In this mode:

• Audit events are emitted as JSON lines on the container's standard output.
• Each event carries "audit": true, so a log collector can route audit records separately from application logs.
• The log-forwarding sidecar is not deployed, because the container runtime already captures standard output.
• The file-based parameters in the previous table have no effect.

The default value is file, which preserves the behavior described above.

Choose stdout when a log collector such as Fluent Bit, Fluentd, or Vector already ships container logs to a central system, and that system is the system of record for audit data. Choose file with a persistent volume when audit records must remain on durable storage owned by the platform itself.

Export Audit Logs to Kafka

The recommended approach for forwarding audit logs to Kafka is to attach a FluentBit sidecar to the api-gateway pod. FluentBit tails the local audit log files and streams entries to a Kafka topic. It uses built-in filesystem buffering to handle backpressure.

To enable FluentBit-based export, provide your broker addresses and topic name in your api-gateway Helm chart values:

1audit:
2  enabled: true
3  fluentbit:
4    enabled: true
5    kafka:
6      brokers: '<your-kafka-brokers>'
7      topic: '<your-audit-log-topic>'

The following table lists the FluentBit configuration options and their defaults:

For advanced Kafka connection settings such as TLS or SASL authentication, modify the OUTPUT section of the FluentBit configmap directly using rdkafka.* properties. See the FluentBit Kafka output documentation for available options.

Limitations

• Audit logs capture platform-level actions you perform through the Ververica Platform UI or API. Ververica Platform does not record events from Flink jobs themselves.
• This release does not include advanced log querying, a built-in filtering UI, or per-log-entry access control.
• Audit log delivery to Kafka is best-effort. You might lose events if both the Kafka broker and the local FluentBit buffer are unavailable at the same time.