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

Support different service discovery systems #213

Open
yurishkuro opened this Issue Jun 16, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@yurishkuro
Member

yurishkuro commented Jun 16, 2017

Depends on go-kit push model for discovery: go-kit/kit#492

  • upgrade to 0.5 version of go-kit (not released yet)
  • decommission internal discovery API and replace it with go-kit
  • add command line options for configuring different service discovery systems
  • integration tests
@yurishkuro

This comment has been minimized.

Member

yurishkuro commented Dec 28, 2017

A few thoughts since this issue has been opened.

The direct integration with service discovery is quickly becoming an anti-pattern given the rise of service meshes and proxies that abstract away that infrastructural concern. Even at Uber internally our agents are communicating to collectors via a service mesh proxy

If direct integration is still desired for performance reasons, I think integration of numerous SD systems directly into the Jaeger binary is the wrong approach, as it bloats the binary size on one hand, and on the other it pushes us more into dependencies hell. I think the solution here is a plugins architecture (#422) that decouples the main binary from the dependencies of individual SD implementations. An interesting observation here is that unlike storage plugins, the SD plugins have very low QPS and therefore are much more suitable for the sidecar plugin model where the main binary communicates to the plugin over, say, gRPC streams. Of course, the sidecar plugin model is actually a special case of in-process plugin model, so we still need to start there.

@pavolloffay

This comment has been minimized.

Member

pavolloffay commented Nov 26, 2018

@yurishkuro do we want to still provide this functionality?

@yurishkuro

This comment has been minimized.

Member

yurishkuro commented Nov 26, 2018

I am not sure, there hasn't been much demand. My last comment was almost a year ago, since then I thought of yet another solution that requites no plugins. We can have an API endpoint where SD information can be pushed into by an external process, similar to data/control plane separation advocated by Envoy. This way the SD can be implemented as a sidecar to the Jaeger components.

But a harshicorp go-plugin would also work.

I don't see any of this work happening any time soon unless there are volunteers who actually need it in their environment.

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