Expose drop_unroutable rate for an exchange via API

[avtc]

Hello,

Currently exchange name of drop_unroutable can be read only from Prometheus metrics, but not from an API, is it possible to add such data to API?

i.e. to message_stats of response from
/api/exchanges/awesome_vhost/awesome_exchange?

Same for return_unroutable.

[lukebakken]

The *unroutable* stats are per-channel stats. Here you can see them in the Prometheus non-aggregated output:

# TYPE rabbitmq_channel_messages_published_total counter
# HELP rabbitmq_channel_messages_published_total Total number of messages published into an exchange on a channel
rabbitmq_channel_messages_published_total{channel="<0.5371.0>",vhost="/",exchange="test"} 26
# TYPE rabbitmq_channel_messages_confirmed_total counter
# HELP rabbitmq_channel_messages_confirmed_total Total number of messages published into an exchange and confirmed on the channel
rabbitmq_channel_messages_confirmed_total{channel="<0.5371.0>",vhost="/",exchange="test"} 26
# TYPE rabbitmq_channel_messages_unroutable_returned_total counter
# HELP rabbitmq_channel_messages_unroutable_returned_total Total number of messages published as mandatory into an exchange and returned to the publisher as unroutable
rabbitmq_channel_messages_unroutable_returned_total{channel="<0.5371.0>",vhost="/",exchange="test"} 26
# TYPE rabbitmq_channel_messages_unroutable_dropped_total counter
# HELP rabbitmq_channel_messages_unroutable_dropped_total Total number of messages published as non-mandatory into an exchange and dropped as unroutable
rabbitmq_channel_messages_unroutable_dropped_total{channel="<0.5371.0>",vhost="/",exchange="test"} 0

As we are trying to discourage use of the HTTP API for stats, I doubt we will add the exchange name to the HTTP API /api/channels/... endpoints. @michaelklishin ?

[michaelklishin]

I see little value in exposing this stat per-exchange. The goal has always been to demonstrate that some publishers publish unroutable messages, not that some exchanges cannot route. It can be somewhat useful for troubleshooting but a traffic capture would reveal
more, as can application-level metrics.

So I doubt it is worth spending time on, we are a small team with bigger fish to fry.