Performance events are IBM MQ way of ringing a bell when workload crosses a line you drew in advance—queue depth above ten thousand, depth back below one hundred, channel entering RETRY, or other threshold conditions defined in object attributes and queue manager policy. Metrics platforms sample every thirty seconds; a depth spike between scrapes can still trigger a performance event the moment CURDEPTH crosses QDEPTHHI. Beginners enable PERFMEV globally but never set QDEPTHHI on queues, then conclude events do not work. This tutorial explains queue manager and queue attribute knobs, channel-related performance notifications where supported, event message delivery to SYSTEM.ADMIN.PERFM.EVENT, building consumers and SIEM rules, calibrating thresholds to avoid alert fatigue, pairing events with Grafana and Prometheus, and differences from configuration and security event streams.
ALTER QLOCAL sets QDEPTHHI to the message count that defines high water—for example 8000 when MAXDEPTH is 10000. QDPHIEV controls whether a high event generates when depth crosses upward through QDEPTHHI. QDEPTHLO and QDPLOEV define the low side—useful to detect consumer recovery when depth drains below a small number. MONQ must be ENABLED on the queue for monitoring events to apply. Each attribute has operational meaning: QDEPTHHI too low pages constantly during normal batch; too high and you learn about backlog after the application is already failing.
| Attribute | Purpose | Beginner tip |
|---|---|---|
| MONQ | Enable monitoring events for this queue | ENABLED on tier-1 queues only if noise is a concern |
| QDEPTHHI | High threshold message count | Often seventy to eighty percent of MAXDEPTH |
| QDPHIEV | Generate event on high crossing | ENABLED when you want notifications |
| QDEPTHLO | Low threshold message count | Small value for drained signal |
| QDPLOEV | Generate event on low crossing | Use for recovery confirmation |
12345678ALTER QMGR PERFMEV(ENABLED) DISPLAY QMGR PERFMEV ALTER QLOCAL('ORDERS.IN') MONQ(ENABLED) QDEPTHHI(8000) QDPHIEV(ENABLED) + QDEPTHLO(100) QDPLOEV(ENABLED) DISPLAY QLOCAL('ORDERS.IN') MONQ QDEPTHHI QDPHIEV QDEPTHLO QDPLOEV DISPLAY QLOCAL('SYSTEM.ADMIN.PERFM.EVENT') CURDEPTH
Channel performance events can notify on state changes such as entering retry or stopping—exact capabilities depend on MQ version and channel MONCHL settings. Pair channel events with CHSTATUS metrics so operators receive an event message and can open Grafana to see duration in RETRYING. Pub/sub and listener objects have their own monitoring attributes on some releases—check IBM documentation rather than assuming parity with QLOCAL.
For each tier-1 queue document MAXDEPTH, chosen QDEPTHHI, expected peak depth during batch, and consumer recovery time. If batch normally peaks at 6000 and MAXDEPTH is 10000, QDEPTHHI 7500 gives warning before hard cap. Add Prometheus alert at eighty-five percent as backup when scrape interval is sixty seconds. Performance events win on fast spike detection; metrics win on trending and dashboards.
Performance events are float switches in a tank—they click when water hits a line, not on every drop added.
When the toy box gets fuller than the red line you drew, a bell rings. When it empties below the green line, another bell says the room is tidy again.
Calculate QDEPTHHI at seventy-five percent for MAXDEPTH 50000 and write MQSC ALTER line.
Compare one scenario handled better by performance events than by thirty-second Prometheus scrape.
Write consumer pseudocode: on depth high open ticket; on depth low close ticket.
1. Performance events typically include:
2. MONQ(ENABLED) on a queue means:
3. QDEPTHHI defines:
4. PERFMEV on queue manager enables: