Add dedicated OTLP/HTTP listener on port 4318#70
Open
RaphaelManke wants to merge 4 commits into
Open
Conversation
The extension previously accepted OTLP data from the runtime only over HTTP on the proxy listener port (9009, DASH0_LISTENER_PORT), which also serves the Lambda Runtime API proxy. It now additionally listens on the default OpenTelemetry ports: - 4318 (DASH0_OTLP_HTTP_PORT): dedicated OTLP/HTTP listener serving only the /v1/traces, /v1/logs and /v1/metrics ingest routes - 4317 (DASH0_OTLP_GRPC_PORT): new OTLP/gRPC receiver (tonic) for the trace, logs and metrics services, feeding the same processing pipeline The receivers were refactored so the transport-independent payload handling is shared between the HTTP handlers and the gRPC services. OTLP/HTTP on port 9009 keeps working for backwards compatibility. The runtime distros (Node, Python, Java) and the manual-instrumentation docs now point to port 4318. The manual-instrumentation integration test lambda is deployed in two variants exercising both OTLP/HTTP (4318) and OTLP/gRPC (4317). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H3abARSdGW8Edy6LT8CBdP
The gRPC receiver added ~1.2 MiB zipped per layer (tonic, axum, h2) while providing no benefit over OTLP/HTTP on loopback: OTLP only uses unary calls with identical protobuf payloads, and all shipped distros export via OTLP/HTTP anyway. The extension now accepts OTLP over HTTP on the default OpenTelemetry port 4318 (DASH0_OTLP_HTTP_PORT) plus the legacy proxy port 9009, and no longer listens on 4317. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H3abARSdGW8Edy6LT8CBdP
The python distro used BatchSpanProcessor defaults, i.e. a 5s schedule delay. Spans still queued in the SDK when Lambda kills a timed-out runtime are lost, which made the python timeout integration tests flaky (the HTTP client span intermittently never reached the extension). The Java distro already batches tightly (otel.bsp.schedule.delay=10ms) for the same reason; align the python distro. The standard OTEL_BSP_SCHEDULE_DELAY environment variable still takes precedence. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H3abARSdGW8Edy6LT8CBdP
On platform.runtimeDone with an error status (e.g. timeout), the telemetry handler signaled the runtime-done notifier before building the synthetic trace. With DASH0_SEND_ON_INVOCATION_END=true the notifier wakes the invocation-end flush task, which concurrently drains the stored traces. When that task won the race, build_synthetic_trace could no longer recover the invocation's real trace id from the stored spans and fell back to a derived one, breaking correlation between the synthetic handler span and already-received spans (observed as the flaky python timeout integration tests: the HTTP client span never matched the synthetic trace id). Defer the signal until after error traces are built and sent, making the ordering deterministic. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H3abARSdGW8Edy6LT8CBdP
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a dedicated OTLP/HTTP receiver listening on the default OpenTelemetry HTTP port (4318) while maintaining backwards compatibility with the existing proxy port (9009). The extension now spawns two separate HTTP servers to handle different concerns: the Lambda Runtime API proxy on port 9009 and OTLP ingest on port 4318.
Key Changes
New OTLP/HTTP listener: Added a dedicated HTTP server listening on port 4318 (configurable via
DASH0_OTLP_HTTP_PORTenvironment variable) that only handles OTLP ingest routes (/v1/traces,/v1/logs,/v1/metrics)Refactored HTTP server setup: Extracted HTTP server spawning logic into a generic
spawn_http1_server()function that accepts a handler, allowing multiple servers with different routing logicSeparate routing: Created
OTLP_ROUTESstatic router for the dedicated OTLP listener, while the mainROUTEScontinue to handle both Lambda Runtime API proxy and OTLP (for backwards compatibility)New dispatch function: Added
dispatch_otlp()function that routes requests only to OTLP endpoints, returning 404 for anything elseConfiguration support: Added
otlp_http_port()function inconfig/endpoints.rsto read the OTLP HTTP port from environment variablesUpdated documentation and examples: Updated README and language-specific distro examples (Java, Node.js, Python) to point to the new standard OTLP/HTTP port (4318) instead of the proxy port (9009)
Implementation Details
https://claude.ai/code/session_01H3abARSdGW8Edy6LT8CBdP