Skip to content

[protocol/exporter] allow SDK users to enrich the user-agent header in exporters #4479

Open
@david-luna

Description

@david-luna

What are you trying to achieve?

As a developer using an upstream SDK to build my own OpenTelemetry Agent or a distribution I want to be able to differentiate my product from the upstream one. I see its possible to leverage resource SDK semantic conventions for that but it would require to inspect the payloads of every request. I may want to treat differently (redirect) request from my product and having info in the headers would mean less processing.

Checking the user-agent section I can read

OpenTelemetry protocol exporters SHOULD emit a User-Agent header to at a minimum identify the exporter, the language of its implementation, and the version of the exporter. For example, the Python OTLP exporter version 1.2.3 would report the following:

OTel-OTLP-Exporter-Python/1.2.3

One can interpret at a minimum that the header is not limited to have only this value. Also the next paragraph states

The format of the header SHOULD follow RFC 7231

and the section 5.5.3 of the RFC

The User-Agent field-value consists of one or more product identifiers, each followed by zero or more comments

so my interpretation is as long as it complies with the RFC is valid to append a product identifier.

What did you expect to see?

IMHO the specification should be explicit about this case either if tis allowed or not.

If allowed there should be a way in the SDKs to append the user-agent header. I've checked java, swift and js SDKs and none of them allow it.

  • should there be a OTEL_* env var for that in env vars spec?
  • or should be a local configuration for each SDK?

Metadata

Metadata

Assignees

No one assigned

    Labels

    spec:protocolRelated to the specification/protocol directorytriage:accepted:needs-sponsorReady to be implemented, but does not yet have a specification sponsor

    Type

    No type

    Projects

    Status

    Spec - Accepted

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions