Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DESCR file in metrics #16

Closed
piotrekbed opened this issue Jul 5, 2019 · 5 comments
Closed

DESCR file in metrics #16

piotrekbed opened this issue Jul 5, 2019 · 5 comments

Comments

@piotrekbed
Copy link

Hi,
Is any chance to metrics return DESCR field and USAGE (for the queues).

BR
Piotrek

@ibmmqmet
Copy link
Collaborator

ibmmqmet commented Jul 6, 2019

DESCRIPTION is not a metric. As it's a string, the only way to have it passed to prometheus would be to add it as a label to the object but I'd rather not do that - the more labels on an entry in prometheus, the harder it has to work.

There's also danger of over-extending the capabilities of these monitors - why that attribute and not all the others from an object. (Although it is a config attribute I added MAXDEPTH as a metric to enable calculations rather than as an object descriptor/selector.)

I'm a bit more sympathetic to adding USAGE to allow graphs of transmission queues to be selected, but that does have similar attribute-vs-metric considerations.

A better approach might be to have a separate view in grafana that is selecting configuration attributes from another datasource. It's fairly easy, for example, to have Grafana extract information from MySQL tables that might be populated with your reasonably-static queue manager configuration.

@ibmmqmet
Copy link
Collaborator

v4.0.8 now has USAGE as a label on queue objects

@keithknott26
Copy link

keithknott26 commented Dec 10, 2019

By the way I came across this project and I was also looking for the DESCR() feature , the use case was to pass applicationName (which is currently in the (CHANNEL and QUEUE DESCR() fields) and use that as a label to prometheus so we could use it while filtering. Being able to have DESCR() will allow us to map channel and queue names directly to a applicationName using the built in MQ fields.

Is this reasonably straight forward to add? I see that you can't retrieve DESCR() directly it would have to be "looked up" and written as a channel and queue attribute. Perhaps I'll have a look at the MAXDEPTH() implementation and that will give me some ideas.

Edit: It looks like the MAXDEPTH() is looked up as part of the INQUIRE_Q call and this (among various other lines) would need to be edited to accommodate the DESCR() attribute. Would you know if a similar process exists for a channel? I'd need to do an "INQUIRE_CHL" and retrieve the DESCR() similar to the way INQUIRE_Q works I guess?

Thanks!
Keith

@ibmmqmet
Copy link
Collaborator

The most recent restructure of the code, where it's now doing a DISPLAY CHL to get some numeric attributes, makes it more feasible to add DESCR. I'll take another look at it next time I'm doing some updates.

@keithknott26
Copy link

That's great news, thanks very much!

ibmmqmet added a commit that referenced this issue Jan 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants