Allow tracking of current CircuitControllers and output hystrix style…

[dgodd]

This commit is considered less than an MVP and is hoped to be useful to start a conversation

I noticed that #90 mentions metrics. I a part of a team (steeltoe.io) looking to increase the interaction between java spring and .net applications. As part of that, we would like to help with efforts to add metrics to Polly, and specifically output them in a feed consumable by Hystrix.

We have investigated how we believe to be a sensible starting point to add metrics to Polly (and specifically circuit breaker), and would like feedback on whether this is a good approach and interest from the team to have us continue with this work.

I include a sample image of the hystrix dashboard with success / failure counts and circuit open / closed streaming in.

We would love to chat in any way you prefer (eg. hangout etc....)

[reisenberger]

@dgodd Thank you for this very interesting suggestion. I intend to put some thoughts together on this (basis for further discussion) in the coming days.

[reisenberger]

@dgodd Thanks for your interest in Polly! We would love to collaborate on adding metrics to Polly, and see what we can push to Hystrix dashboard. Videochat with myself (/and a.n.other AppvNext member/s?) next week mby?

Right now the Polly team are engaged in pushing out v5.0, which will contain additional policies Bulkhead; Cache; Timeout; Fallback and PolicyWrap to tie everything together. Is SteelToe interested in using / in metrics only for AdvancedCircuitBreaker, or potentially wider Polly policies?

Dipping into your PR, it looks closer to a Hystrix 1.4.x approach? The metrics implementation we envisage for Polly v5.0+ is slightly closer to the Hystrix 1.5.x approach : we expect Polly policies to emit events (much like the Hystrix Event Types) as an Rx stream. Aggregators would then be able to aggregate those events (and derive metrics from them) for any dashboard. Thoughts?

Timing-wise, we may be a few weeks getting v5.0 out first. But carve out some time on metrics proof-of-concept during that?

Couple of conceptual differences between Hystrix and Polly possibly to work through. Polly has retries; Hystrix doesn't. Do you envisage being able to adapt the Hystrix dashboard at all?

The Polly PolicyWrap is also more flexible (not imposing a structure) than Hystrix's fixed arrangement of strategies. But I'm envisaging adding a 'default' PolicyWrap option to Polly (watch for post in coming days), that will be pretty close to Hystrix approach - probably allowing us to bridge this difference.

Happy to explore further in videochat ...

[reisenberger]

@ wider community: And other dashboards too! (aware that others have expressed interest in metrics). Requests welcome! Offers of contributions (or thoughts to develop this) even better! 😉

[brunolauze]

Wow! Metrics are on my watch too! I started to look at what would be required to have an Hystrix-like metrics reporting relying on Polly. You can check https://github.com/brunolauze/Polly.Metrics https://github.com/brunolauze/Polly.Config and https://github.com/brunolauze/Polly.Web.EventStream
Since hystrix dashboard is a html/javascript only thing, we can plug it directly in an middleware along with an Rx Stream endpoint. It's just brainstorming code so don't be harsh on quality...

My findings are that the current implementation for calculating minimum throughtput use an internal Rolling Count for total and failures, the goal would be to offer something more global, optionally, to count everything. (e.g.: OnFallbackCompleted;OnFallbackFailed;OnFallbackRejected;OnShortCircuited;etc..)

[reisenberger]

@dgodd Would any of the steeltoe team like to do a videochat this week about this? If so, please contact me off-github on software[at]reisenberger.net, to arrange. I am in the UK; other relevant App-vNext members are also East Coast US.