Add HTTP protocol test case to OTLP exporter integration tests

[pellared]

Add HTTP protocol test case to OTLP exporter integration tests to help with #2691

Remarks

AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);

is only needed for the gRPC OTLP protocol (on .NET 3.1 Core of course).

[codecov]

Codecov Report

Merging #2692 (132c98d) into main (2c9501f) will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #2692      +/-   ##
==========================================
- Coverage   84.06%   84.03%   -0.03%     
==========================================
  Files         251      251              
  Lines        8778     8778              
==========================================
- Hits         7379     7377       -2     
- Misses       1399     1401       +2     

Impacted Files	Coverage Δ
...emetry.Api/Internal/OpenTelemetryApiEventSource.cs	76.47% <0.00%> (-5.89%)	⬇️
...ter.ZPages/Implementation/ZPagesActivityTracker.cs	97.14% <0.00%> (-2.86%)	⬇️
...Telemetry/Internal/SelfDiagnosticsEventListener.cs	97.65% <0.00%> (+0.78%)	⬆️

[tomkerkhove]

I don't see it either so it might be the collector :/

[reyang]

LGTM in general, perhaps we want to rename CollectorEndpoint to CollectorHostname/CollectorHostName.

[pellared]

LGTM in general, perhaps we want to rename CollectorEndpoint to CollectorHostname/CollectorHostName.

Agree. The main problem is.... That the test for HttpProtobuf are failing and the reason is unknown. I do not know when I will have time to investigate it further

[reyang]

LGTM in general, perhaps we want to rename CollectorEndpoint to CollectorHostname/CollectorHostName.

Agree. The main problem is.... That the test for HttpProtobuf are failing and the reason is unknown. I do not know when I will have time to investigate it further

Is this a priority? I don't know much history about this component, why would people want to use HTTP instead of gRPC? I can imagine the following:

1. Work with HTTP proxies, so it's simpler to penetrate firewalls.
2. Required by some company policies.
3. Less dependency? (I doubt if is this the case today)

[pellared]

I heard that it is also more performant and it is the default proposed by spec https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md.

I think the URL for HttpProtobuf is bad in the test code. I will check it on Monday

[pellared]

@tomkerkhove There were two issues:

1. a bug in test (missing whole trace endpoint URL)
2. For an unknown reason the collector was not listening on the default HTTP endpoint port at all. I had to explicitly set the endpoint URL in the config. When I have more time I'll check if it is already fixed in https://github.com/open-telemetry/opentelemetry-collector

Both issues were addressed here 75ec65f

[pellared]

@open-telemetry/dotnet-approvers PTAL

[tomkerkhove]

Thanks for sharing and taking a closer look! I've noticed you have removed the HTTP comment remark, is that on purpose?

[pellared]

Thanks for sharing and taking a closer look! I've noticed you have removed the HTTP comment remark, is that on purpose?

Yes, because it is not needed and the integration test confirms it. Take notice:

#if NETCOREAPP3_1
            // Adding the OtlpExporter creates a GrpcChannel.
            // This switch must be set before creating a GrpcChannel when calling an insecure HTTP/2 endpoint.
            // See: https://docs.microsoft.com/aspnet/core/grpc/troubleshoot#call-insecure-grpc-services-with-net-core-client
            if (protocol == OtlpExportProtocol.Grpc)
            {
                AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
            }
#endif

[alanwest]

LGTM

[cijothomas]

LGTM in general, perhaps we want to rename CollectorEndpoint to CollectorHostname/CollectorHostName.

Agree. The main problem is.... That the test for HttpProtobuf are failing and the reason is unknown. I do not know when I will have time to investigate it further

Is this a priority? I don't know much history about this component, why would people want to use HTTP instead of gRPC? I can imagine the following:

1. Work with HTTP proxies, so it's simpler to penetrate firewalls.
2. Required by some company policies.
3. Less dependency? (I doubt if is this the case today)

^ There are backends which doesn't support Grpc.