Enabling Auditing in IBM MQ to Track Every Action by a Specific User

Audience: MQ admins, SREs, security & compliance Applies to: IBM MQ v9.x (notes for v9.4.3+ where “positive authority events” are available)

Why audit MQ user activity?

Enterprises often need a verifiable trail of who did what, when, and where in MQ: opening/putting/getting messages, connecting, admin commands, channel connections, and authorization outcomes. IBM MQ provides first‑class mechanisms for this through instrumentation events, command/config events, and Application Activity Trace, which you can centralize and analyze in your preferred observability stack.

What to enable (and why)

IBM MQ produces structured PCF event messages on well‑known queues. Turning on the right switches yields a full audit trail.

1) Authority (authorization) events — who was allowed/denied?These capture authorization checks and include user identity fields, so you can tie operations back to a specific user ID. Events are written to SYSTEM.ADMIN.QMGR.EVENT.

· Enable (minimum — failures only):

ALTER QMGR AUTHOREV(ENABLED)

· IBM MQ 9.4.3+ — enable positive authority events (successful connects and checks too):

ALTER QMGR AUTHOREV(ENABLED) AUTHEVSC(ALLCHECKS)

AUTHEVSC supports FAILURES | ALLCONNS | ALLCHECKS. With ALLCHECKS, you audit successful connect and resource checks — ideal for complete trails.

Tip: To avoid floods from apps that repeatedly MQOPEN the same object (e.g., MQPUT1 patterns), tune EventMinDuplicationDelayTime in qm.ini.

2) Command & configuration events — which admin issued what command?

Audit who executed MQSC/PCF commands and what changed.

Enable: ALTER QMGR CMDEV(ENABLED) CONFIGEV(ENABLED)

Events go to SYSTEM.ADMIN.COMMAND.EVENT (what command ran) and SYSTEM.ADMIN.CONFIG.EVENT (what changed). These include origin details (user ID, origin = console/REST, etc.).

3) Application Activity Trace — what did an application actually do?

For detailed per‑API call visibility (sequence of MQPUT/MQGET/MQOPEN/… including parameters and object names), enable Application Activity Trace.

Enable globally: ALTER QMGR ACTVTRC(ON)

Trace messages are sent to SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE. You can also subscribe to special system topics to consume activity data dynamically (without central queue) and adjust the performance/verbosity via mqat.ini.

Performance note: Activity tracing is powerful but adds overhead. For production, trace only what you need and tune ActivityInterval, ActivityCount, and TraceLevel in mqat.ini.

4) Channel events & CHLAUTH — who connected from where?

Enable channel events (CHLEV) to audit connection starts/stops, SSL issues, and blocked connections (useful alongside CHLAUTH rules).

Enable: ALTER QMGR CHLEV(ENABLED)

Events go to SYSTEM.ADMIN.CHANNEL.EVENT. CHLAUTH itself is controlled with ALTER QMGR CHLAUTH(ENABLED) and rules generate events when they block users.

Centralizing the events (recommended patterns)

*All events are written to the SYSTEM.ADMIN..EVENT queues. You can either consume directly, or redirect/publish** these events so multiple tools can subscribe without hard‑coding system queues:

• Publish events: Convert the event queues to aliases targeting topics, then subscribe once (wildcards supported). Example:

DEFINE TOPIC(ADMIN.QMGR.EVENT) TOPICSTR('Events/QMgr')
DEFINE TOPIC(ADMIN.CHANNEL.EVENT) TOPICSTR('Events/Channel')
DEFINE QALIAS(SYSTEM.ADMIN.QMGR.EVENT) TARGTYPE(TOPIC) TARGET(ADMIN.QMGR.EVENT)
DEFINE QALIAS(SYSTEM.ADMIN.CHANNEL.EVENT) TARGTYPE(TOPIC) TARGET(ADMIN.CHANNEL.EVENT)
DEFINE QLOCAL(ADMIN.EVENT)
DEFINE SUB(EVENTS.ALL) TOPICSTR('Events/+') PSPROP(NONE) DESTCLAS(PROVIDED) DEST(ADMIN.EVENT)

Queue depth hygiene: If you enable events but don’t drain them, those queues can fill up. Plan consumers and retention from day one.

Reading & filtering the audit data (per‑user)

You have two solid utilities out of the box:

• amqsevt (formats event messages; supports JSON -o json and compact single‑line JSON -o json_compact since MQ 9.2.4). Great for authority, channel, command/config events.
• amqsact (formats Application Activity Trace messages).Use it when you need the granular API call sequence per application/connection.

Advanced: amqsevt can also format activity trace messages if you prefer a single formatter and JSON outputs.

Below is a clean, production‑ready sample script that uses amqsevt in JSON mode (-o json_compact) for log ingestion into ELK

The script follows IBM MQ’s documented behavior:

• amqsevt reads messages from system event queues and formats them into readable strings or JSON.
• Event messages represent instrumentation events, which include warnings, errors, configuration changes, channel activity, security‑related failures, etc.
• JSON mode (-o json_compact) ensures each event is emitted as a single‑line JSON object, ideal for log ingestion pipelines.

#!/usr/bin/env bash
#
# amqsevt JSON ingestion script
# Streams IBM MQ event messages as single-line JSON objects
# suitable for ingestion into SIEM/ELK/Loki/Splunk.
#
set -euo pipefail
# - - - - - - - - - - - -
# User-configurable settings
# - - - - - - - - - - - -
QMGR="${QMGR:-QM1}"
EVENT_QUEUES=(
"SYSTEM.ADMIN.QMGR.EVENT"
"SYSTEM.ADMIN.CHANNEL.EVENT"
"SYSTEM.ADMIN.COMMAND.EVENT"
"SYSTEM.ADMIN.CONFIG.EVENT"
)
OUT_DIR="${OUT_DIR:-/var/log/mq-events}"
mkdir -p "$OUT_DIR"
LOGFILE="$OUT_DIR/mq_events_$(date +%Y%m%d).log"
# - - - - - - - - - - - -
# Function: Stream events
# - - - - - - - - - - - -
stream_events() {
for Q in "${EVENT_QUEUES[@]}"; do
echo ">>> Listening to $Q on $QMGR" >&2
# amqsevt options explained:
# -m : queue manager name
# -q : which system event queue to read
# -b : browse (non‑destructive read)
# -o json_compact : single‑line JSON (ideal for log ingestion)
# -w <sec> : wait N seconds if no events arrive
amqsevt \
-m "$QMGR" \
-q "$Q" \
-b \
-w 2 \
-o json_compact \
| while IFS= read -r jsonline; do
# Add local metadata before logging
printf '{"qmgr":"%s","queue":"%s","timestamp":"%s","event":%s}\n' \
"$QMGR" "$Q" "$(date -Is)" "$jsonline" \
>> "$LOGFILE"
done
done
}
# - - - - - - - - - - - -
# Main loop (runs forever)
# - - - - - - - - - - - -
echo "Starting MQ event ingestion… Output: $LOGFILE" >&2
while true; do
stream_events
sleep 1
done

The script wraps each JSON event with:

{
"qmgr": "QM1",
"queue": "SYSTEM.ADMIN.QMGR.EVENT",
"timestamp": "2026–02–17T12:34:56+05:30",
"event": { …original MQ event… }
}