Last year, I released a program that would read MQ Event messages, format them, and send them directly to an OpenTelemetry backend. I wrote about it here. I’ve now extended it to also publish events to a Kafka topic.
Introduction
The amqsevtg (‘g’ for Go – the language it’s written in) program was effectively a clone of the product-shipped amqsevt, with the added capability of configuring an OTel backend. So you don’t need to use an intermediate procedure like sending output via a named pipe or having the OTel Collector program read from a redirected file.
But a recent question asked if it was possible to send MQ Events to Kafka. Although the amqsevt program could handle it similarly to the OTel situation by writing to stdout and then piping that to a Kafka-specific program reading stdin, it’s not the simplest path to setup. I got it working using the kafka-console-producer program (the equivalent of amqsput).
But how tricky would it be to do a more integrated solution?
Extending amqsevtg
Quite easy, as it turned out. It probably took about an hour to modify the program, and to start to test it.
There was already a well-encapsulated output path to OTel; a similar path to reach Kafka could go alongside. Configuration options can name the broker address and topic (I didn’t add more features like TLS configurations). And that’s essentially all.
The Apache Kafka project does not have a native Go client; most things there are done in Java. But there are several alternative implementations available. I picked the IBM Sarama package as it is a Go-native option.
Differences in the consumer implementation options were not relevant, as this program only writes to a single topic, and the Confluent-provided Go client required cgo, as it is just a wrapper around the C client library.
Why send events to Kafaka?
Sending events to something billed as an event streaming solution feels like a natural option. And there are then a range of analytics programs that can read the events from Kafka and generate reports or potentially take action.
It’s not really any different than working with an OTel-based stack, but the choice will probably depend on what you already have in place.
Running the program
Once I had a Kafka broker running, I defined the mqevents topic that I was planning to use.
Then run something to read messages from that topic:
kafka-console-consumer.sh -bootstrap-server localhost:9092 --topic mqevents
And finally, start the formatter against a queue manager. The compact option causes single lines of output:
go build -o amqsevtg .
./amqsevtg -kb localhost:9092 -kt mqevents -o compact -m EVENTS
The default maximum message size for Kafka is 1MB, which is easily large enough for event messages.
The output is what you would expect. JSON-formatted event messages for easy parsing by other programs:
"eventSource": {
"objectName": "SYSTEM.ADMIN.QMGR.EVENT",
"objectType": "Queue",
"queueManager": "EVENTS"
},
"eventType": {
"name": "Queue Mgr Event",
"value": 44
},
"eventReason": {
"name": "Put Inhibited",
"value": 2051
},
"eventCreation": {
"timeStamp": "2026-11-10T09:06:43.06Z",
"epoch": 1794301603
},
"eventData": {
"applName": "amqsput",
"applType": "Unix",
"qMgrName": "EVENTS",
"qName": "X"
}
Summary
Exploring different options can be fun. I already had a Kafka environment available for other reasons, so this enhancement did not take long to code and test. Maybe it gives you more ideas on how to use these events, which are so important when monitoring an MQ queue manager.
This post was last updated on November 10th, 2026 at 11:30 am