Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems with turbine (Pull Model not suitable for containers): Our own model for metrics tapping (Push model) #1404

Open
mukteshkrmishra opened this issue Oct 26, 2016 · 4 comments

Comments

@mukteshkrmishra
Copy link

mukteshkrmishra commented Oct 26, 2016

Hi @mattrjacobs @spencergibb ,

I am opening this issue to submit a PR for moving away with turbine's pull model for aggregating metrices since it is not suitable in terms of distributed containers, where each microservice is running in different self sufficient containers and ips/ports are assigned dynamically (since in turbine we need to define host port in advance to aggregate streams).

Idea and solution I am using (Pull Model):
Create a custom jar which tap the hystrix metrics data as soon as call is made via hystrix then pushes that data into a facade (publisher). For accessing this data we have different subscribers viz: Rabbit MQ, Kafka, Spring XD, SQS or default medium (based on subscribers choice, how they wanna persist and use it. In our use case after publishing it to Kafka we persist in DB in order to create dashboards using Kibana).

Please let me know your thoughts on this. If we are good then I can go ahead and submit a PR on this.

@mukteshkrmishra mukteshkrmishra changed the title Problems with turbine: Our own model for metrics tapping Problems with turbine (Pull Model not suitable for containers): Our own model for metrics tapping (Push model) Oct 26, 2016
@mukteshkrmishra
Copy link
Author

@mattrjacobs : can you please review this once.

@mattrjacobs
Copy link
Contributor

@mukteshkrmishra Apologies for the delay. If I'm understanding correctly, you're trying to create a new method of getting metrics off of the instance producing Hystrix metrics that's not SSE. I agree that this seems like something interesting to pursue.

One piece of prior work we experimented with (but didn't quite finalize) was around pushing metrics over ReactiveSocket. You can see that code here:
#1236. ReactiveSocket is not strictly request-reply, so we've got more options than SSE. We ended up getting rid of it temporarily since it is Java8-only and complicated the build process. I have an open issue (#1325) to get this building again.

Let me know if that work is at all interesting. If so, I can prioritize the work to get it back into master and save some effort on your part.

@mukteshkrmishra
Copy link
Author

@mattrjacobs : Apologies for the delay. I will look into this over weekend and get back to you.

@gmcdowell-r7
Copy link

gmcdowell-r7 commented Jun 5, 2018

@mukteshkrmishra @mattrjacobs

Hi guys, was this ever implemented?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants