OpenTelemetry: Update messaging.operation span attribute to latest OTel Semantic Conventions

[iinuwa]

Is your feature request related to a problem? Please describe.

The Activities in RabbitMQ client currently emit the messaging.operation attribute. However, the Semantic Conventions for messaging currently specify use messaging.operation.type for the values that are currently being set there, and to add messaging.operation.name to values like ack, nack, etc.

Describe the solution you'd like

At minimum, changing the messaging.operation attribute to messaging.operation.type would be helpful to comply with the conventions.

Adding messaging.operation.name would also be helpful for tracking the number of/searching for acks vs. nacks in the system. I'm not sure if there's a good place to add this in this library though; perhaps it would need to be done in higher level libraries.

Additional context

References #1528.

[michaelklishin]

@lukebakken sounds like a reasonable last minute 7.0 change? 😢

[michaelklishin]

@iinuwa you are welcome to submit a PR that would rename the attribute. Whether it can ship in 7.0.0, I don't know. It sounds like the right moment to do it, since this feature is very new (in general and new in 7.x).

[alrz]

I'm not sure if there's a good place to add this in this library though

That would be actually quite useful if supported built-in as some generic .net metrics.

[michaelklishin]

It's surprising that messaging.operation.name reflects an operation type and messaging.operation.type is… for I'm not sure what, a different type.

In any case, renaming a metric for 7.0 sounds acceptable. Introduction of an another metric will have to go into 7.1, you are welcome to submit PRs.

[iinuwa]

Thanks Michael.

It's surprising that messaging.operation.name reflects an operation type and messaging.operation.type is… for I'm not sure what, a different type.

Yeah, I'm kind of confused too. I think type is supposed to be generic/constrained for creating dashboards across different messaging systems and name can be whatever you want. 🤷🏿‍♂️

In any case, renaming a metric for 7.0 sounds acceptable.

Added #1716 for changing the attribute name to messaging.operation.type. I also updated the corresponding attribute and operation name values to non-deprecated values since it seemed related.

[michaelklishin]

OpenTelemetry support was originally contributed in #1528 by @stebet, @lmolkova and others. Perhaps we should also ask for their opinion.

[lukebakken]

I am pinging these people because they all reviewed #1528 -

@danielmarbach

@lmolkova

@martinjt

@Kielek

@cijothomas

@WeihanLi

[lmolkova]

It's surprising that messaging.operation.name reflects an operation type and messaging.operation.type is… for I'm not sure what, a different type.

Yeah, I'm kind of confused too. I think type is supposed to be generic/constrained for creating dashboards across different messaging systems and name can be whatever you want.

This is exactly the point. We want systems to have operation names that use their own terminology, but we also need unified type that's common across different systems. The latter one is useful for common dashboards, alerts and helps to move between messaging systems.

There could also be multiple different operation names with the same type. E.g. Azure ServiceBus has receive, peek and receive_deferred operation names which all map to receive type. Or there could be some operations like admin ones that have a name, but don't have a type since it does not make much sense to unify them across systems.

I hear you both that it's confusing. Let me know if you have any thoughts on how to make it less confusing :)

PS: will take a look at #1716

[iinuwa]

I'll take a look this morning, thanks!

[michaelklishin]

@lmolkova this is probably not the right place to discuss this but messaging.operation.type seems to cover both messaging and topology operations, which is not wrong per se but then why does it have create but not delete? If you declare a queue or a stream, they won't necessarily live forever.

As for .name, it is a parallel track of operations. If I was designing this today,
I'd use

1. messaging.operation.type: create | delete | publish (or send) | deliver (or receive) | ack | nack | message_return (a message was returned) | consumer_registration | consumer_cancelation
2. messaging.operation.subtype then would replace messaging.operation.name as a field that can contain arbitrary information

In any case, our team understands that it's not a decision our team will probably influence a great deal, so we will follow the current naming scheme even if it leaves a bit to be desired.

[lmolkova]

Thank for the feedback! You can actually influence our design quite a lot - this is a perfect time for it (we plan to stabilize sometime soon and after that breaking changes will have very high bar).

why does it have create but not delete. If you declare a queue or a stream, they won't necessarily live forever.

The messaging.operation.type only covers operations for which we see a strong need for unification. E.g. you create a dashboard that shows messaging throughput. You can get number of incoming messages by filtering by operation type == send (plus any other dimensions) - you can do this whether you use RabbitMQ or Active MQ.

When tracing backends visualize stuff, they need to know some things about these special operations to visualize them nicely.

But also, if I use e.g. Azure ServiceBus, having a common name send is not covering all cases. e.g. I can schedule a message, so I need something else to show the real operation name.

When it comes to queue/consumer deletion - these operations seems to be less of an interest when it comes to visualizations/common dashboards at least at the moment.
I.e. you can have an arbitrary, broker-friendly name and not having a type defined won't hurt anyone. We can definitely grow a list of recognized operation types over time and include things like consumer_registration.

As for .name, it is a parallel track of operations. If I was designing this today,

Do you feel that the messaging.operation.name is confusing in some way? Why would you prefer the messaging.operation.subtype ?

we picked this name because it aligns well with similar notions we have for other technologies (e.g. we have db.operation.name or gen_ai.operation.name). It's more than a subtype - that's actually the primary thing people who use your library/system know about their operation.

messaging.operation.type: create | delete | publish (or send) | deliver (or receive) | ack | nack | message_return (a message was returned) | consumer_registration | consumer_cancelation

That's where things get tricky with operation types. They need to apply to most of the messaging systems. E.g. ack/nack/checkpoint/commit/completion/abandonment/dead lettering are all forms of settlement. For this one we want to unify since it's such an important part (you want to know how message processing has ended).

As I mentioned above, consumer_registration|cancellation|etc could be added incrementally.

In any case, happy to hear your thoughts