Add AWS Sigv4 support to scraper and http_sd about prometheus HOT 8 OPEN

@haoranleo do you plan to work in this yourself? I think this would be a very welcome feature, but @roidelapluie has more context for sure.

from prometheus.

Hi @beorn7, yeah we can add the SigV4 support ourselves. Just wanted to seek opinions from upstream first and ensure there is no major concern of adding that support :D.

We are currently finalizing the discussion on exposing a native SigV4 enabled metrics endpoint, after it is finalized we can start working on the change.

from prometheus.

We chose not to implement this because users who only require http_sd shouldn't have to build the entire AWS dependencies. I'm curious if there are enough use cases to justify this approach, or if there's a way to enable AWS SigV4 at compile time specifically for http_sd and Alertmanager.

from prometheus.

With SigV4 supported by remote write, maybe we have already linked in most of the required dependencies?

from prometheus.

I personally have projects that are using only the discovery.

But I am fine either way, if there is an easy way to only have sigv4 with opt-in, let's do this. otherwise, let's bake it in...

from prometheus.

Inclusion/exclusion via build tags would be nice, I guess. (It could also be opt-out, so that users that care about binary size can exclude it, similar to what we do with SD mechanisms.)

from prometheus.

We chose not to implement this because users who only require http_sd shouldn't have to build the entire AWS dependencies.

If SigV4 support is added in the http_sd, user can still choose to opt out right? They can use other authentication methods same as today like basic_auth/oauth2/tls_config etc... Please correct me if I miss something

from prometheus.

I think @roidelapluie is talking about having all the library dependencies linked into the binary, even for those users that don't need SigV4 support.

from prometheus.