Global scrape protocols not propagated to target allocator generated scrape configs

[sfc-gh-rscott]

Component(s)

target allocator

Description

Similar to #3035. When specifying scrape protocols in the global prometheus config for a collector, those protocols are not propagated to the generated scrape configs.

Steps to Reproduce

Use a prometheus config with scrape protocols globally defined:

prometheus:
    config:
      global:
        scrape_interval: 30s
        scrape_protocols: ['PrometheusProto','OpenMetricsText1.0.0','OpenMetricsText0.0.1','PrometheusText0.0.4']
    target_allocator:
      endpoint: [http://opentelemetry-k8s-agent-targetallocator:80](http://opentelemetry-k8s-agent-targetallocator/)
      interval: 30s
      collector_id: ${POD_NAME}
      http_sd_config:
        refresh_interval: 60s

Expected Result

Generated scrape configs have the PrometheusProto protocol included:

    "scrape_protocols": [
      "PrometheusProto",
      "OpenMetricsText1.0.0",
      "OpenMetricsText0.0.1",
      "PrometheusText0.0.4"
    ],

Actual Result

PrometheusProto is omitted:

    "scrape_protocols": [
      "OpenMetricsText1.0.0",
      "OpenMetricsText0.0.1",
      "PrometheusText0.0.4"
    ],

Kubernetes Version

1.28.3

Operator version

v0.103.0

Collector version

v0.103.0

Environment information

Environment

OS: (e.g., "Ubuntu 20.04")
Compiler(if manually compiled): (e.g., "go 14.2")

Log output

No response

Additional context

No response

[jaronoff97]

Discussion:

• The approach for adding global into the TA CRD is acceptable
• We DO NOT want to accept any other custom Prometheus fields, and we don't think we will need to in the future (i.e. we are choosing to not accept scrape configs files)
  • We only want to maintain parity with the prometheus receiver
  • In the future, we will recommend using the prometheus CRs to do this
  • We do need to get Enabling scrapeConfig and Probe #3103, but that's a separate problem.