Area(s)
area:messaging
Propose new conventions
#4080
What I would like to define
Two additions to the messaging conventions, both for spans:
messaging.ibmmq.queue_manager.id, a new string attribute in a new registry.messaging.ibmmq group. It carries IBM MQ's queue manager identifier, MQCA_Q_MGR_IDENTIFIER, formatted <QUEUE_MANAGER_NAME>_YYYY-MM-DD_HH.MM.SS and generated when the queue manager is created.- An
ibmmq member for the existing messaging.system enum, pinned on IBM MQ producer, receive and process span refinements the way kafka and rabbitmq already pin theirs.
No metrics or logs, and no change to any existing attribute's meaning.
Why the identifier is needed
Queue manager names are not globally unique. In a federated MQ estate two hosts can each run a queue manager called QM1, and that is ordinary rather than an edge case. A span today carries the destination and at best a queue manager name, so a telemetry consumer cannot say which physical queue manager an application talked to, and cannot join an application span to queue manager level infrastructure telemetry, because the only shared key collides. The identifier is globally unique and solves exactly that.
It is also cheap to collect. Both IBM's JMS client and IBM's XMS.NET client already resolve and cache the queue manager identity on the connection at MQCONN time and expose it through their own property bag, so instrumentation reads it from memory rather than issuing an MQINQ round trip. It has to be reported with the trailing padding of the fixed width MQI character field removed.
Why the system value is needed
IBM MQ traffic currently reports messaging.system as jms, which names the API the application used rather than the broker behind it. That makes IBM MQ indistinguishable from any other JMS provider, and it does not carry across languages: the mainstream Node.js and Python IBM MQ bindings wrap the MQI C client rather than JMS, so they cannot report jms at all. ibmmq would also be the only messaging attribute group without a matching enum member if it were left out.
Who would implement it
Three instrumentations, two already written and emitting the attribute against a live queue manager, with the value checked against DIS QMGR QMID:
Both existing prototypes keep the attribute behind an experimental flag, off by default, precisely because none of this is ratified yet.
On area ownership
I am aware AREAS.md marks messaging inactive and needs_staffing, and that an earlier pull request of mine was auto closed for that reason rather than on its merits. I am not asking to route around that. I would like to know whether this is small enough to proceed without forming a SIG, or whether a messaging project needs staffing first, and I am willing to be the point of contact for the IBM MQ part either way. I will also raise it in #otel-semantic-conventions.
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
Area(s)
area:messaging
Propose new conventions
#4080
What I would like to define
Two additions to the messaging conventions, both for spans:
messaging.ibmmq.queue_manager.id, a new string attribute in a newregistry.messaging.ibmmqgroup. It carries IBM MQ's queue manager identifier,MQCA_Q_MGR_IDENTIFIER, formatted<QUEUE_MANAGER_NAME>_YYYY-MM-DD_HH.MM.SSand generated when the queue manager is created.ibmmqmember for the existingmessaging.systemenum, pinned on IBM MQ producer, receive and process span refinements the waykafkaandrabbitmqalready pin theirs.No metrics or logs, and no change to any existing attribute's meaning.
Why the identifier is needed
Queue manager names are not globally unique. In a federated MQ estate two hosts can each run a queue manager called
QM1, and that is ordinary rather than an edge case. A span today carries the destination and at best a queue manager name, so a telemetry consumer cannot say which physical queue manager an application talked to, and cannot join an application span to queue manager level infrastructure telemetry, because the only shared key collides. The identifier is globally unique and solves exactly that.It is also cheap to collect. Both IBM's JMS client and IBM's XMS.NET client already resolve and cache the queue manager identity on the connection at
MQCONNtime and expose it through their own property bag, so instrumentation reads it from memory rather than issuing anMQINQround trip. It has to be reported with the trailing padding of the fixed width MQI character field removed.Why the system value is needed
IBM MQ traffic currently reports
messaging.systemasjms, which names the API the application used rather than the broker behind it. That makes IBM MQ indistinguishable from any other JMS provider, and it does not carry across languages: the mainstream Node.js and Python IBM MQ bindings wrap the MQI C client rather than JMS, so they cannot reportjmsat all.ibmmqwould also be the only messaging attribute group without a matching enum member if it were left out.Who would implement it
Three instrumentations, two already written and emitting the attribute against a live queue manager, with the value checked against
DIS QMGR QMID:Both existing prototypes keep the attribute behind an experimental flag, off by default, precisely because none of this is ratified yet.
On area ownership
I am aware
AREAS.mdmarks messaginginactiveandneeds_staffing, and that an earlier pull request of mine was auto closed for that reason rather than on its merits. I am not asking to route around that. I would like to know whether this is small enough to proceed without forming a SIG, or whether a messaging project needs staffing first, and I am willing to be the point of contact for the IBM MQ part either way. I will also raise it in#otel-semantic-conventions.Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it. Learn more here.