opentelemetry-dotnet icon indicating copy to clipboard operation
opentelemetry-dotnet copied to clipboard

Setting OTLP Exporter Endpoint Inconsistent Behaviour (Environment Variable vs Options)

Open cparkins opened this issue 1 year ago • 3 comments

Bug Report

List of all OpenTelemetry NuGet packages and version that you are using (e.g. OpenTelemetry 1.0.2):

  • OpenTelemetry 1.6.0
  • OpenTelemetry.Extensions.Hosting
  • OpenTelemetry.Exporter.OpenTelemetryProtocol 1.6.0

Runtime version (e.g. net462, net48, netcoreapp3.1, net6.0 etc. You can find this information from the *.csproj file):

  • net6.0

Symptom

When trying to send data to an Otel Collector using the HTTP Protocol setting the Endpoint using the Exporter Options does not append the default path for the HTTP Endpoints. But when setting the Endpoint via Environment Variable the path is modified.

What is the expected behavior?

What did you expect to see?

When using the ExporterOptions the code should work the same as the Environment Variables.

What is the actual behavior?

The Environment Variables append the default path. The Exporter Options do not.

What did you see instead?

No OpenTelemetry data is sent to my configured Endpoint because the request is malformed.

Reproduce

Create a self-contained project using the template of your choice, apply the minimum required code to result in the issue you're observing.

This is simple to reproduce using the example code found on the OpenTelemetry .NET Exporter Documentation: AddOtlpExporter

We will close this issue if:

  • The repro project you share with us is complex. We can't investigate custom projects, so don't point us to such, please.
  • If we can not reproduce the behavior you're reporting.

Additional Context

This problem exists because of how the underlying code sets the endpoint when using the Exporter Options versus the Environment Variable. See the Code links below: OtlpExporterOptions.Environment Setter: https://github.com/open-telemetry/opentelemetry-dotnet/blob/b0f9607a806c1e888446c6f70bc00062a4e1ceef/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpExporterOptions.cs#L130

Environment Variable: https://github.com/open-telemetry/opentelemetry-dotnet/blob/b0f9607a806c1e888446c6f70bc00062a4e1ceef/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpExporterOptions.cs#L72

And the code that determines how to set the Endpoint: https://github.com/open-telemetry/opentelemetry-dotnet/blob/b0f9607a806c1e888446c6f70bc00062a4e1ceef/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/BaseOtlpHttpExportClient.cs#L35

cparkins avatar Nov 15 '23 20:11 cparkins

@cparkins : Does this issue still needs to be open? Looks like the docs have been updated in the mean time (https://github.com/open-telemetry/opentelemetry.io/pull/3583) to better signify that you have to use the full URL when configuring the endpoint using OtlpExporterOptions.

ngruson avatar Dec 19 '23 14:12 ngruson

@cparkins : Does this issue still needs to be open? Looks like the docs have been updated in the mean time (open-telemetry/opentelemetry.io#3583) to better signify that you have to use the full URL when configuring the endpoint using OtlpExporterOptions.

I think those changes should make it more clear that the full URL is expected, unlike when using the gRPC option.

cparkins avatar Dec 19 '23 21:12 cparkins

Is the new cross-cutting UseOtlpExporter expected to work nicely with OtlpExporterOptions?

the note

When the protocol is set to OtlpExportProtocol.HttpProtobuf a signal-specific path will be appended automatically to the base URL when constructing exporters.

contradicts the later note

When using OtlpExportProtocol.HttpProtobuf, the full URL MUST be provided, including the signal-specific path v1/{signal}. For example, for traces, the full URL will look like http://your-custom-endpoint/v1/traces.

I've reverted to three separately named configs with the full url for each, but its a little weird if UseOtlpExporter works with HttpProtoBuf only if you don't specify the endpoint and let it default to localhost:4318?

AlanRitchie avatar Mar 27 '24 18:03 AlanRitchie