Enable Metrics for RabbitMQ Component

[eerhardt]

RabbitMQ's current version is 6.6.0, which doesn't have any meters/event counters.

However, they have an alpha 7.0 version out, which does have event counters - see https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/a0321c6c2203cedeacdd5c1ec5bcdc924e85a842/projects/RabbitMQ.Client/client/logging/RabbitMqClientEventSource.Counters.cs#L51-L58.

When we have a RabbitMQ component that depends on v7, we should enable Metrics via these EventCounters.

[danmoseley]

For future ref their commit was rabbitmq/rabbitmq-dotnet-client@6e6ab3e and indeed it's only in v7+.

Looks like they're pretty early in their v7 so it will be a question of whether it's stable in time for us to ship with it.

[davidfowl]

@eerhardt backlog or will we get this in preview?

[eerhardt]

@eerhardt backlog or will we get this in preview?

I don't expect RabbitMQ v7 to be released before Aspire's 8.0 release. (But would be pleasantly surprised.)

[eerhardt]

We have support for RabbitMQ v7 now with #6770.

However, an issue is that we don't/can't use the OpenTelemetry.Instrumentation.EventCounters nuget package to pull EventCounters into OTel Metrics. See #2819 - OpenTelemetry.Instrumentation.EventCounters does not ship a "stable" version, which means our client integration library can't depend on the package (or else it can't be "stable").

Options we have to move forward here:

1. Push for RabbitMQ.Client to use System.Diagnostics.Metrics.Meter instead of (or in addition to) EventCounters.
2. "Vendor"/copy in the source code for OpenTelemetry.Instrumentation.EventCounters like we do for other opentelemetry-dotnet-contrib libraries.
3. Don't add the metrics for now and wait for OpenTelemetry.Instrumentation.EventCounters to go stable.

cc @samsp-msft @noahfalk

[maddymontaquila]

Sounds good. Any of those are fine with me so I'll leave it up to you / @samsp-msft / @noahfalk to make a call on this one

[noahfalk]

I think the ideal option is moving to Meters (option 1). The Meter API is our default recommendation for anything new as it is more flexible, more powerful, and aligned with OpenTelemetry, a growing industry standard. (https://learn.microsoft.com/en-us/dotnet/core/diagnostics/compare-metric-apis)

If for whatever reason Meters is off the table then we could weigh the pros and cons of (2), (3), or add option (4) do nothing. I don't know if OTel is seeing enough demand that their EventCounters instrumentation will ever get promoted to stable. EventCounters are more like a back-compat bridge and demand is probably going down over time rather than up at this point.

[eerhardt]

It looks like there are a few discussions in the RabbitMQ repo regarding using Meters.

• Implements OTEL Metrics based on standard dotnet on system diagnostics rabbitmq/rabbitmq-dotnet-client#1733
• Capturing of Metrics about message sent/recieved rabbitmq/rabbitmq-dotnet-client#1459

@stebet - I see you've been heavily involved in adding OTel support for the RabbitMQ.Client library. Any thoughts on what should be done here? Do you think it is feasible to get RabbitMQ.Client to start using Meters (either instead of or in addition to) the existing EventCounters?

[stebet]

@stebet - I see you've been heavily involved in adding OTel support for the RabbitMQ.Client library. Any thoughts on what should be done here? Do you think it is feasible to get RabbitMQ.Client to start using Meters (either instead of or in addition to) the existing EventCounters?

Certainly :) I'll take a look at it soon.