Semantic Conventions for Messaging Spans

[mamwl1]

I'm looking at how these conventions, particularly the spans, could apply to IBM MQ (https://www.ibm.com/docs/en/ibm-mq/9.4).
IBM MQ provides support for both point to point messaging, via queues, and publish subscribe messaging via topics.

I have the following comments / questions, which it would be good to discuss at a future Messaging SIG.

1. The conventions read as very pub/sub focussed. For example, use of the word publish when sending a message to a queue doesn't feel right to me. Ideally there would be a discussion around both queue based and topic based messaging. I guess point to point could be treated as a special case of pub/sub but that doesn't feel great.

2. Is it a correct assumption that "message creation context" (https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/#context-propagation) should be a child of any context associated with the publishing environment? I was expecting a bit more of a discussion of that aspect in the context propagation section.

3. Should there be an attempt to name JMS message headers which can be used for context propagation? It would be really useful to start having something more concrete in this space.

4. For operation type, as mentioned above it would be good to have "send" here for queue based operations, this would map to a PRODUCER span kind.

5. I was surprised that there wasn’t a messaging.producer namespace, it seems like a logical partner to messaging.consumer

6. The concept of expiry, priority and persistence is common in messaging systems, and defined in the JMS spec. It would be good to have them defined in the messaging.message namespace. Same for reply queue

7. In many of the examples, for example https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/#topic-with-multiple-consumers, a span link is used to relate the consumer spans to the producer span. Why isn’t the parent used instead?

8. “messaging.destination.name” is this the name before or after name resolution, compare to span name which does refer to being after name resolution

9. For span name: “Wherever possible, the real destination names after resolving logical or aliased names SHOULD be used.” I would have thought it would be better to actually use the name that the application provided, with the real destination name elsewhere. App developers / owners might not be aware of the real destination name.

10. I was surprised about “or a value obtained from a Reply-To header, it SHOULD NOT be used for the span name.” what’s the rationale behind that? I could understand this if it was a dynamic destination name, but this implies that it is always the case.

11. I wonder when anyone would use messaging.system =jms? You need an implementation of JMS so wouldn’t the vendor name always be used instead?

[lmolkova]

Thanks for the feedback @mamwl1 !

I'll try to address some of the concerns here, but it would be awesome if you could join one of the messaging SIG calls to discuss it in more details.

1. The conventions read as very pub/sub focussed. For example, use of the word publish when sending a message to a queue doesn't feel right to me. Ideally there would be a discussion around both queue based and topic based messaging. I guess point to point could be treated as a special case of pub/sub but that doesn't feel great.

Could you please give some examples of pub/sub terminology:

• which attributes/metrics look weird for IBM MQ?
• how would you rename them?

2. Creation context

That's correct - messaging span is created in whatever context the message is enqueued/created at. I agree it's worth documenting better

4. would be good to have "send" operation name

We now have messaging.operation.name that also appears in the span name which can be anything - this is a recent addition. Messaging systems are encouraged to use their own terminology there. It could also be relevant for p1.

5. Producer namespace

We don't have any attributes to put in this namespace. What would be the benefit of reserving a namespace without anything that goes into it?

7. a span link is used to relate the consumer spans to the producer span. Why isn’t the parent used instead?

Link is a requirement (because if messages are received in a batch, you can't use parent-child relationships), parent is optional - i.e. instrumentation may use parent if there is just one message. We're getting similar feedback from others and will document it better.

8, 9, 10, span name, destination name

We've recently updated and cleaned up span name section, please check if these points still apply to the the current version here https://github.com/open-telemetry/semantic-conventions/blob/main/docs/messaging/messaging-spans.md

3 JMS headers
6 JMS expiry, priority, persistence
11 messaging.system = jms

If somebody comes and contributes any additions, cleanups or removals around jms, we'd be happy to consider and review them.

[mamwl1]

Hi Liudmila, Thanks for the comments. I keep getting clashes, otherwise I would have attended sooner. I should be able to make the one next week on the 25th. See you there. Some replies in line in green. Regards, Matt. Matt Leming STSM, IBM MQ for z/OS Email: ***@***.******@***.***> From: Liudmila Molkova ***@***.***> Sent: Friday, July 12, 2024 3:08 AM To: open-telemetry/semantic-conventions ***@***.***> Cc: Matthew Leming ***@***.***>; Mention ***@***.***> Subject: [EXTERNAL] Re: [open-telemetry/semantic-conventions] Semantic Conventions for Messaging Spans (Issue #1205) Thanks for the feedback @mamwl1 ! I'll try to address some of the concerns here, but it would be awesome if you could join one of the messaging SIG calls to discuss it in more details. 1, The conventions read as very pub/sub focussed. For example, Thanks for the feedback @mamwl1<https://github.com/mamwl1> ! I'll try to address some of the concerns here, but it would be awesome if you could join one of the messaging SIG calls to discuss it in more details. 1, The conventions read as very pub/sub focussed. For example, use of the word publish when sending a message to a queue doesn't feel right to me. Ideally there would be a discussion around both queue based and topic based messaging. I guess point to point could be treated as a special case of pub/sub but that doesn't feel great. Could you please give some examples of pub/sub terminology: As mentioned before, use of publish both in the text and in the attributes is the biggest thing that doesn’t feel right for point to point, queue based, scenarios. It would be good to have a “send” operation type which feels like a better match for point to point. I would expect that to be widely applicable. Similarly messaging.destination_publish bakes in the idea of pub/sub so it would feel strange to use it for point to point. * which attributes/metrics look weird for IBM MQ? I don’t think any of the attributes look particularly weird for MQ. Its more just a couple of the possible values as mentioned earlier. Obviously some don’t apply, but that’s to be expected. Metrics look reasonable too. But again I not that the word publish, e.g. messaging.publish.duration isn’t great for point to point scenarios. I haven’t looked in depth at the metrics yet. * how would you rename them? I wouldn’t. 1. Creation context That's correct - messaging span is created in whatever context the message is enqueued/created at. I agree it's worth documenting better OK, thanks for clarifying. 1. would be good to have "send" operation name We now have messaging.operation.name that also appears in the span name which can be anything - this is a recent addition. Messaging systems are encouraged to use their own terminology there. It could also be relevant for p1. Right, but I was thinking of operation type. 1. Producer namespace We don't have any attributes to put in this namespace. What would be the benefit of reserving a namespace without anything that goes into it? Even if there was nothing in messaging.producer, you could at least have something saying that messaging.{system}.producer.* is an appropriate location for producer attributes from specific messaging systems. I would expect MQ to want to make use of this namespace. 1. a span link is used to relate the consumer spans to the producer span. Why isn’t the parent used instead? Link is a requirement (because if messages are received in a batch, you can't use parent-child relationships), parent is optional - i.e. instrumentation may use parent if there is just one message. We're getting similar feedback from others and will document it better. MQ doesn’t do batch receives so the use of a span link when the trace parent would already be in the span seems like extra overhead. It would be good if the docs made it clearer that parent and no link is OK in non-batch scenarios. 8, 9, 10, span name, destination name We've recently updated and cleaned up span name section, please check if these points still apply to the the current version here https://github.com/open-telemetry/semantic-conventions/blob/main/docs/messaging/messaging-spans.md OK, I will take a read before next week. 1. JMS headers 2. JMS expiry, priority, persistence 3. messaging.system = jms If somebody comes and contributes any additions, cleanups or removals around jms, we'd be happy to consider and review them. OK, I will find some time to do that. — Reply to this email directly, view it on GitHub<#1205 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEHSGHRFFAPVEQZFUX7CUZ3ZL43A5AVCNFSM6AAAAABKJIKAHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRUGI4TINBZGE>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>> Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

[joaopgrassi]

@mamwl1 looking at the thread here, I feel we talked about every item, so I'm wondering if there's anything here left you'd like to address? If not, then we can close this as either we did it all or we have tickets for the other items.

[mamwl1]

@joaopgrassi yes, I agree this can be closed.