Error metrics should be generated by upstream channel connectors when message is nacked

[vietk]

Hello !

For an incoming connector channel that is bound to a consumer method, either be :

• an @incoming + @Outgoing method
• a simple @incoming method

When a message is nacked, it is generally due to an error downstream, reactive messaging could monitor the number of errors in this case, in addition to failure strategy already put in place. The metric reported would feed an alert system or a dashboard for health monitoring for example

Naively, I would implement this using a PublisherDecorator :

What do you think about this idea?
Regards

[ozangunalp]

Hi @vietk ,

I think the Message Observability fits your use case. In Quarkus it works together with the Micrometer extension: https://quarkus.io/guides/kafka#channel-metrics

Underneath it is indeed some decorators intercepting message ack/nack

[vietk]

Hello!
Thanks for your answer, we already implemented (without the Message Observability API) this, in our reactive messaging application and we based on Decorators.

My question was more to get you feeling on this topic : do you plan to support it in reactive messaging to avoid every one to code the decorators. ?
And if yes, are you open to contributions on this specific topic ?

Regards

[ozangunalp]

I'd like the message observability API to already satisfy this need, without coding decorators.

In Quarkus, metrics are gathered using Micrometer but one can imagine an alternative implementation of MessageObservationCollector. I think gathered metrics, together with derivations you can apply on the telemetry backend (Prometheus, Grafana etc.) should cover most use cases.

For contributions, you know they are always welcome :)
The hard part is to have a balance between extension points (like decorators, interceptors etc.) and what is provided by default by the framework. Health checks are a good example. We provide sensible default health checks and your contribution was awesome for the Kafka connector. There are so many different cases with health checks that we no longer need modifications to those but a good extension point to customize them per usage.

Hope this makes sense and doesn't discourage you for future contributions, again they are much appreciated!