Configuring audit logging for IBM MQ in containers

IBM® MQ in containers provides various facilities for audit logging of different events.

Depending on the audit logging requirements for your environment, you might need to configure one or more of these facilities as well as suitable mechanisms for collecting and retaining the event logs. Choose from the following options.

IBM MQ Operator validating webhook

From version 3.6.0, the IBM MQ Operator by default outputs access audit events to exposed endpoints to the pod's container log. No configuration is required.

IBM MQ events

You can configure IBM MQ to produce event messages for auditing purposes. For more information see Auditing.

[MQ 9.4.3 Jun 2025]
MQ container metrics
The IBM MQ container exposes a Prometheus metrics endpoint (for more information, see Monitoring when using the IBM MQ Operator). From IBM MQ 9.4.3, you can enable logging of access to this endpoint by setting the MQ_LOGGING_METRICS_AUDIT_ENABLED environment variable to true. If you are using the IBM MQ Operator, you can set this variable in the env section of the queueManager configuration:
[...]
spec:
  queueManager:
    env:
    - name: MQ_LOGGING_METRICS_AUDIT_ENABLED
      value: "true"
[...]

When logging is enabled, log files are generated in the /var/mqm/errors directory. You can persist data that is in this directory by mounting external storage to /mnt/mqm (see container image reference). If you are using the IBM MQ Operator, you can instead map external storage by using the .spec.queueManager.storage.persistedData fields. Metrics access log files are written in JSON format. The filenames have the form metricaudit<nn>.json, where nn is a number. The metricaudit01.json file contains the most recent events.

Embedded IBM WebSphere® Application Server Liberty webserver

You can configure the embedded WebSphere Liberty webserver to produce audit events. The audit-1.0 and audit-2.0 features are installed and available for configuration, depending on your requirements. For more information, see Audit 1.0 and Audit 2.0 in the WebSphere Liberty documentation.

You can enable and configure the feature by using a configuration file. If you are using the IBM MQ Operator, you can load the file by using the .spec.web.manualConfig mounts. For example, the following code enables default configuration of the Audit 2.0 feature.

Create a configuration file called mqwebuser.xml, to enable the audit-2.0 feature:
kind: ConfigMap
apiVersion: v1
metadata:
  name: example-enable-audit
data:
  mqwebuser.xml: |
    <?xml version="1.0" encoding="UTF-8"?>
    <server>
      <featureManager>
        <feature>audit-2.0</feature>
      </featureManager>
    </server>
Add the previous code to the queueManager configuration by using the spec.web.manualConfig mount:
apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
[...]
spec:
  [...]
  web:
    enabled: true
    manualConfig:
      configMap:
        name: example-enable-audit
Note: By default, audit logs are mirrored to the container log in basic (plain text) format. This format contains a reduced set of audit information. To get more information, either change the IBM MQ container log to JSON format or disable the web log mirroring and gather the WebSphere Liberty JSON audit log file directly. You can control the log format and log mirroring sources by using the MQ_LOGGING_CONSOLE_FORMAT and MQ_LOGGING_CONSOLE_SOURCE environment variables. For valid values, see Environment variables supported.