You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add HTTP/protobuf OTLP export support to otel-webserver-module #614
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)
Activity