Capturing of Metrics about message sent/recieved

[thompson-tomo]

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

I want to get an understanding of how many messages are being sent & received by each instance of my applied.

Describe the solution you'd like

I would like to export the following metrics from the library so that I can analyse them:

• Qty Message sent
• Qty Message recieved
• Time for message sent to be acknowledged

Metrics need to also be capturing metadata which can be used for filters which include

• Application Id
• Message type
• message content type
• Persistent
• Priority
• User
• consumerTag
• deliveryTag
• exchange
• redelivered
• routingKey

Describe alternatives you've considered

No response

Additional context

Metrics would be collected by an OTEL collector for aggregation, transmission & analysis

[michaelklishin]

There are no plans to add longer term storage for RabbitMQ metrics.

Prometheus and Grafana already do a very good job of storing, filtering, alerting, visualizing and sharing metrics over longer periods of time.

I am not sure what "value being result" means but if you want RabbitMQ to collect metrics on messages in your app, I'd say that those are your application's metrics and arguably should be collected by your publishers and consumers. Prometheus and Grafana can aggregate values in a way that may work as a good alternative when there are few queues. Grafana technically can visualize per-queue metrics systems with tens of thousands of queues but making sense of such charts for a human will be effectively impossible.

[thompson-tomo]

This request is purely focused on the client's (dotnet) to be able to produce metrics about sent & received messages. This capturing would occur via System.Diagnstics.Meter. An OTEL collector is responsible for collecting/transmitting as such anything to do with storage or Analysis is 100% out of scope and instead purely about capturing the data.

An example would be you would have an instrument Rabbitmq.SentMessage with a tag to indicate success, fail etc. The analysis tool would aggregate/compute statistics.

[michaelklishin]

#1261 has been in the works for well over a year, with some OpenTelemetry messaging bits being revisited after some of its authors got involved.

When that work and #1261 wrap up, there will be some renewed interest in other aspects of "OpenTelemetry support" (a broad term).

[lukebakken]

@thompson-tomo - if you have the time to review and test this PR, it would be a major contribution to this library:

#1528

Thanks!