Support Prometheus Operator ScrapeClass.

[nicolastakashi]

Component(s)

target allocator

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

In the Prometheus Operator, we have developed a cool feature called ScrapeClass, which allows us to define common configurations that are automatically injected into every scrape configuration.

This feature is particularly useful for standardizing configurations such as common relabeling rules, certificates, and other settings. It ensures consistency across monitored objects without requiring users to repeatedly define the same settings for each scrape target.

I’d love to hear your thoughts—do you think this could be a valuable addition to the PrometheusCR integration?

Describe the solution you'd like

Extend TA Config to allow define scrape class structure while using PrometheusCR integration.

Describe alternatives you've considered

No response

Additional context

No response

[jaronoff97]

@swiatekm this sounds like exactly what we want for the TA rather than embedding the whole thing in the TA config

[swiatekm]

Sounds good to me. One point worth mentioning is that unlike in prometheus-operator, in a target allocator + otel collector setup, service discovery and scraping happen in different applications. Right now we solve the issue around credentials by encrypting traffic between the target allocator and prometheus receiver, and simply exposing them via target allocator endpoints. Not sure if that makes any difference for scrape classes specifically.

[nicolastakashi]

@swiatekm thanks for mention, I don't see any issue from our side with that, I think it's fine.
I'm going to open a PR extending TA to work with this.