@opentelemetry/exporter-trace-otlp-grpc ignores headers

[ruslan-mikhailov]

Hello!

According to the documentation, it is possible to provide custom headers when configuring the OTLP trace exporter:

new OTLPTraceExporter({
    // optional - default url is http://localhost:4318/v1/traces
    url: '<your-otlp-endpoint>/v1/traces',
    // optional - collection of custom headers to be sent with each request, empty by default
    headers: {},
  })

However, the headers option is ignored in the @opentelemetry/exporter-trace-otlp-grpc package, as seen in the implementation here: https://github.com/open-telemetry/opentelemetry-js/blob/v1.x/experimental/packages/otlp-grpc-exporter-base/src/configuration/convert-legacy-otlp-grpc-options.ts#L36

This behavior can be confusing for library users, as demonstrated in these discussions:
https://community.grafana.com/t/sending-one-simple-trace-to-tempo-via-http/82901/3
https://community.grafana.com/t/how-to-send-traces-from-node-js-otel-sdk-to-tempo/81283
Possible workarounds:

1. Use metadata property
2. Setting OTEL_EXPORTER_OTLP_HEADERS env variable

Are there any specific reasons why the gRPC exporter ignores the headers option? If so, I suggest explicitly documenting this behavior in the module's documentation to avoid confusion.

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

[pichlermarc]

Hi @ruslan-mikhailov, thanks for reaching out.

Yep, that's quite annoying behavior. When I restructured the exporters I decided to keep it as-is I wanted the restructuring to feel as close to a refactor as possible for end-users that use the exporters "normally" (meaning users that are not subclassing it or using any other interfaces other than the constructor, and what's defined in the SDK exporter interfaces).

Before this restructuring OTLPGRPCExporterConfigNode was required to extend OTLPExporterConfigBase for internal implementation reasons. Since I cleaned the internal implementation up, this is now not needed anymore.

(Side note: I'm planning to introduce a completely new interface to construct exporters, but am currently preoccupied with other topics)

My suggestion on how we could fix that here:

Introduce a breaking change by pulling in all applicable properties (obviously excluding headers) from OTLPExporterConfigBase into OTLPGRPCExporterConfigNode and make it not extend OTLPExporterConfigBase anymore. Then the type will be correct and we don't need to document it seperately that headers are not supported. 🙂

I'd be happy to see a PR making such a change to clarify the interface. I suppose any breakages that would occur from it would just alert users that something's wrong in their setup, which I'd say is a good thing anyway.

[pichlermarc]

(such a change would affect all grpc exporters, metrics/traces/logs alike, as they all suffer from the same issue)

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.