running as a client

[salapat11]

Can the go binary run on a server without MQ installed? I get this error - error while loading shared libraries: libmqm_r.so: cannot open shared object file: No such file or directory

[ibmmqmet]

You always need the MQ code installed somehow.

[salapat11]

Thank you. I configured the exporter to remote to a queue manager on z/OS.
mq_prometheus -ibmmq.queueManager=$qMgr -ibmmq.monitoredQueues="$queues" -ibmmq.monitoredChannels="$channels" -log.level=debug -ibmmq.qStatus=true -ibmmq.client=true After running the above command, these are the logs - INFO[0000] Starting IBM MQ metrics exporter for Prometheus monitoring INFO[0000] Connected to queue manager TGV1
FATA[0030] MQGET: MQCC = MQCC_FAILED [2] MQRC = MQRC_NO_MSG_AVAILABLE [2033]

What could be the issue?

[ibmmqmet]

Probably not getting a response from the command server for some reason while querying the list of queues. The agent waits for 30 seconds so that ought to be enough. But I don't know how errors (perhaps authorisation problems?) get reported on z/OS for PCF problems. Perhaps something in the JES logs.

[salapat11]

Thanks again. I'll check them. The qmgr and queue don't have any authorization at this time.

[salapat11]

Is there a way to pass the host information for the remote queue manager thru the config? Right now, I set the MQSERVER environment variable.

[ibmmqmet]

MQSERVER is one way, or use a CCDT with suitable environment variables to point at that. There's no additional programmatic client configuration implemented.

[salapat11]

The monitor program connects to the queue manager and fails to read from the temporary queue for inquiring the queue pattern. The error was MQGET: MQCC = MQCC_FAILED [2] MQRC = MQRC_NO_MSG_AVAILABLE [2033]. The string that was put on the command queue for inquiry was “$$?TGV1.DEAD.QUEUE”.

Tried the same test on a distributed queue manager and there were no issues. The string for inquiry was “$(?POC.TEST_MQV9_REQ”.

The command for the monitor program was - /exporter/mq_prometheus -ibmmq.queueManager=TGV1 -ibmmq.monitoredQueues="TGV1.DEAD.QUEUE" -ibmmq.monitoredChannels="*" -log.level=debug -ibmmq.qStatus=true -ibmmq.client=true -ibmmq.httpListenPort=9700

Is there any setting that we missed?

[ibmmqmet]

I don't know where the odd characters at the start of those inquiry strings come from - what are you using to look at the messages? Messages put to the command queue are binary PCF formats, so you shouldn't expect to read them as strings.

Is there anything in the JES log on z/OS to indicate an error? The normal configuration for a z/OS queue manager has SYSTEM.ADMIN.COMMAND.QUEUE defined as an alias to SYSTEM.COMMAND.INPUT, and the queue manager's COMMANDQ attribute set to SYSTEM.COMMAND.INPUT.

[salapat11]

There is nothing on z/OS logs about the 2033. I'll check the other configuration. I'm running the monitor program in a container. Tried with both 9.1.0.0 and 9.1.1.0. I could not find a base image for 9.0.5.0. Does the MQ version on the container have any impact?

[ibmmqmet]

MQ version shouldn't matter

[salapat11]

We have a Java sample working without any issue to inquire the queue names on the z/OS queue manager.

[salapat11]

After updating the settings for SYSTEM.ADMIN.COMMAND.QUEUE metrics are exposed

[ibmmqmet]

What settings did you update? I'll see if they can be detected in future. And/or I'll switch to using the SYSTEM.COMMAND.INPUT queue directly instead.

[salapat11]

SYSTEM.ADMIN.COMMAND.QUEUE was defined as a local queue rather than an alias queue. After your comment above, we updated it as the alias to SYSTEM.COMMAND.INPUT.

[abtmamr]

This is just an FYI, I had a similar error. My queue manager was running on a Windows server.

Resolution :

Amended Queue manager Publish/Subscribe mode attribute to enabled. It was initially set to Compatibility