Proposal: Add SD implementation backed by a gRPC interface for custom providers

[Yaroslav Skopets]

Proposal

• In the context of a Service Mesh, there is always a notion of a Control Plane that coordinates telemetry among other things
• It would be perfect for overall user experience if a Control Plane could also become a source of scrape targets (specifically, for collecting metrics out of side-car proxies)
• As a way to achieve that, we would like to propose to introduce a gRPC interface for SD that Control Planes could implement
• The choice of gRPC will enable effective server-side streaming of SD information, and it will remove the requirement on users to think upfront about refresh intervals they cannot choose reliably anyway
• There is already a well-defined, battle-tested and widely used protocol for delivering discovery information - Envoy xDS API
• Based on all the above, we would like to ask if Prometheus community is open for such a contribution

[Brian Brazil]

If you're on Kubernetes then kubernetes_sd should already cover you, beyond that I'd suggest starting out using file_sd as this sounds a bit niche.

--

Brian Brazil

www.robustperception.io

[Julien Pivotto]

On 18 Dec 14:34, Yaroslav Skopets wrote:
> Proposal
>
> - In the context of a Service Mesh, there is always a notion of a

> Control Plane that coordinates telemetry among other things

> - It would be perfect for overall user experience if a Control Plane

> could also become a source of scrape targets (specifically, for collecting
> metrics out of side-car proxies)

> - As a way to achieve that, we would like to propose to introduce a gRPC

> interface for SD that Control Planes could implement

> - The choice of gRPC will enable effective server-side streaming of SD

> information, and it will remove the requirement on users to think upfront
> about refresh intervals they cannot choose reliably anyway

> - There is already a well-defined, battle-tested and widely used

> protocol for delivering discovery information - Envoy xDS API

> <https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol>
> - Based on all the above, we would like to ask if Prometheus community

> is open for such a contribution

Hello,

I guess a lot of service mesh users have access to the kubernetes
service discovery.

Shouldn't that be possible, then we must remember that envoy is not used
in every service mesh, so that would not be generic. That is not an
issue per se, but it is important when we would name that service
discovery.

>
> --
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/b55f6280-3f5b-49ee-97b2-e4bfa104fd4f%40googlegroups.com.


--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu

[Yaroslav Skopets]

Thank you!

Do you why the discussion around `http_sd` stop ?

On Fri, Dec 20, 2019 at 11:19 PM Daniel Swarbrick <daniel.s...@cloud.ionos.com> wrote:

You might want to read this earlier thread first: https://groups.google.com/d/topic/prometheus-developers/3B3jBsErK5M/discussion

I would certainly be in favour of some generic gRPC-based SD method, such that people could implement their own gRPC services, exposing scrape targets from whatever funky / proprietary information sources they use. As I wrote in the aforementioned thread, I ended up implementing a bare minimum fake Consul service, providing only the API endpoints used by Prometheus, as an SD mechanism for hosts stored in an enterprise database (Postgres, in my case). It has worked flawlessly for over 18 months.

I would of course much rather not have to fake other products' APIs though.

--

You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/cb86c927-8642-45b0-bf33-00d14e09aec7%40googlegroups.com.

--

Best regards,

Yaroslav Skopets

[Brian Brazil]

On Fri, 20 Dec 2019 at 22:57, Yaroslav Skopets <y.sk...@gmail.com> wrote:

Thank you!

Do you why the discussion around `http_sd` stop ?

That particular one looks like it started going into the weeds of inventing a brand new SD, and petered out. There's enough of them out there without us creating more.

More generally, why should we have two generic SDs? That kinda defeats the purpose of having a generic integration, which is to have one thing that all the other use cases can be handled via.

If you want to add a hop that goes over http it's not exactly difficult to run curl in a cronjob or have a sidecar.

Brian

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAJsMHLKWheCeGT_MiEGjrxbPpR8_t-nFmCgu4Vps5OE66-mekQ%40mail.gmail.com.

--

Brian Brazil

www.robustperception.io

[Austin Cawley-Edwards]

Hey all,

Trying to bring this thread back to life and give some updates since it petered out.

At Kuma[0], we've gone down the suggested `file_sd` route by building a custom binary that runs in a Prometheus sidecar to do the polling and writing of the sd file, which is then shared w/ Prometheus via volume mounts[1]. This works very well once it is set up correctly, but has proven difficult for many users to get up and running as it involves a good deal of low-level, non-prometheus config. It's even more difficult if they are not on the team managing Prometheus infra.

For those reasons, implementing another generic SD would help purely with adoption, as configuring a few lines of yaml is a dramatically lower starting place compared to configuring a sidecar with shared volume mounts. I understand and agree with the general hesitation here, especially when it comes to defining entirely new "generic" SDs, and even the hesitation to adopt a widely-used protocol like envoy's xDS, but with the primary goal of increasing adoption, what do you all think about exposing a grpc_sd that uses the same format as the file_sd? I'm sure much of the implementation could be shared and it would remove the burden of setting up the network hop and file sharing themselves.

Lastly, in terms of continued support, we at Kuma are committed to our Prometheus integration and are happy to contribute and maintain this SD with the Promtheus community.

Other related issues:

- #6484 [2], gRPC proposal

- #7919 [3], Kuma SD proposal

Thanks for hearing this out,

Austin

[0]: https://kuma.io/

[1]: https://kuma.io/docs/0.5.0/policies/traffic-metrics/#configure-dataplane-discovery-by-prometheus-2

[2]: https://github.com/prometheus/prometheus/issues/6484

[3]: https://github.com/prometheus/prometheus/issues/7919

[Julien Pivotto]

As you might have seen, we are slowly getting new SD's into prometheus
core. We had 4 new SD's in the last weeks.

When the issue for Kuma arrived in te bug tracker, there were some
leftover questions, like did you try the DNS-SD? Then the issue was
directly closed.

If you have the Prometheus Operator, you have a my understanding is that
you can make your "generic sd" by creating Probe CRD's (e.g. from within
the kuma controllers). Did you consider that option too? If you are not
in kube then you don't have shared mountpoints issues.

Should we have a generic SD, I would not like that much GRPC as would
bring many dependencies, that we already had issues with. Additionally,
we have more chances to use a more-established standard like HTTP (with
long poll). Especially since the communications only need to be one-way.

I also think that such SD's should be limited to what they do, and that
it should be less flexible than the current file_sd. I think that any
generic remote file_sd should have constraints, such as all the labels
should be prefixes with __meta unless the __address__ label. We should
try to enforce on those SD's the same rules we have kept for the SD's
that are implemented now.

> >>>> - In the context of a Service Mesh, there is always a notion of a

> >>>> Control Plane that coordinates telemetry among other things

> >>>> - It would be perfect for overall user experience if a Control

> >>>> Plane could also become a source of scrape targets (specifically, for
> >>>> collecting metrics out of side-car proxies)

> >>>> - As a way to achieve that, we would like to propose to introduce a

> >>>> gRPC interface for SD that Control Planes could implement

> >>>> - The choice of gRPC will enable effective server-side streaming of

> >>>> SD information, and it will remove the requirement on users to think
> >>>> upfront about refresh intervals they cannot choose reliably anyway

> >>>> - There is already a well-defined, battle-tested and widely used

> >>>> protocol for delivering discovery information - Envoy xDS API

> >>>> <https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol>
> >>>> - Based on all the above, we would like to ask if Prometheus

> >>>> community is open for such a contribution
> >>>>
> >>>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Prometheus Developers" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> >>> an email to prometheus-devel...@googlegroups.com.
> >>> To view this discussion on the web visit
> >>> https://groups.google.com/d/msgid/prometheus-developers/cb86c927-8642-45b0-bf33-00d14e09aec7%40googlegroups.com

> >>> <https://groups.google.com/d/msgid/prometheus-developers/cb86c927-8642-45b0-bf33-00d14e09aec7%40googlegroups.com?utm_medium=email&utm_source=footer>
> >>> .

> >>>
> >>
> >>
> >> --
> >> Best regards,
> >> Yaroslav Skopets
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Prometheus Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to prometheus-devel...@googlegroups.com.
> >>
> > To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/prometheus-developers/CAJsMHLKWheCeGT_MiEGjrxbPpR8_t-nFmCgu4Vps5OE66-mekQ%40mail.gmail.com

> >> <https://groups.google.com/d/msgid/prometheus-developers/CAJsMHLKWheCeGT_MiEGjrxbPpR8_t-nFmCgu4Vps5OE66-mekQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> >> .
> >>
> >
> >
> > --
> > Brian Brazil
> > www.robustperception.io

> >
>
> --
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/8894963b-f578-4898-a3ff-d0b963a3e3a4n%40googlegroups.com.


--
Julien Pivotto
@roidelapluie

[Frederic Branczyk]

> If you have the Prometheus Operator, you have a my understanding is that
> you can make your "generic sd" by creating Probe CRD's (e.g. from within
> the kuma controllers). Did you consider that option too? If you are not
> in kube then you don't have shared mountpoints issues.

Just for clarification, Prometheus Operator Probes are only meant for automating the setup and specialties around making blackbox probes more accessible. They are not a general-purpose way to scrape targets.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20201009230855.GA1267035%40oxygen.

[Austin Cawley-Edwards]

Hey Julien + Frederic,

Thanks for the quick replies.

I'm gathering details on the DNS SD option, but we have tried that option without success. I'll post back when I have a full answer and am happy to update the issue for completeness.

I agree with Frederic on the Prometheus Operator point and think that even if there was a way to use the Prometheus Operator to solve this, we'd still be reliant on users to have a specific Prometheus installation.

I think what you've said about the gRPC drawbacks are very reasonable, and the HTTP approach sounds like a good, simple alternative. The restrictions on such a sd also make total sense -- is there a full list of those restrictions somewhere/ could you expand on them if not? My only worry is that we'd end up trying to invent a new HTTP sd, which seems to be what killed these threads in the past.

Thank you!

Austin

[Austin Cawley-Edwards]

Hey all,

I've gathered up some research about our efforts with the DNS SD option, please let me know if I've overlooked something.

Since the DNS SD[1] only supports basic A, AAAA, and SRV records and a small set of meta labels, the amount of information that can be transparently stored and parsed is limited. Of the three available meta labels, the only field that would make sense to use for holding information is `__meta_dns_name`. This is limiting when many pieces of info are necessary, as they'd have to be encoded and parsed with some decently complex relabling steps.

In terms of a service mesh like Kuma, there are quite a lot of labels that are valuable to an end user, for example: the mesh name, the dataplane name, the service name, user-defined tags about the service,  etc. These would get quite complex to encode and parse in a single (or even if spread across the three) label supported by the DNS SD mechanism.

This limitation is likely to affect anyone trying to integrate with an extisiting Prometheus installation without, outside of a natively supported environment. Providing a more generic external SD might also be useful as an alternative to adding new environment-specific SDs where these limitations are hit.

Anyways, I'll update the original ticket -- please let me know what you think @julien and if you'd be willing to further discuss what extra constraints would be necessary.

Thanks so much,

Austin

[1]: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#dns_sd_config

[Julien Pivotto]

On 21 Oct 15:12, Austin Cawley-Edwards wrote:
> Hey all,
>

> I've gathered up some research about our efforts with the DNS SD option,
> please let me know if I've overlooked something.

I have been looking on my side too - I think that what the option that's
more likely on the table would not to have a "generic" implementation,
but a xDS protocol service discovery. In that case, it would not be an
issue to have that in Prometheus (even the gRPC version).

However, the extra layer that kuma is offering in the SD should be done
at the Prometheus configuration level - e.g. by the user, in the
relabel_configs.

I think I'd like to better understand xDS but it seems that it could be
good option for a service discovery in Prometheus, at least at first
sight.

We are looking at a huge amount of work here I think.

--
Julien Pivotto
@roidelapluie

[Austin Cawley-Edwards]

That makes sense to me, and would be nice to build of an existing protocol, and agree it sounds like a large effort. I’m pretty new to xDS as well, though we have many people on the Kuma team who are quite knowledgeable — I’d be happy to set up a call/ bring them in to help size the work if you’d be open to that. 

And understand + agree on the configuration approach for the extra layer. The main difficulty for users is configuring the file_sd + sidecar, relabel_configs should be fairly straightforward and accessible. 

Austin

[Austin Cawley-Edwards]

Hey Julien,

Following up on if you've had time to think about how we can move forward on one of these paths. I haven't been able to find any formal proposals for the other recently merged SDs like Eureka besides this comment[1]. Would it be valuable for us to work on something similar for envoy's xDS in the meantime?

Thanks,

Austin

[1]: https://github.com/prometheus/prometheus/pull/3369#issuecomment-667344846

[Julien Pivotto]

On 28 Oct 08:28, Austin Cawley-Edwards wrote:
> Hey Julien,
>
> Following up on if you've had time to think about how we can move forward
> on one of these paths. I haven't been able to find any formal proposals for
> the other recently merged SDs like Eureka besides this comment[1]. Would it
> be valuable for us to work on something similar for envoy's xDS in the
> meantime?

Let's be honest that recent service discoveries are 'small', and that
big ones are quite old now.

I still need to gather intel on xDS; but let's start by collecting data:

- What would the configuration look like (does it need multiple
`roles`)
- Which meta labels could we have exposed
- How would we set the address

That hopefully should not be too much work and then we can see how/if we
move forward with this.

> --
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/89922987-42e4-4807-9956-5590cb2de558n%40googlegroups.com.


--
Julien Pivotto
@roidelapluie

[Austin Cawley-Edwards]

Perfect, I'll get started collecting that data. Thanks for the direction.

Best,

Austin

[Julien Pivotto]

Hello Austin,

Is there any progress here? I am really willing to learn more about xds
and how it would fit here.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CALGL%2BUBExJmaD9rzXWnTJf5h6my3cbYrrh-uQjCD9U9PGoW-Aw%40mail.gmail.com.

--
Julien Pivotto
@roidelapluie

[Austin Cawley-Edwards]

Hey Julien,

Thanks for reaching back out about this. I’ve been on the midst of a job transition and have not made any progress, but that is finally fully done and I can try to move this along (though it will still be slowly). I’ll get back to research and bring it up at the next Kuma community meeting in two weeks, and then report back.

Best,

Austin

[Austin Cawley-Edwards]

Hey Julien,

I've finished up a rough proof of concept for what xDS support in Prometheus could look like [1]. I think it shows the main areas without going too over-the-top. In summary, the two main pieces to the integration seem to be an xDS API definition[2] and an xDS client/ discovery that uses an implementation of this API [3] (HTTP discovery implementation here[4]). For the xDS API, envoy does not have a native concept of metrics/ monitoring, so we need to define this data structure -- I've currently sketched one out (taking from Kuma) that is very close to a targetgroup[5].

A few pros:

- support for both HTTP and gRPC API implementations

- xDS protocol is well documented

- versioned API will make modifications possible

A few cons:

- complexity of the protocol for people who have not used it

- added dependencies on gRPC and envoy + build processes additions for compiling protobuf

- xDS adds some overhead for implementors of this API, though this seems like an "advanced" use case where that is ok

Please let me know what you think and if you think it's feasible to move forward with xDS or if we should go back to discussions of a simpler HTTP/ gRPC approach.

Best,

Austin

[1]: https://github.com/austince/prometheus/tree/discovery-xds/discovery/xds

[2]: https://github.com/austince/prometheus/tree/discovery-xds/discovery/xds#xds-api-implementation

[3]: https://github.com/austince/prometheus/tree/discovery-xds/discovery/xds#discovery-scraping

[4]: https://github.com/austince/prometheus/blob/discovery-xds/discovery/xds/http_discovery.go

[5]: https://github.com/austince/prometheus/blob/discovery-xds/discovery/xds/api/v1alpha1/mads.proto

[Julien Pivotto]

On 18 Feb 12:10, Austin Cawley-Edwards wrote:
> Hey Julien,
>

> I've finished up a *rough *proof of concept for what xDS support in

> Prometheus could look like [1]. I think it shows the main areas without
> going too over-the-top. In summary, the two main pieces to the integration
> seem to be an xDS API definition[2] and an xDS client/ discovery that uses
> an implementation of this API [3] (HTTP discovery implementation here[4]).
> For the xDS API, envoy does not have a native concept of metrics/
> monitoring, so we need to define this data structure -- I've currently
> sketched one out (taking from Kuma) that is very close to a targetgroup[5].
>
> A few pros:
> - support for both HTTP and gRPC API implementations
> - xDS protocol is well documented
> - versioned API will make modifications possible
>
> A few cons:
> - complexity of the protocol for people who have not used it
> - added dependencies on gRPC and envoy + build processes additions for
> compiling protobuf
> - xDS adds some overhead for implementors of this API, though this seems
> like an "advanced" use case where that is ok
>
> Please let me know what you think and if you think it's feasible to move
> forward with xDS or if we should go back to discussions of a simpler HTTP/
> gRPC approach.

Thanks, here are my initial thoughts:

- We should not *add* an API, but discover everything on the xDS API.
The meta labels created would then enable to filter what is needed and
what is not. It is not the responsibility of the service discovery.
Monitoring is not just about whitebox monitoring, the scope can be
much larger. Also, I want something that could be used out of the box
with current xds api's.
- We need to settle by using grpc or http, we would not support both.
Which one is the most used?

So overall I don't think there should be any overhead for the
implementors of the API, since my understating is that there are out of
the box implementations out there, like envoy? What am I missing?

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/7db91c8f-33e2-4253-8cc6-daf596a1d1ban%40googlegroups.com.


--
Julien Pivotto
@roidelapluie

[Austin Cawley-Edwards]

Hey Julien,

I think the disconnect here is that xDS is just a protocol used for many different Envoy services[1], and does not define any actual data that could be mapped to a target itself. It is purely meant as a base that is to be extended. Can you clarify what you mean by "current xds api's"? Do you mean just discovering the current Envoys in a cluster? Or do you mean trying to discover all the various Listeners/ VirtualHosts[2] (which may or may not expose a metrics endpoint) from Envoy? Envoy does not implement anything about metrics of the underlying services it proxies, i.e. there is no way to say "these services are good to scrape" to my knowledge.

For HTTP vs gRPC, I'm not sure why we wouldn't want to support both as the xDS protocol defines support for both, but gRPC is more common.

Best,

Austin

[1]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/service

[2]: https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol#resource-types

[Austin Cawley-Edwards]

Quick follow-up: I think an "envoy discovery" method to scrape Envoy-specific metrics might be worthwhile, but I don't think it fits in the same conversation as this one.

[Julien Pivotto]

Yeah my impression was that eDS would fit here, what envoy uses for
endpoints.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/47fdf607-fac5-41bd-94ea-683fe67e38bfn%40googlegroups.com.


--
Julien Pivotto
@roidelapluie

[Austin Cawley-Edwards]

Yeah, that would be nice too but would not solve the original use case of this thread, which was to provide a generic option that did not need to co-locate data next to Prometheus via a filesystem. I think xDS is still a good fit for a generic option, but we would need to define an API.

If we were to just directly use the structure of file_sd, then we're not creating anything new, just joining the xDS discovery protocol with an existing data structure.

What are you thinking? Do you want to open a new thread to see if anyone would find an envoy_ds valuable?

Best,

Austin

[Julien Pivotto]

On 18 Feb 13:52, Austin Cawley-Edwards wrote:
> Yeah, that would be nice too but would not solve the original use case of
> this thread, which was to provide a generic option that did not need to
> co-locate data next to Prometheus via a filesystem. I think xDS is still a
> good fit for a generic option, but we would need to define an API.
>
> If we were to just directly use the structure of file_sd, then we're not
> creating anything new, just joining the xDS discovery protocol with an
> existing data structure.
>
>
> What are you thinking? Do you want to open a new thread to see if anyone
> would find an envoy_ds valuable?

Well I think we should have a xds package which would have envoy_sd, and
possibly kuma_sd, but stay scoped and tight to what exists _now_. Having
them in a xds package enables us to reuse code.

I am really not willing to have file_sd over xds.

Note: We use the same pattern in zookeeper, where one discovery package
contains 2 sd mechanisms.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/4deb5ef0-7acd-4746-8627-f10abc7bd846n%40googlegroups.com.


--
Julien Pivotto
@roidelapluie

[Austin Cawley-Edwards]

We could try out EDS, though it seems like a very envoy-specific feature without a good way to provide non-envoy labels. The only way that seems possible with EDS is via the LbEndpoint's metadata[1], though that very specifically not what it is designed for. 

[1]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/endpoint/v3/endpoint_components.proto#config-endpoint-v3-lbendpoint

[Julien Pivotto]

On 18 Feb 14:01, Austin Cawley-Edwards wrote:
> We could try out EDS, though it seems like a very envoy-specific feature
> without a good way to provide non-envoy labels. The only way that seems
> possible with EDS is via the LbEndpoint's metadata[1], though that very
> specifically not what it is designed for.

I don't get what you mean here.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/16e4997f-3d3c-493c-b183-f503789cbf66n%40googlegroups.com.


--
Julien Pivotto
@roidelapluie

[Austin Cawley-Edwards]

> Well I think we should have a xds package which would have envoy_sd, and
> possibly kuma_sd, but stay scoped and tight to what exists _now_. Having

> them in a xds package enables us to reuse code.

That could make sense to me, though in the long term seems like it would be more of a burden in the long run that fragments xDS implementations and brings more dependencies into Prometheus.

I don't think it would make sense to implement this for envoy without someone asking for it, but it could be done for Kuma where we have an xDS client in the xds package, and then pull in Kuma's xDS API for Monitoring assignments. I'd be happy to update my fork to reflect that if you'd like to see it?

Best,

Austin

[Julien Pivotto]

On 18 Feb 14:06, Austin Cawley-Edwards wrote:
> > Well I think we should have a xds package which would have envoy_sd, and
> > possibly kuma_sd, but stay scoped and tight to what exists _now_. Having
> > them in a xds package enables us to reuse code.
>
> That could make sense to me, though in the long term seems like it would be
> more of a burden in the long run that fragments xDS implementations and
> brings more dependencies into Prometheus.
>
> I don't think it would make sense to implement this for envoy without
> someone asking for it, but it could be done for Kuma where we have an xDS
> client in the xds package, and then pull in Kuma's xDS API for Monitoring
> assignments. I'd be happy to update my fork to reflect that if you'd like
> to see it?

I don't want to instruct you to do a lot of "free" work given I don't
really know where we are heading but I am willing to see what it would
look like with existing kuma xds api, over HTTP (grpc is currently quite
a pain to update and would cause short-term issues to integrate in
Prometheus, so if http is available let's use that).

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/25b690f4-a24c-42df-b0e5-909a4e55287cn%40googlegroups.com.


--
Julien Pivotto
@roidelapluie

[Julien Pivotto]

On 18 Feb 14:06, Austin Cawley-Edwards wrote:

> > Well I think we should have a xds package which would have envoy_sd, and
> > possibly kuma_sd, but stay scoped and tight to what exists _now_. Having
> > them in a xds package enables us to reuse code.
>
> That could make sense to me, though in the long term seems like it would be
> more of a burden in the long run that fragments xDS implementations and
> brings more dependencies into Prometheus.
>
> I don't think it would make sense to implement this for envoy without
> someone asking for it, but it could be done for Kuma where we have an xDS
> client in the xds package, and then pull in Kuma's xDS API for Monitoring
> assignments. I'd be happy to update my fork to reflect that if you'd like
> to see it?

It seems like we are back at:
https://github.com/kumahq/kuma/tree/master/app/kuma-prometheus-sd/pkg/discovery/xds

We have circled down.
:)


I will look at that.