Configuration events are IBM MQ audit trail messages that fire when someone or something changes the shape of your messaging estate—new channels, altered queue depths, deleted topics, modified CHLAUTH rules. In regulated industries, proving who changed PARIS.TO.LONDON at 02:14 matters as much as proving messages were delivered. Beginners enable events once, never monitor the event queue, and wonder why disks fill—SYSTEM.ADMIN.CONFIG.EVENT grows without a consumer. This tutorial explains what configuration events contain, how to enable them on the queue manager, where messages land, how event messages differ from ordinary application payloads, integrating with SIEM and observability pipelines, filtering noise from legitimate automation, and pairing configuration events with performance and security events for complete observability.
Administrative commands and API calls that create or modify MQ objects generate configuration events when event generation is enabled. Examples include DEFINE QLOCAL, ALTER CHANNEL, DELETE TOPIC, SET CHLAUTH, and equivalent PCF commands issued from scripts, MQ Explorer, MQ Console, or DevOps pipelines. The event message encodes object type, object name, change type, and principal information where available. Not every DISPLAY command generates configuration events—read-only inspection is usually silent. Automated installers that DEFINE hundreds of objects during deploy can flood the event queue if you do not filter or batch notifications.
| Category | Reports | Example |
|---|---|---|
| Configuration | Object definition changes | ALTER QLOCAL MAXDEPTH |
| Performance | Thresholds and state | Queue depth high |
| Security | Auth and authority failures | MQRC_NOT_AUTHORIZED on OPEN |
| Command | Command server events | Command completion (version-specific) |
12345ALTER QMGR CONFIGEV(ENABLED) DISPLAY QMGR CONFIGEV * Ensure event queue exists and is not inhibited DISPLAY QLOCAL('SYSTEM.ADMIN.CONFIG.EVENT') CURDEPTH MAXDEPTH * Deploy consumer: amqsevt, custom Java, or SIEM agent
Attribute spellings and default event queue names depend on MQ version—verify in IBM Documentation for 9.3 before production ALTER. On z/OS, event configuration may integrate with operations procedures and alternate queue names. After enablement, run one controlled ALTER on a test queue and confirm a message appears on the config event queue within seconds.
Event messages use special message descriptors and headers (event header structures in IBM docs) separate from application business payloads. Parsers extract reason codes, object identifiers, and change verbs. Custom consumers should use IBM sample patterns or supported libraries rather than treating events as plain text strings—binary fields and coded enums break naive grep. Store parsed events in immutable audit storage with timestamp, queue manager name, command source, and correlation to change tickets.
Desired state lives in Git; runtime events prove what actually applied. Compare event stream to merge commit timestamps. Drift detection: ALTER in production without matching pipeline run id in ticket metadata should page security. Configuration events do not replace version control—they validate it.
Configuration events are security cameras pointed at the wiring closet—every time someone moves a cable (ALTER CHANNEL), the camera records it even if the network still works.
When a grown-up changes the rules of a board game (MQ objects), a bell rings and writes down what changed so nobody can say they did not touch the rules later.
List five ALTER commands you would alert on immediately in production and five you would ignore from automation.
Draw flow from ALTER QLOCAL to SIEM ticket in six boxes.
What happens if SYSTEM.ADMIN.CONFIG.EVENT hits MAXDEPTH? Write recovery steps.
1. Configuration events report:
2. Typical config event queue name pattern:
3. CONFIGEV on queue manager controls:
4. Config events help security teams detect: