Send trace origin

[stephanie-anderson]

Overview

The origin is of type string and consists of four parts: <type>.<category>.<integration-name>.<integration-part>. Only the first is mandatory. The parts build upon each other, meaning it is forbidden to skip one part. For example, you may send parts one and two but aren't allowed to send parts one and three without part two.

Origin Parts

1. type: Required. Can be either manual (user created the trace/span) or auto (created by SDK/integration)
2. category: Optional. Must be a category of span operations.
3. integration-name: Optional. Name of the integration or the SDK that created the trace or span. We could use sentry_dotnet (matching the name of our repository). Maybe check what other SDK teams are doing here.
4. integration-part: Optional. Part of the integration of the SDK that created the trace or span. This is only useful when one integration creates multiple traces or spans, and you'd like to differentiate. Therefore, most of the time, this will be omitted. Possibly we could use it to identify the specific NuGet Package (e.g. Opentelemetry or AzureFunctions_Worker)

Constraints

All parts can only contain:

• Alphanumeric characters: a-z , A-Z , and 0-9.
• Underscores: _

Approach

Initially perhaps we aim just to provide the required type part. Then we incrementally build out support for subsequent parts (possibly as separate pull requests... depending on how much work this looks to be).

References

• Project: Send trace origin #14
• SDK Development > Performance > Trace Origin
• SDK Development > Event Payloads > Contexts Interface > Trace Context

[jamescrosswell]

Note: I raised a question on the project here.

My current plan is to set the Origin for open telemetry spans to be auto.middleware.sentry_dotnet.opentelemetry. Whether or not these are auto or not is debatable. I couldn't find a more approriate category than middleware. I figured we'd use sentry_dotnet as the integration name for anything that has been added from the Sentry dotnet library and finally, I wanted to indicate somewhere that this had come from OpenTelemetry (so using the Integration Part Name for that).

Open to suggestions/discussion on any of that.

[jamescrosswell]

Chatted with @bitsandfoxes and we'll put this one on pause for a bit as there are other priorities.

[bitsandfoxes]

We've got some dev docs regarding span/trace origin (which are used synonymously): https://develop.sentry.dev/sdk/performance/trace-origin

[jamescrosswell]

We've got some dev docs regarding span/trace origin (which are used synonymously): https://develop.sentry.dev/sdk/performance/trace-origin

I see the docs still only allow for the type to be either manual or auto. It would be great if there was a 3rd option there = otel, since with OTEL spans, where we don't control the way spans get instrumented, we have no way of knowing whether these are manual or automatic.

Otherwise, I guess we're back to the option above if people are using our OTEL integration.

[philipphofmann]

@jamescrosswell, I answered the OTEL topic here https://github.com/getsentry/team-sdks/issues/14#issuecomment-1750501304. Please let me know if that works, because then I'm going to update the develop docs.

[bitsandfoxes]

Right now, for trace origin we simply care what created the trace. For that breakdown, it doesn't really matter whether OTEL is a part of manual or auto. The ideal outcome would be something like auto.db.otel-processor.integration-name.

Since it's the SDKs integration with OTEL via the SpanProcessor I'd argue we're fine putting it into auto. Also, I expect the percentage of incoming traces originating from OTEL to be comparatively small. There's no point in being too granular there.

[philipphofmann]

If you know it's coming from otel, I would recommend using auto.otel instead of auto only. We can also change the pattern, described in https://develop.sentry.dev/sdk/performance/trace-origin/ if required. It's not set in stone.