Change unique metrics collected

[z5d69]

We're using a recent version of mq-metric-samples and would like to configure the following:

Reduce metrics exported - right now we're exporting a large number of MQ metrics that we don't need (really, we only need maybe 2-3 distinct metrics per queue). Is there a way to set the metric set to the number we need? I see queue and channel properties but nothing for metrics.

[Bert99Blib]

Hi all,

We have a similar challenge. We would certainly want to use more than 2 or 3 metrics, but are now forced to configure the 'jobname' field in particular out of the channel information, as this leads to a very bad cardinality in the database.

Therefore, I am very curious what possibilities there are (or could be) without having to adapt the code for each release (which we are currently considering in order to be able to use the mq-metric-samples at all).

[ibmmqmet]

The queueSubscriptionSelector configuration option reduces some of the metrics collected. I normally have it set to "PUT,GET & GENERAL". But the dynamic model for the publication of metrics means that we don't necessarily know in advance what the different metric names are going to be, or how many there can be. A single subscription to the qmgr will return multiple metrics. There's not a lot of metrics coming from the QSTATUS responses. I couild imagine some sort of configuration option where you give an explicit list of the metric names you are interested in, once you know what they are, but it feels messy and probably bad for performance (eg having to do a pattern match on each available metric on each collection cycle as we can't filter in advance).

[ibmmqmet]

On the jobname comment, is this specific to certain types of channels? SDR/RCVRs ought to usually be long-running so the jobname remains constant through the lifetime of that channel instance. For SVRCONN channels, it's going to be more varied, especially if you have clients continually connecting/disconnecting (which is usually considered a bad pattern anyway). I can see how an option that sets the jobname to a fixed value on SVRCONNs might reduce that variation, but at the same time you lose the distinctiveness and the ability to see information about the multiple instances of the same channel name that might be running.

[Bert99Blib]

jobname again

We mainly use SRVCONN channels, which of course also have long-lasting connections for the most part.
Since we have between a few hundred and many thousands of connections per stage, a lot of data is entered into the Prometheus database during a scraping interval - even if we do not need it to monitor our systems. Job name is absolutely negligible for us in this case. If problems arise, we can already make sufficient restrictions with the combination of Channel + Connection Name.

Your suggestion to fill the field 'job name' with a literal should be very helpful for our purposes. Even though I am not a go programmer, the change should be possible with the change in 'exporter.go' on line 451.

Many thanks for your quick answer

[z5d69]

@ibmmqmet more specifically, we only need at the moment and for certain environments: queue depth, qmgr stats, queue oldest message age, qmgr and channel status. Queue metrics in particular are only a killer because of the sheer number of queues we have. I searched in the code repository for queueSubscriptionSelector but didn't really see what metrics would fall into PUT, GET, GENERAL (iow, if I were to deactivate these, which one(s) would leave us with what we need?

[ibmmqmet]

See https://www.ibm.com/docs/en/ibm-mq/9.2?topic=trace-metrics-published-system-topics for the values returned by various classes and types. Or you can explore them yourself using the amqsrua sample program.

[z5d69]

@ibmmqmet Okay, understood. Either General or Put depending on MQ version. For ibmmq_qmgr_status and ibmmq_channel_status, do those ALWAYS get provided or always as long as the sourced metric is available?

[ibmmqmet]

The useObjectStatus configuration option controls whether the collectors use the DISPLAY xxSTATUS commands, and hence produce the corresponding metrics. It's global in that it controls the status queries for all object types including channels and the qmgr itself. If it's disabled, then you wouldn't see ANY channel information.

[z5d69]

Thanks!