lmolkova
commented
1 month ago 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.
- 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?
- 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
- 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.
- 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?
- 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
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.
12) 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?