Summary
Add support for HTTP/protobuf OTLP export protocol alongside the existing gRPC export in the otel-webserver-module (used for Apache HTTPD and Nginx auto-instrumentation).
Motivation
The OpenTelemetry Operator provides auto-instrumentation for multiple languages (Java, Python, Node.js, .NET, Go). All other language auto-instrumentations support configuring the OTLP export protocol via the OTEL_EXPORTER_OTLP_PROTOCOL environment variable, and default to http/protobuf. The Apache HTTPD and Nginx auto-instrumentations are the exception — they hardcode gRPC at the native C++ level by directly linking libopentelemetry_exporter_otlp_grpc.so.
This creates operational friction:
- Users must ensure their collector exposes the gRPC endpoint (port 4317) specifically for these two instrumentations, even if everything else in their environment uses HTTP/protobuf (port 4318)
- The
OTEL_EXPORTER_OTLP_PROTOCOL environment variable is silently ignored, leading to confusion
- Operator users cannot use a uniform collector configuration across all auto-instrumented workloads
Proposed Change
- Link both OTLP exporter libraries — Build the webserver module against both
opentelemetry_exporter_otlp_grpc and opentelemetry_exporter_otlp_http
- Add runtime protocol selection — Read
OTEL_EXPORTER_OTLP_PROTOCOL (and the signal-specific variants OTEL_EXPORTER_OTLP_TRACES_PROTOCOL, etc.) at exporter initialization time
- Use the appropriate factory — Instantiate
OtlpHttpExporterFactory or OtlpGrpcExporterFactory based on the configured protocol
- Default to
http/protobuf — Align with the OpenTelemetry specification default and the behavior of all other auto-instrumentations
This is architecturally straightforward because the upstream opentelemetry-cpp SDK already provides both exporters behind a shared SpanExporter interface. The webserver module pipeline is transport-agnostic — only the exporter instantiation point needs to change.
Scope
- Apache HTTPD auto-instrumentation
- Nginx auto-instrumentation
- CMake/build changes to link the HTTP exporter library and its dependency (libcurl)
- Supported protocol values:
grpc, http/protobuf, http/json
Related
Summary
Add support for HTTP/protobuf OTLP export protocol alongside the existing gRPC export in the otel-webserver-module (used for Apache HTTPD and Nginx auto-instrumentation).
Motivation
The OpenTelemetry Operator provides auto-instrumentation for multiple languages (Java, Python, Node.js, .NET, Go). All other language auto-instrumentations support configuring the OTLP export protocol via the
OTEL_EXPORTER_OTLP_PROTOCOLenvironment variable, and default tohttp/protobuf. The Apache HTTPD and Nginx auto-instrumentations are the exception — they hardcode gRPC at the native C++ level by directly linkinglibopentelemetry_exporter_otlp_grpc.so.This creates operational friction:
OTEL_EXPORTER_OTLP_PROTOCOLenvironment variable is silently ignored, leading to confusionProposed Change
opentelemetry_exporter_otlp_grpcandopentelemetry_exporter_otlp_httpOTEL_EXPORTER_OTLP_PROTOCOL(and the signal-specific variantsOTEL_EXPORTER_OTLP_TRACES_PROTOCOL, etc.) at exporter initialization timeOtlpHttpExporterFactoryorOtlpGrpcExporterFactorybased on the configured protocolhttp/protobuf— Align with the OpenTelemetry specification default and the behavior of all other auto-instrumentationsThis is architecturally straightforward because the upstream opentelemetry-cpp SDK already provides both exporters behind a shared
SpanExporterinterface. The webserver module pipeline is transport-agnostic — only the exporter instantiation point needs to change.Scope
grpc,http/protobuf,http/jsonRelated
OTEL_EXPORTER_OTLP_PROTOCOL: https://opentelemetry.io/docs/specs/otel/protocol/exporter/