Routing Processor is always Routing to default exporter when receiver is oltp http

[shahrajesh2006]

Component(s)

processor/routing

What happened?

Description

Routing Processor is routing to default exporter when the receiver is oltp http.

Steps to Reproduce

See the below configuration of routing processor

-------------------
receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:8443"
exporters:
  logging:
    loglevel: debug
  otlp:
    endpoint: https://xyz.com/
    headers:
      api-key: $API_KEY_1
    compression: gzip
  otlp/one:
    endpoint: https://xyz.com/
    headers:
      api-key: $API_KEY_2
    compression: gzip
  otlp/two:
    endpoint: https://xyz.com/
    headers:
      api-key: $API_KEY_3
    compression: gzip
processors:
  routing:
    from_attribute: otel-exporter-lob
    default_exporters:
    - logging
    - otlp
    table:
    - value: one
      exporters: [logging, otlp/one]
    - value: two
      exporters: [logging, otlp/two]
extensions:
  health_check:
    endpoint: "0.0.0.0:8080"
  pprof:
  zpages:
    endpoint: "0.0.0.0:11400"
service:
  telemetry:
    logs:
      level: "debug"
  extensions: [pprof, zpages, health_check]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [logging, otlp, otlp/one, otlp/two]
      processors: [routing]
    metrics:
      receivers: [otlp]
      exporters: [logging, otlp, otlp/one, otlp/two]
      processors: [routing]
---------------------------------

Routing process is ignoring http header"otel-exporter-lob" values "one/two" and always routes to default exporters.

Expected Result

When the http header "otel-exporter-lob" is "one" route to following exporters
exporters: [logging, otlp/one]

When the http header "otel-exporter-lob" is "two" route to following exporters
exporters: [logging, otlp/two]

Actual Result

Routing process is ignoring http header"otel-exporter-lob" values "one/two" and always routes to default exporters.

Collector version

latest

Environment information

Environment

OS: Amazon Linux
Compiler(if manually compiled): (e.g., "go 14.2")

OpenTelemetry Collector configuration

receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:8443"
exporters:
  logging:
    loglevel: debug
  otlp:
    endpoint: https://xyz.com
    headers:
      api-key: $API_KEY_1
    compression: gzip
  otlp/one:
    endpoint: https://xyz.com
    headers:
      api-key: $API_KEY_2
    compression: gzip
  otlp/two:
    endpoint: https://xyz.com
    headers:
      api-key: $API_KEY_3
    compression: gzip
processors:
  routing:
    from_attribute: otel-exporter-lob
    default_exporters:
    - logging
    - otlp
    table:
    - value: one
      exporters: [logging, otlp/one]
    - value: two
      exporters: [logging, otlp/two]
extensions:
  health_check:
    endpoint: "0.0.0.0:8080"
  pprof:
  zpages:
    endpoint: "0.0.0.0:11400"
service:
  telemetry:
    logs:
      level: "debug"
  extensions: [pprof, zpages, health_check]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [logging, otlp, otlp/one, otlp/two]
      processors: [routing]
    metrics:
      receivers: [otlp]
      exporters: [logging, otlp, otlp/one, otlp/two]
      processors: [routing]

Log output

No relevant log

Additional context

Router works when the the receiver is using "oltp" grpc protocol

[github-actions]

Pinging code owners:

• processor/routing: @jpkrohling @kovrus

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[kovrus]

You need to provide the following configuration for the otlp receiver, that should fix your configuration

     otlp:
       protocols:
         http:
           endpoint: "0.0.0.0:8443"
           include_metadata: true

[shahrajesh2006]

ok let me try that - Thanks @kovrus

[shahrajesh2006]

@kovrus - Even after updating config as suggested above. I still see routing to default value.

[akats7]

Hi @jpkrohling, it looks like in the current state the processor does not support http metadata that is not from the grpc server, would you accept a PR to add this functionality. We can still default to the default grpc extraction using the grpc metadata module and then in the case that it does not return anything try to extract it from client.Info.

[shahrajesh2006]

@atoulme @kovrus @akats7 tagging couple of more folks to this discussion thread.

[jpkrohling]

Thank you for the PR. The direction is good, just need one more test.