Support for OTLP/UDP Span Exporter (Lambda use case)

[jj22ee]

Is your feature request related to a problem? Please describe.

People who want to use OTel in AWS Lambda are recommended to use the OTel Lambda Layers that packages both the OTel Collector and OTel SDK components to instrument a Lambda Function. However, using OTel on Lambda may incur performance impact, partially due to using OTel Collector.

• Slow start-up? opentelemetry-lambda#263 - issue summarizes the performance impact in Lambda

Describe the solution you'd like

The approach to reduce the performance impact in Lambda by OTel involves avoid running the Collector in Lambda.
Recently, Lambda supports their own endpoint to receive OTLP/UDP spans and send them to AWS X-Ray. It exists as an alternative to the Collector's OTLP Receiver.

Today, AWS Observability's auto-instrumentation is leveraging a UDP Exporter to export traces to Lambda's UDP endpoint to send traces to AWS X-Ray. I want to add this UDP Exporter to an OTel JS repository (either contrib or non-contrib).

Additional context

At first glance, while the intent of this solution is for Lambda specific, the exporter seems generic. Should this be named as a Lambda OTLP/UDP Exporter or just OTLP/UDP Exporter?

Should this issue be relocated to the opentelemetry-js-contrib repo?

[pichlermarc]

Hmm, the rule of thumb is If there's no specification for it, then it should not go here. 🤔
It seems OTLP/UDP is non-specified and is something that's only supported by AWS X-Ray (correct me if I'm wrong) - in that case it it could become a vendor component in contrib.

What I'm wondering though is - IIUC the improvement would only take effect if the collector is removed. If that's the case and OTLP/UDP is not in the spec, what is the plan to keep this approach compatible with OTel's principle of being vendor-agnostic? Can you forward the Spans received via UDP somewhere else via OTLP/http or OTLP/gRPC without added cost? 🤔

[jj22ee]

You are right that this endpoint is specific to vending to X-Ray, not vendor-agnostic. This UDP Exporter solution is re-using the existing UDP endpoint at 127.0.0.1:2000 that is currently used by the X-Ray tracing SDKs. This means this performance impact mitigation solution is not compatible with the vendor-agnostic principal; the existing collector-in-Lambda solution is still needed to vend to non-XRay. I think AWS Lambda still needs a new solution from their end to mitigate performance in this scenario.

I'll recreate the issue in the contrib repo to continue the conversation.