# Audit Logging > For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [streaming-full.txt](https://docs.redpanda.com/streaming-full.txt) --- title: Audit Logging latest-redpanda-tag: v25.2.1 latest-console-tag: v3.7.3 latest-operator-version: v26.1.4 # EOL = End-of-Life (support lifecycle status) page-is-nearing-eol: "true" page-is-past-eol: "false" page-eol-date: July 31, 2026 latest-connect-version: 4.93.0 docname: audit-logging page-component-name: streaming page-version: "25.2" page-component-version: "25.2" page-component-title: Streaming page-relative-src-path: audit-logging.adoc page-edit-url: https://github.com/redpanda-data/docs/edit/v/25.2/modules/manage/pages/audit-logging.adoc description: Learn how to use Redpanda's audit logging capabilities. page-git-created-date: "2023-12-22" page-git-modified-date: "2025-07-31" support-status: nearing end-of-life --- > 📝 **NOTE** > > This feature requires an [enterprise license](https://docs.redpanda.com/streaming/25.2/get-started/licensing/). To get a trial license key or extend your trial period, [generate a new trial license key](https://redpanda.com/try-enterprise). To purchase a license, contact [Redpanda Sales](https://redpanda.com/upgrade). > > If Redpanda has enterprise features enabled and it cannot find a valid license, [restrictions](https://docs.redpanda.com/streaming/25.2/get-started/licensing/#self-managed) apply. Many scenarios for streaming data include the need for fine-grained auditing of user activity related to the system. This is especially true for regulated industries such as finance, healthcare, and the public sector. Complying with [PCI DSS v4](https://www.pcisecuritystandards.org/document_library/?document=pci_dss) standards, for example, requires verbose and detailed activity auditing, alerting, and analysis capabilities. Redpanda’s auditing capabilities support recording both administrative and operational interactions with topics and with users. Redpanda complies with the Open Cybersecurity Schema Framework (OCSF), providing a predictable and extensible solution that works seamlessly with industry standard tools. With audit logging enabled, there should be no noticeable changes in performance other than slightly elevated CPU usage. > 📝 **NOTE** > > Audit logging is configured at the cluster level. Redpanda supports excluding specific topics or principals from auditing to help reduce noise in the log. Audit logging is disabled by default. ## [](#audit-log-flow)Audit log flow The Redpanda audit log mechanism functions similar to the Kafka flow. When a user interacts with another user or with a topic, Redpanda writes an event to a specialized audit topic. The audit topic is immutable. Only Redpanda can write to it. Users are prevented from writing to the audit topic directly and the Kafka API cannot create or delete it. ![Audit log flow](https://docs.redpanda.com/streaming/25.2/shared/_images/audit-logging-flow.png) By default, any management and authentication actions performed on the cluster yield messages written to the audit log topic that are retained for seven days. Interactions with all topics by all principals are audited. Actions performed using the Kafka API and Admin API are all audited, as are actions performed directly through `rpk`. Messages recorded to the audit log topic comply with the [open cybersecurity schema framework](https://schema.ocsf.io/). Any number of analytics frameworks, such as Splunk or Sumo Logic, can receive and process these messages. Using an open standard ensures Redpanda’s audit logs coexist with those produced by other IT assets, powering holistic monitoring and analysis of your assets. ## [](#audit-log-configuration-options)Audit log configuration options Redpanda’s audit logging mechanism supports several options to control the volume and availability of audit records. Configuration is applied at the cluster level. - [`audit_enabled`](https://docs.redpanda.com/streaming/25.2/reference/properties/cluster-properties/#audit_enabled): Boolean value to enable audit logging. When you set this to `true`, Redpanda checks for an existing topic named `_redpanda.audit_log`. If none is found, Redpanda automatically creates one for you. Default: `false`. - [`audit_log_num_partitions`](https://docs.redpanda.com/streaming/25.2/reference/properties/cluster-properties/#audit_log_num_partitions): Integer value defining the number of partitions used by a newly created audit topic. This configuration applies only to the audit log topic and may be different from the cluster or other topic configurations. This cannot be altered for an existing audit log topic. Default: `12`. - [`audit_log_replication_factor`](https://docs.redpanda.com/streaming/25.2/reference/properties/cluster-properties/#audit_log_replication_factor): Optional Integer value defining the replication factor for a newly created audit log topic. This configuration applies only to the audit log topic and may be different from the cluster or other topic configurations. This cannot be altered for existing audit log topics. If a value is not provided, Redpanda uses the `internal_topic_replication_factor` cluster property value. Default: `null`. - [`audit_client_max_buffer_size`](https://docs.redpanda.com/streaming/25.2/reference/properties/cluster-properties/#audit_client_max_buffer_size): Integer value defining the number of bytes allocated by the internal audit client for audit messages. When changing this, you must disable audit logging and then re-enable it for the change to take effect. Consider increasing this if your system generates a very large number of audit records in a short amount of time. Default: `16777216`. - [`audit_queue_max_buffer_size_per_shard`](https://docs.redpanda.com/streaming/25.2/reference/properties/cluster-properties/#audit_queue_max_buffer_size_per_shard): Integer value defining the maximum amount of memory in bytes used by the audit buffer in each shard. When this size is reached, requests to log additional audit messages return a non-retryable error. You must restart the cluster when changing this value. Default: `1048576`. - [`audit_enabled_event_types`](https://docs.redpanda.com/streaming/25.2/reference/properties/cluster-properties/#audit_enabled_event_types): List of strings in JSON style identifying the event types to include in the audit log. This may include any of the following: `management, produce, consume, describe, heartbeat, authenticate, schema_registry, admin`. Default: `'["management","authenticate","admin"]'`. - [`audit_excluded_topics`](https://docs.redpanda.com/streaming/25.2/reference/properties/cluster-properties/#audit_excluded_topics): List of strings in JSON style identifying the topics the audit logging system should ignore. This list cannot include the `_redpanda.audit_log` topic. Redpanda rejects the command if you do attempt to include that topic. Default: `null`. - [`audit_queue_drain_interval_ms`](https://docs.redpanda.com/streaming/25.2/reference/properties/cluster-properties/#audit_queue_drain_interval_ms): Internally, Redpanda batches audit log messages in memory and periodically writes them to the audit log topic. This defines the period in milliseconds between draining this queue to the audit log topic. Longer intervals may help prevent duplicate messages, especially in high throughput scenarios, but they also increase the risk of data loss during hard shutdowns where the queue is lost. Default: `500`. - [`audit_excluded_principals`](https://docs.redpanda.com/streaming/25.2/reference/properties/cluster-properties/#audit_excluded_principals): List of strings in JSON style identifying the principals the audit logging system should ignore. Principals can be listed as `User:name` or `name`, both are accepted. Default: `null`. Even though audited event messages are stored to a specialized immutable topic, standard topic settings still apply. For example, you can apply the same Tiered Storage, retention time, and replication settings available to normal topics. These particular options are important for controlling the amount of disk space utilized by your audit topics. > ❗ **IMPORTANT** > > You must configure certain audit logging properties before enabling audit logging because these settings impact the creation of the `_redpanda.audit_log` topic itself. These properties include: `audit_log_num_partitions` and `audit_log_replication_factor`. The Kafka API allows you to add partitions or alter the replication factor after enabling audit logging, but Redpanda prevents you from altering these two configuration values directly. ## [](#audit-logging-event-types)Audit logging event types Redpanda’s auditable events fall into one of eight different event types. The APIs associated with each event type are as follows. | Audit event type | Associated APIs | | --- | --- | | management | AlterPartitionReassignmentsCreateACLsCreatePartitionsCreateTopicsDeleteAclsDeleteGroupsDeleteRecordsDeleteTopicsIncrementalAlterconfigsOffsetDelete | | produce | AddPartitionsToTxnEndTxnInitProducerIdProduce | | consume | AddOffsetsToTxnFetchJoinGroupLeaveGroupListOffsetOffsetCommitSyncGroupTxOffsetCommit | | describe | DescribeAclsDescribeConfigsDescribeGroupsDescribeLogDirsFindCoordinatorListGroupsListPartitionReassignmentsMetadataOffsetForLeaderEpochDescribeProducersDescribeTransationsListTransactions | | heartbeat | Heartbeat | | authenticate | All authentication events | | schema_registry | All Schema Registry API calls | | admin | All Admin API calls | ### [](#logged-events)Logged events The following table identifies the data logging level for each audit event entry. > 📝 **NOTE** > > The Included column captures whether the event itself is included (for example, successful and failed access attempts), or whether a piece of data is included in the event itself (for example, Source IP address). | Data Logging Level | Audit Event | Included? | Details | | --- | --- | --- | --- | | System Level | Date and time stamp for each entry | Yes | time field on each event | | Successful and failed access attempts | Yes | The status_id field shows success/failure for all access attempts for which auditing is enabled | | User ID | Yes | user.name | | User connect and disconnect time | No | Connect and disconnect time may be inferred from the presence or absence of activity. | | Password change | Yes | For SCRAM users managed through Redpanda core, the Admin API call associated with the password change is logged. Note that this does not cover users synced from external IdPs, such as through OIDC. | | Changes of security settings | Yes | For example, ACL creation is logged (kafka create_acls), and cluster configuration changes are logged (Admin API events) | | Successful and failed attempts to add/remove users from the system | Yes | See Password change | | Failed attempts to access system data | Yes | Generally, access attempts are logged. For example, kafka produce and consume calls are audited. | | Failed attempts to access critical directories and files | No | Not applicable | | Date and time of system start-up and shut-down | Yes | An application lifecycle event is logged when the broker starts/stops | | Use of external/peripheral devices | No | Not applicable | | Application Level | Transaction date and time | Yes | time field on each event | | User ID | Yes | user.name | | Source IP address | Yes | src_endpoint.ip field | | Type of transaction | Yes | api.operation shows the relevant Kafka API accessed or HTTP method used (Admin/Schema Registry) | | Transaction data | Yes | resources[] for Kafka ops; http_request (headers, URL) for HTTP endpoints | | Transaction result (success/fail) and reason of failure | Partial | Auditing occurs at request time (start of event). Authentication failures are captured with status_id and status_detail fields. However, downstream operation outcomes (whether the actual Kafka/Admin API/Schema Registry operation succeeded or failed) are not included in audit logs. | | Transaction number | No | Redpanda auditing does not assign a unique number to each request | | Failed attempts to access system data | Yes | Access attempts are logged through various audit event types | | Failed attempts to access critical directories and files | No | Not applicable | | Use of external/peripheral devices | Yes | Device access events are captured when applicable | | Network Level | Source IP address (IPv4 or IPv6) | Yes | src_endpoint.ip field | | Destination IP address (IPv4 or IPv6) | Yes | dst_endpoint.ip field | | Protocol/Ports | Yes | service.name shows the service/protocol used (kafka/http). http_request.url.scheme shows http/https for http requests. dst_endpoint.port may be indicative of the protocol. | | Timestamp | Yes | time field | | Host name | Yes | url.hostname: HTTP endpoints (Admin API / Schema Registry) include the HTTP hostname. Not included for Kafka (only source/destination IP). | | VLAN ID | No | Not applicable | | MAC address | No | Not applicable | ## [](#enable-audit-logging)Enable audit logging All audit log settings are applied at the cluster level. Use `rpk cluster config` to configure audit logs. Some options require a cluster restart. You can verify this using `rpk cluster config status`. Some key tuning recommendations for your audit logging settings include: - To change the number of partitions or the replication factor for your audit log topic, set the `audit_log_num_partitions` and `audit_log_replication_factor` properties, respectively. - Choose the type of events needed by setting `audit_enabled_event_types` to the desired list of event categories. Keep this as restrictive as possible based on your compliance and security needs to avoid excessive noise in your audit logs. - Identify non-sensitive topics so that you can exclude them from auditing. Specify this list of topics in `audit_excluded_topics`. - Identify non-sensitive principals so that you can exclude them from auditing. Specify this list of principals in `audit_excluded_principals`. This command accepts names as `name` or `User:name`. - Set `audit_enabled` to `true`. - [Optimize costs for audit logging](#optimize-costs-for-audit-logging). The sequence of commands in `rpk` for this audit log configuration is: rpk cluster config set audit\_log\_num\_partitions 6 rpk cluster config set audit\_log\_replication\_factor 5 rpk cluster config set audit\_enabled\_event\_types '\["management","describe","authenticate"\]' rpk cluster config set audit\_excluded\_topics '\["topic1","topic2"\]' rpk cluster config set audit\_excluded\_principals '\["User:principal1", "principal2"\]' rpk cluster config set audit\_enabled true rpk topic alter-config \_redpanda.audit\_log --set retention.ms=259200000 ## [](#optimize-costs-for-audit-logging)Optimize costs for audit logging When enabled, audit logging can quickly generate a very large amount of data, especially if all event types are selected. Proper configuration of audit logging is critical to avoid filling your disk or using excess Tiered Storage. The configuration options available help ensure your audit logs contain only the volume of data necessary to meet your regulatory or legal requirements. With audit logging, the pattern of message generation may be very different from your typical sources of data. These messages reflect usage of your system as opposed to the operational data your topics typically process. As a result, your retention, replication, and Tiered Storage requirements may differ from your other topics. A typical scenario with audit logging is to route the messages to an analytics platform like Splunk. If your retention period is too long, you may find that you are storing excessive amounts of replicated messages in both Redpanda and in your analytics suite. Identifying the right balance of retention and replication settings minimizes this duplication while retaining your data in a system that provides actionable intelligence. Assess the retention needs for your audit logs. You may not need to keep the logs for the default seven days. This is controlled by setting [`retention.ms`](https://docs.redpanda.com/streaming/25.2/reference/properties/topic-properties/#retentionms) for the `_redpanda.audit_log` topic or by setting [`log_retention_ms`](https://docs.redpanda.com/streaming/25.2/reference/properties/cluster-properties/#log_retention_ms) at the cluster level. ## [](#next-steps)Next steps [See samples of audit log messages](audit-log-samples/) ## [](#suggested-reading)Suggested reading - [Topic Configuration Properties](https://docs.redpanda.com/streaming/25.2/reference/properties/topic-properties/) - [Manage Topics](https://docs.redpanda.com/streaming/25.2/develop/config-topics/) ## Suggested labs - [Enable Unified Identity with Azure Entra ID for Redpanda and Redpanda Console](https://docs.redpanda.com/labs/docker-compose/oidc/) - [Migrate Data with Redpanda Migrator](https://docs.redpanda.com/labs/docker-compose/redpanda-migrator/) [Search all labs](https://docs.redpanda.com/labs)