If I "read between the lines" here ...
We could use the ELK stack RESTful services, but we don't want to tightly couple our business transactions with the ELK backends (we had a bad experience some months ago).I take this to mean that they've experienced blocking or performance issues when putting data "on the wire" within the transaction process.
Enter zeroMQ. It is a lightweight, zero configuration messaging system ...Let's use something that purports to be light on the sending side to avoid bogging down the transactions and protect us from transmission or backend delays via buffering.
What we would do is to have a bunch of zeroMQ consumers as started tasks which would use the RESTful API to send stuff to ELK, while the PL/1 transactions would send asynchronously to the 0MQ queues.And this is how we would configure to for availability/capacity.
Given these concerns and how you are looking to address them, the location of the ELK backend (IFL, x86 servers, someone's cloud) does not appear to be interesting at the moment.
I have no idea whether the C++ zeroMQ implementation would successfully compile on z/OS nor any concept of whether or not it would perform to your needs. I would suggest considering Java (JeroMQ) implementation to "offload" this processing to a zIIP specialty engine (if you have any).
For the C++ implementation, the additional consumption of general purpose processor capacity will likely be proportional to message rate; because of this, the C++ version may wind up consuming more general purpose (MLC chargeable) capacity than you might want to pay for. Depending on your MLC scheme, this could drive up IMS (and other MLC product) costs.
If zeroMQ doesn't work out, there are a number of other open source MQ implementations that offer Java implementations (e.g. ActiveMQ), as well.