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

[prometheusremotewrite] - Prioritize "external_labels" on prometheusremotewrite exporer #5842

Closed
gillg opened this issue Oct 20, 2021 · 1 comment
Labels
comp:prometheus Prometheus related issues

Comments

@gillg
Copy link
Contributor

gillg commented Oct 20, 2021

Is your feature request related to a problem? Please describe.
Actualy the final label set pushed to prometheus is constructed with :

  1. external_labels config
  2. OTEL resources (marked as "usefull")
  3. OTEL attributes

See :

Describe the solution you'd like
We should use this preceence instead to allow any override in external_labels I think...

  1. OTEL resources (marked as "usefull")
  2. OTEL attributes
  3. external_labels config

Additional context
As an exemple I would override in my context the instance resource to put a hostname on it.
I will do it by a resource processor, but this order seems more smart anyway.

@alolita alolita added the comp:prometheus Prometheus related issues label Nov 10, 2021
@gouthamve
Copy link
Member

Hi @gillg making this change would make it incompatible with how Prometheus does it unfortunately. Prometheus prioritises metric labels over external_labels:

https://github.com/prometheus/prometheus/blob/57f4aab27d53872b109c8513846765df6b51eb57/storage/remote/queue_manager.go#L665

and

https://github.com/prometheus/prometheus/blob/57f4aab27d53872b109c8513846765df6b51eb57/storage/remote/queue_manager.go#L741-L742

I think using the resource processor is the right way to go for your usecase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp:prometheus Prometheus related issues
Projects
None yet
Development

No branches or pull requests

4 participants