Issue with OpenTelemetry.Extensions.AWS

Context

The AWS X-Ray Propagator automatically attaches the X-Amzn-Trace-Id header to requests, facilitating trace continuity across services. An example header is:

X-Amzn-Trace-Id: Root=1-5759e988-bd862e3fe1be46a994272793;Parent=53995c3f42cd8ad8;Sampled=1

This header, carrying Root trace ID, Parent span ID, and Sampled status, is crucial for linking traces across services. However, when tracing crosses AWS account boundaries, it introduces specific challenges:

Context Loss: Information critical for debugging and optimization, such as response codes, execution times, and URLs, may not be properly captured or associated due to the reliance on Parent span IDs from different AWS accounts.
Inherited Sampling Decision : The downstream service inherits the sampling decision (Sampled) from the upstream service. This can lead to misaligned tracing efforts, where downstream services might either collect too much or too little trace data, based on the upstream's decision.

I propose enhancing the AWSXRayPropagator to support a new feature: accepting a scope parameter. This enhancement entails:

Scope Parameterization: Modifying the AWSXRayPropagator to accept scope as a parameter.
Injecting Scope: Adding the scope value as an X-Amzn-Trace-Scope header within the Inject function.
Scope Verification: During extraction, if the X-Amzn-Trace-Scope does not match the expected scope, initiating a new trace. This functionality will allow for defining trace boundaries via the scope parameter, ensuring that traces are accurately linked within their designated scope. It's designed to improve trace management across AWS accounts, providing a method to clearly delineate trace boundaries and enhance trace clarity.

Is this a feature request or a bug?

[x] Feature Request
[ ] Bug

What is the expected behavior?

The enhancement aims to introduce scoped tracing to the AWSXRayPropagator within opentelemetry-dotnet-contrib, leveraging an additional X-Amzn-Trace-Scope header. This feature ensures traces are linked only when they share a common scope, improving trace management across AWS accounts managed by different teams.

What is the actual behavior?

Without scoped tracing, services across different AWS accounts may inaccurately link traces, leading to incorrect trace information and difficulties in monitoring and debugging across service boundaries.

Expected Enhancement:

public class AWSXRayPropagator : TextMapPropagator
{
    // Existing constants and fields...

+   private const string TraceScopeHeader = "X-Amzn-Trace-Scope";
+   private readonly string? scope;

    /// <summary>
    /// Initializes a new instance of the <see cref="AWSXRayPropagator"/> class.
    /// </summary>
    public AWSXRayPropagator()
    {
+       this.scope = null;
    }

    /// <summary>
    /// Initializes a new instance of the <see cref="AWSXRayPropagator"/> class with the specified scope.
    /// </summary>
    /// <param name="scope">The scope parameter allows for defining trace boundaries within a specific scope.</param>
+   public AWSXRayPropagator(string scope)
+   {
+       this.scope = scope;
+   }

    // Existing methods...

    public override PropagationContext Extract<T>(PropagationContext context, T carrier, Func<T, string, IEnumerable<string>> getter)
    {
        // Existing extraction logic...

+       try
+       {
+           if (!string.IsNullOrEmpty(this.scope))
+           {
+               var traceScopeHeader = getter(carrier, TraceScopeHeader);
+               if (traceScopeHeader == null
+                   || traceScopeHeader.Count() != 1
+                   || traceScopeHeader.First() != this.scope)
+               {
+                   // If the scope doesn't match, continue with a new trace
+                   return context;
+               }
+           }

            // Existing extraction logic continues...
        }
        catch (Exception ex)
        {
            // Existing error handling...
        }

        return context;
    }

    public override void Inject<T>(PropagationContext context, T carrier, Action<T, string, string> setter)
    {
        // Existing injection logic...

+       if (!string.IsNullOrEmpty(this.scope))
+       {
+           setter(carrier, TraceScopeHeader, this.scope);
+       }
    }

    // Existing internal helper methods...
}

If this proposal gains consensus, I am ready to create a PR to implement these changes.

open-telemetry / opentelemetry-dotnet-contrib

Enhance AWSXRayPropagator with Scope Functionality for Better Trace Management #1602

Issue with OpenTelemetry.Extensions.AWS

Context