Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Provide aggregated retry.calls
See original GitHub issueResilience4j version: 1.2.0
Java version: 11.0.3
Problem description:
As some systems expects aggregated data the retry.calls metric should return for them aggregated value. Here you can read more about this problem:
https://micrometer.io/docs/concepts#rate-aggregation
Currently this metric is Gauge. In my case the monitoring system is a newrelic. I can not make readable dashboard without such a metric.
How do you about providing additional metric retry.calls.aggregated? Which returns how many calls have been processed from last execution. I am going to provide example implementation.
Issue Analytics
- State:
- Created 4 years ago
- Comments:31 (31 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I’ve opened another PR. @RobWin could you review it please? 😃
Yes, you are right. I also don’t like the idea that the Retry decorator emits an event on every successful call only to be able to measure the call rate. It puts too much unnecessary pressure on memory and garbage collection. I thought you are only interested in the rate of calls which have been retried. If you need a decorator which measures the rate and maybe also response times of all calls, you should better implement a new Timer decorator especially for this purpose.