[EXPORTER] Add custom HTTP client

[ltowarek]

Fixes #2084

Changes

Adds a way to provide a custom HTTP client instead of the default libcurl-based client.

The main motivation are embedded and cross-compiled targets where libcurl is unavailable. A working example for ESP32S3 using ESP-IDF's esp_http_client as the transport backend is at ltowarek/esp-opentelemetry-cpp#30.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ltowarek / name: Lukasz Towarek (a323792)
• ✅ login: ThomsonTan / name: Tom Tan (07d6483, 8b2112a, a5264df)

[owent]

Could you please add a test to use a simple custom http client?

[lalitb]

Thanks @ltowarek. Couple of review comments as of now -

1. As @owent mentioned, could we also add a minimal example for this option, even if the transport is just a no-op custom HttpClient / HttpClientSync? The important part is showing where the user provides HttpClientFactory::Create() and CreateSync(), and how their target is linked with the OTLP HTTP exporter.

2. Also, I believe there are still a few CMake paths that bring in curl directly. For example, Zipkin, Elasticsearch, HTTP examples, and the W3C tracecontext HTTP test server still link opentelemetry_http_client_curl / CURL::libcurl, while WITH_CUSTOM_HTTP_CLIENT=ON disables the curl client target globally. Can we either make this option explicitly incompatible with those curl-only paths, or update them to follow the same custom-client path?

[codecov]

Codecov Report

❌ Patch coverage is 6.90476% with 391 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.06%. Comparing base (16b1369) to head (864d706).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
exporters/otlp/src/otlp_http_metric_exporter.cc	0.00%	122 Missing ⚠️
exporters/otlp/src/otlp_http_exporter.cc	0.00%	118 Missing ⚠️
...xporters/otlp/src/otlp_http_log_record_exporter.cc	0.00%	118 Missing ⚠️
...orters/elasticsearch/src/es_log_record_exporter.cc	0.00%	9 Missing ⚠️
exporters/otlp/src/otlp_http_exporter_factory.cc	0.00%	8 Missing ⚠️
.../otlp/src/otlp_http_log_record_exporter_factory.cc	0.00%	8 Missing ⚠️
...ters/otlp/src/otlp_http_metric_exporter_factory.cc	0.00%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4071      +/-   ##
==========================================
- Coverage   82.01%   80.06%   -1.94%     
==========================================
  Files         385      386       +1     
  Lines       16023    16416     +393     
==========================================
+ Hits        13139    13142       +3     
- Misses       2884     3274     +390     

Files with missing lines	Coverage Δ
...y/exporters/elasticsearch/es_log_record_exporter.h	0.00% <ø> (ø)
...de/opentelemetry/exporters/otlp/otlp_http_client.h	100.00% <ø> (ø)
exporters/otlp/src/otlp_http_client.cc	67.50% <100.00%> (-0.06%)	⬇️
exporters/zipkin/src/zipkin_exporter.cc	88.89% <100.00%> (ø)
...pentelemetry/ext/http/client/http_client_factory.h	100.00% <100.00%> (ø)
...t/src/http/client/curl/http_client_factory_curl.cc	100.00% <100.00%> (ø)
exporters/otlp/src/otlp_http_exporter_factory.cc	36.85% <0.00%> (-26.79%)	⬇️
.../otlp/src/otlp_http_log_record_exporter_factory.cc	36.85% <0.00%> (-26.79%)	⬇️
...ters/otlp/src/otlp_http_metric_exporter_factory.cc	36.85% <0.00%> (-26.79%)	⬇️
...orters/elasticsearch/src/es_log_record_exporter.cc	0.00% <0.00%> (ø)
... and 3 more

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dbarker]

Thanks for the PR. Please see the question below.

[ltowarek]

Thanks for the feedback! I think I've covered everything in the new patch set:

• Added opentelemetry_http_client interface library to easily inject different implementations.
• Added tests based on http_client::nosend::HttpClient.
• Added an example app.
• Used WITH_HTTP_CLIENT_CURL=OFF instead of WITH_CUSTOM_HTTP_CLIENT.

[marcalff]

Thanks for the contribution.

Please consider to use:

• an abstract class HttpClientFactory, with virtual methods for Create and CreateSync
• A child class HttpCurlClientFactory, which implement this for CURL
• a HttpCurlClientFactory::singleton

Everywhere the static method HttpClientFactory::Create() is used today, pass a HttpClientFactory instance instead, taken as input parameter.

The user of an HTTP client can then decide which implementation to use:

• pass HttpCurlClientFactory::singleton to use CURL
• pass an instance of MyOwnHttpClientFactory for alternate implementations.

It should be possible to mix CURL and non CURL HTTP clients in the same binary, for example:

• send traces using HTTP + CURL to endpoint A
• send metrics using HTTP + alternate to endpoint B

[ltowarek]

Thanks for the contribution.

Please consider to use:

* an abstract class `HttpClientFactory`, with virtual methods for `Create` and `CreateSync`

* A child class `HttpCurlClientFactory`, which implement this for CURL

* a HttpCurlClientFactory::singleton

Everywhere the static method HttpClientFactory::Create() is used today, pass a HttpClientFactory instance instead, taken as input parameter.

The user of an HTTP client can then decide which implementation to use:

* pass HttpCurlClientFactory::singleton to use CURL

* pass an instance of MyOwnHttpClientFactory for alternate implementations.

It should be possible to mix CURL and non CURL HTTP clients in the same binary, for example:

* send traces using HTTP + CURL to endpoint A

* send metrics using HTTP + alternate to endpoint B

@marcalff, it looks like a good idea.

My main goal with the current PR is build-time configuration - to enable opentelemetry-cpp for embedded systems as they simply can't build
libcurl. The binary for such systems will always contain only one HTTP client.

I think runtime changes should be a part of a separate PR which I'm open to working on.

[ltowarek]

@marcalff I've added runtime changes to this PR. Please let me know if b8eb45d fits the needs.

[lalitb]

Thanks for adding the runtime factory path. I think this is moving in the right direction, but can we make the injection story consistent across all HTTP exporters?

Right now OtlpHttpExporterFactory has overloads that accept a custom HttpClientFactory / HttpClient, but the OTLP HTTP log and metric exporter factories still only expose the default-client path. That means a user can inject a custom client for traces, but not for logs/metrics through the same public factory API.

Also, after making HttpClientFactory::Create*() virtual instance methods, there still seem to be a few static call sites left, for example the HTTP example and test_ext_http_curl.cc. Those should probably go through GetDefaultHttpClientFactory()->Create*() or a concrete curl factory.

[ltowarek]

@lalitb thanks for the feedback! I've addressed your comments in the latest commits.

Need to review again after changes.