Open mat-rumian opened 3 years ago
Hi @mat-rumian - the xray propagation name is a bit of a misnomer. Currently, that header is the only format supported when propagating through AWS services like Lambda, but it is not tied to the X-Ray service in any way. The header functions well for propagating through with X-Ray disabled on e.g., API Gateway and Lambda.
Some more detail is in the spec here https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/instrumentation/aws-lambda.md#determining-the-parent-of-a-span. This is essentially "OpenTelemetry context propagation" and aims to make sure OpenTelemetry instrumentation can propagate through AWS.
There is one known bug in JS which we do need to fix though https://github.com/open-telemetry/opentelemetry-js-contrib/issues/565
Are you seeing any other issue with the propagation mechanism even with active tracing (X-Ray) turned off on Lambda and/or API gateway?
I know this is old, but I'm trying to understand if this is related to my issue. I'm using API Gateway v2 and an ADOT instrumented NodeJS lambda function. I'm looking to disable X-Ray and send traces to a third party vendor. When I do this, I don't get a root span (i.e. the lambda invocation itself). Assume there is no upstream service passing in trace information.
Are HTTP APIs supported (API Gateway v2) and what is the proper set of configuration settings to make this work properly without relying on upstream traces or active tracing in X-Ray?
This issue was marked stale. It will be closed in 30 days without additional activity.
As it is OpenTelemetry Lambda instrumentation project which is using OpenTelemetry SDKs it would be nice to have an OT context propagation enabled by default in the AWS Lambda instrumentation. Current implementation of the instrumentation requires to call Lambda function with AWSXray context propagation. This could help to avoid holes/remote spans in the traces if end user is not aware of AWSXray context propagation.