open-telemetry
[protocol/exporter] allow SDK users to enrich the `user-agent` header in exporters
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?
hi @david-luna, can OTEL_EXPORTER_OTLP_HEADERS be used to override the user-agent header in those implementations?
Hi @trask,
At least in opentelemetry-js it was possible before and I did use it. But I wasn't sure if it was meant to work that way so I've asked about it in https://github.com/open-telemetry/opentelemetry-specification/issues/4230
The conclusion I got was that it was not desired to allow app devs to modify the UA header via env var.
thanks, sounds like a good clarification (one way or the other) in the specification