Integration


This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.


Add a new idea Subscribe
Status Not under consideration
Workspace MQ, MQ Advanced & MQ Appliance
Created by Guest
Created on Jul 20, 2026

RELATED IDEAS

Queues involved in opentelemetry need a otelsamp option to specify how often data is sampled.

Currently  if you use opentelementy, all the records are sent to the data collector on z/OS and onto the opentelemetry collector running on midrange.   This collector has the ability to sample the records from z/OS and pick say every 10th record.

This is effectively useless for problem determination.   Having the collector sample the records, means that all records from DB2 CICS MQ etc are sampled - not just MQ.

 

If there is a slowdown  problem with MQ  I want to be collect more data for say 10 seconds - and not impact DB2, CICS etc.

I see an option OTELSAMP(n) where the value of n is one record ever n for this queue/queue manager.  so OTELSAMP(100) means produce a record every 100 message  OTELSAMP(1000) is produce a record once in every 1000 request.

If the value of n is changed - even if the value does not change, it should create the next record, and then start doing the sampling.  This makes it easier when there is a problem.  By changing the value it does like a "ping request" and the next message has the data produced.

 

This is complicated by I put to a remote queue, which goes to an XMITQ.  I can enable OTELSAMP on the request queue - but this does not mean that the XMITQ will output OTEL information.   When the message gets to the server, it may not honour the outputting of the otel data.   But at least I know ( from history) which queues are involved, and can reset the otelsamp value on each queue manager.

Having this option means I can investigate.  Without this option it is very difficult to investigate

Idea priority Low
  • Guest
    Jul 29, 2026

    Hi Colin,

    The whole point of OTel is that it gives you the enterprise view of your application flow rather than just the MQ view. It's often the case that customers don't know initially where the problem is at all, so narrowing down immediately in MQ is probably less likely than you think. If you already know there is an MQ problem then existing data, such as 115/116 is where you would likely go rather than OTel trace. The hope is that the OTel trace points a finger to where the problem is, and then you narrow down the problem from there.

    "The Opentelemetry collector can sample records - but does not know about queue managers." Right, but it does know about service names and it can sample based on any property name so you should be able to generate a suitable filter. See https://opentelemetry.io/blog/2022/tail-sampling/

    I should have also mentioned above that another option is to use head base sampling, whereby whichever application component is responsible for initially injecting the traceparent in the request only does so every 1/x requests.

    If you have a problem in your application flow, wherever that happens to be, you can up the sampling rate to narrow down the problem. This approach also reduces the amount of CPU used throughout the application stack, not just in MQ. 

    Some OTel provided documentation on sampling is here: https://opentelemetry.io/docs/concepts/sampling/

    Regards, Matt.

    Reply
  • Admin
    Matthew Leming
    Jul 29, 2026

    There are a variety of mechanisms that are evolving in the OTel specifications for trace. We would likely look to adopt those over time, rather than an MQ specific method.
    As a result we are declining this idea. While declined the idea can still be voted, and commented, upon.

    1 reply

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.