Bunny instrumentation is not following semconv

[thompson-tomo]

The problem

The implementation of the Bunny instrumentation is currently using the following attributes but they are not defined in the messaging namespace but there is attributes which should be used

• messaging.destination
• messaging.destination_kind
• messaging.operation
• messaging.protocol
• messaging.protocol_version
• net.peer.name
• net.peer.port
• messaging.rabbitmq.routing_key

Solution

Update the attribute keys being used

[github-actions]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.

[thompson-tomo]

Keep open

[bellvat]

Hi @thompson-tomo @kaylareopelle , I'd like to give this a try.

To clarify, the issue is that messaging.destination (and others in the list) are defined in the Bunny instrumentation, but not defined in
opentelemetry-ruby/semantic_conventions/lib/opentelemetry/semconv/
Am I understanding correctly?

I see that there is already a /messaging folder in opentelemetry-ruby/semantic_conventions/lib/opentelemetry/semconv/incubating/messaging/attributes.rb

Should I add the missing constants there?

Thanks!

[bellvat]

I think I did misunderstand. I see now that in opentelemetry-ruby/semantic_conventions/lib/opentelemetry/semconv/incubating/messaging/attributes.rb,
there are already relevant constants defined.

For example, I see MESSAGING_OPERATION = 'messaging.operation'.
However, it says that it is deprecated, and latest version is using MESSAGING_OPERATION_TYPE = 'messaging.operation.type'.

So we want to update Bunny instrumentation's attribute from messaging.operation to messaging.operation.type.

Is this the case?

[kaylareopelle]

We'd love your help on this @bellvat. I think the main problem is due to the lack of stability in the semantic conventions for messaging. There isn't a working group currently meeting for messaging, so we're not sure when they'll be marked as stable.

We have to keep the conventions aligned with specific versions, to make sure we don't break user's experiences. The current recommended way to update is to use the OTEL_SEMCONV_STABILITY_OPT_IN environment variable. There's a description of how this works at the top of the messaging conventions webpage.

Essentially, we have to make the old (current) conventions, the new conventions, and both available to users. We've implemented for the HTTP conventions and are working toward doing so for the DB conventions. Both of these OpenTelemetry Semantic Conventions categories have been marked stable.

We implemented a pattern in the HTTP conventions that prepends different modules based on the OTEL_SEMCONV_STABILITY_OPT_IN variable. Here's a good example: #1589

I think we'd like to use the same pattern for messaging, but given the uncertainty around stability, it's hard to know for sure.
@thompson-tomo, I'd love to hear your current thoughts on this.

[bellvat]

Hello @kaylareopelle, thank you for explaining how this works to me.

I do not see messaging in the Otel roadmap here.
Maybe its being developed as we speak and just not documented? Would it be discussed in the Semantic Conventions: General SIG?

For now, I will hold off on implementing anything. Please let me know otherwise. Thank you!