GMP Exporter: Support credentials file

[algchoo]

Component(s)

exporter/googlemanagedprometheus

Is your feature request related to a problem? Please describe.

Users that are not running on Google cloud cannot use this exporter.

Describe the solution you'd like

The solution we'd like to see is to allow the use of a credentials file, or JSON key. A user would create a service account with appropriate permissions and then create/download a key to be used for authentication.

Describe alternatives you've considered

We've extended the exporter to make use of these options. It can be found here.

Additional context

No response

[github-actions]

Pinging code owners:

• exporter/googlemanagedprometheus: @aabmass @dashpole @jsuereth @punya @tbarker25 @damemi

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[damemi]

This should work the same way as authenticating the GCP exporter, using the GOOGLE_APPLICATION_CREDENTIALS environment variable or placing the key file in a known location. Have you tried that?

[BinaryFissionGames]

Hey @damemi - this does work, as expected, but there's a few usability issues. Having to set an environment variable requires modifying the environment. This is especially a problem for something like managed agents, where we'd like to send a new key or key path down in the config through OpAmp or have it filled in by a config provider, but can't.

There is also an issue where you may want to use two separate keys, for sending with two separate exporters (perhaps to different projects). In this situation, I don't think the user is able to provide the two keys to the separate exporters.

As @algchoo mentioned, we've extended the exporter to accept files or the raw credentials JSON (https://github.com/observIQ/observiq-otel-collector/blob/1a849bd31661cb7dc34fd9caf6640ba3b2d22dd9/exporter/googlemanagedprometheusexporter/config.go#L35) for our distro. We'd love to see the same thing done upstream.

[damemi]

@BinaryFissionGames thanks for the added context, I thought this was just reporting a bug in the current auth approach

Long term, I think breaking this kind of thing into a custom authenticator would be the right approach. But, that could get tricky to avoid conflicting with the google client libraries' built-in auth handling. So this isn't a top priority for us right now

But we are open to PRs to add this similar to how you already have it working. We would just want to mark the config option experimental so that if we do switch to the authenticator method it's not breaking.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• exporter/googlemanagedprometheus: @aabmass @dashpole @jsuereth @punya @damemi @psx95

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• exporter/googlemanagedprometheus: @aabmass @dashpole @jsuereth @punya @damemi @psx95

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.