New component: Target Allocator

[atoulme]

The purpose and use-cases of the new component

This component is a reprisal of the existing target allocator command under opentelemetry-operator.
The goal of this component is to analyze various Prometheus metric sources and split job allocations between existing collectors.
In the operator, this command is used to find all Prometheus endpoints exposed with Prometheus Operator CRDs and split their jobs according to a strategy that fits best the cluster topology and the type of load to expect.

While this component is currently active under the operator, I would like it to be considered as a collector extension.

I believe this will fit better in scenarios where the operator is not used, but a Kubernetes environment is in play.
I also believe this can be leveraged to check for other sources of Prometheus metrics.

Example configuration for the component

extensions:
  target-allocator:
    collector_selector:
      matchlabels:
        app.kubernetes.io/instance: default.test
        app.kubernetes.io/managed-by: opentelemetry-operator
    prometheus_cr:
      pod_monitor_selector:
        matchlabels:
          release: test
      service_monitor_selector:
        matchlabels:
          release: test
    config:
      scrape_configs:
        - job_name: prometheus
          static_configs:
            - targets: ["prom.domain:9001", "prom.domain:9002", "prom.domain:9003"]
              labels:
                my: label

This example shows an extension target-allocator with a kubernetes selector of OpenTelemetry Collector instances filtered on specific labels.
For any Prometheus custom resources, the target-allocator will find all usage of the PodMonitor and ServiceMonitor CRDs under the release: test label. It also has static configs going to 3 different Prometheus endpoints.

Telemetry data types supported

metrics

Code Owner(s)

atoulme

Sponsor (optional)

@atoulme

Additional context

No response

[atoulme]

The Operator SIG discussed this item during the SIG meeting of 2/13 (notes)

2 objections reported on this proposal:

Collector could theoretically do it, but performance would be bad in large clusters
There’d also be additional load on the API Server for each collector doing this

I believe these objections are alleviated if you use a single pod deployment of the collector, or when using the k8s leader election extension which is being worked in parallel in the collector. This means a specific collector would be performing the work of the target-allocator data collection, so the load would be similar to the existing command.

[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.