[OTel Engine] Missing OTelCollector components for the OTel Demo

[cyrille-leclerc]

Component(s)

No response

Request

Using the Alloy OTel Engine (image: grafana/alloy-dev, tag: v1.13.2-devel-5bf4dcf) as the OTel Collector distro in the Kubernetes deployment of the OpenTelemetry Demo fails because the Alloy OTel Engine lacks:

• Receiver: receiver_creator
• Exporter: opensearch
• Extensions: k8s_observer

I think that:

• The receiver_creator and its dependency k8s_observer will soon be important as it's getting increasingly popular to
  • Have finer granularity to choose whch pod logs to scrape and prevent duplication between pod logs and otlp logs
  • Use K8s pod annotations and GitOps to configure observability
• The opensearch exporter is not a priority.

Error: failed to get config: cannot unmarshal the configuration: decoding failed due to the following error(s):

'receivers' unknown type: "receiver_creator" for id: "receiver_creator/metrics" (valid values: [fluentforward googlecloudpubsub hostmetrics influxdb awss3 cloudflare filelog jaeger k8sobjects kafka prometheus solace awscloudwatch prometheusremotewrite zipkin kubeletstats splunk_hec syslog tcplog vcenter otlp awsecscontainermetrics datadog faro filestats])
'exporters' unknown type: "opensearch" for id: "opensearch" (valid values: [googlecloud kafka syslog googlecloudpubsub loadbalancing zipkin nop otlphttp faro file prometheus prometheusremotewrite awss3 splunk_hec debug otlp])
'extensions' unknown type: "k8s_observer" for id: "k8s_observer" (valid values: [headers_setter jaegerremotesampling oauth2client sigv4auth file_storage alloyengine health_check pprof zpages basicauth bearertokenauth])
2026/02/26 08:43:57 collector server run finished with error: failed to get config: cannot unmarshal the configuration: decoding failed due to the following error(s):

'receivers' unknown type: "receiver_creator" for id: "receiver_creator/metrics" (valid values: [fluentforward googlecloudpubsub hostmetrics influxdb awss3 cloudflare filelog jaeger k8sobjects kafka prometheus solace awscloudwatch prometheusremotewrite zipkin kubeletstats splunk_hec syslog tcplog vcenter otlp awsecscontainermetrics datadog faro filestats])
'exporters' unknown type: "opensearch" for id: "opensearch" (valid values: [googlecloud kafka syslog googlecloudpubsub loadbalancing zipkin nop otlphttp faro file prometheus prometheusremotewrite awss3 splunk_hec debug otlp])
'extensions' unknown type: "k8s_observer" for id: "k8s_observer" (valid values: [headers_setter jaegerremotesampling oauth2client sigv4auth file_storage alloyengine health_check pprof zpages basicauth bearertokenauth])
stream closed: EOF for otel-demo/otel-collector-agent-gpj9s (opentelemetry-collector)

OTel Demo config:

https://github.com/cyrille-leclerc/opentelemetry-helm-charts/blob/6e48c2bc8eca098ea31958a2cc68d2aa106be538/charts/opentelemetry-demo/values.yaml#L906-L910

...
opentelemetry-collector:
  enabled: true
  image:
    repository: grafana/alloy-dev
    tag: v1.13.2-devel-5bf4dcf # TODO: update to v1.14 once it's released
  command:
    name: "bin/otelcol"  # Override default command to use the required `otelcol` binary included in the grafana/alloy image
  fullnameOverride: otel-collector
  mode: daemonset
  presets:
...

Use case

Run the OTel Demo with the Alloy OTel Engine

Tip

_{React with 👍 if this issue is important to you.}

[blewis12]

Hiya @cyrille-leclerc - thanks for this, can you link to the OTel Demo you referenced? I'd like to understand where you got the base config from, and if this is from a user facing guide somewhere

[cyrille-leclerc]

Great catch, I clarified the description. It's a test on the Kubernetes deployment of the OpenTelemetry Demo , I'm trying to replace he contrib collector with the Alloy OTel Engine.
The "only" thing that makes this test not realistic is the usage of the opensearch exporter which is very specific to the usage of OpenSearch as an observability backend. The rest of he OTel Collector usage is quite realistic:

• Use through the very popular OTel Collector Helm Chart
• Configured mostly through presets which represent popular configs of the collector
• Common usage of the OTel Collector on k8s:
  • Transport and enrich application OTLP telemetry
  • K8s & host infra monitoring

[blewis12]

Popping this here just to reflect offline discussions:

Whilst it's not expected that collector distributions all work with the provided OTel example, we could definitely learn about market expectations and what use cases matter most to users from these upstream helm charts. I think there is a good argument here to include both the k8s_observer and receiver_creator (since they work in tandem) in our OTel Engine, they are also included in a number of other distributions.

I will create a more broad issue so that we can discuss the topic of what further components we can include as we iterate and link that back here. We could consider user demand, source repository and any dependency issues - in general it would be good to set up a guideline for this, and set any expectations for component removal as well.

Thanks again for bringing this one up for discussion @cyrille-leclerc!