RFC: Trace Identifiers

[tedsuo]

This is the Tracking issue for the Trace Identifiers RFC.

Proposal: https://github.com/opentracing/specification/blob/master/rfc/trace_identifiers.md

Summary

The OpenTracing SpanContext interface is extended to include SpanID and TraceID accessors.

The OpenTracing model of computation specifies two primary object types, Spans and Traces, but does not specify identifiers for these objects. Identifiers for the two primary object types make it easier to correlate tracing data with data in other systems, simplify important tasks, and allow the creation of reusable trace observers.

Current Status

Work is ready to begin, but there is one final bikeshed to paint: what to call these methods. SpanID and TraceID are the ideal names. However, these method names are already in use by some tracers, but with more specialized return types. Adding them to the SpanContext interface risks causing collisions and potentially creating breaking changes for some tracers. Using a slightly different method name would reduce the chance of a collision, at the expense of being... not TraceID or SpanID. Once we pick a satisfactory term, we can quickly add this feature to all of the OpenTracing APIs.

Let's debate naming conventions on gitter and see if we can get consensus.

Related Issues and Discussions

• RFC https://github.com/opentracing/specification/blob/master/rfc/trace_identifiers.md
• Go Expose TraceID and SpanID from SpanContext opentracing-go#188
• Java Implement Trace Identifiers. opentracing-java#280
• Javascript add trace identifiers to the span context opentracing-javascript#120
• Python

[tedsuo]

We may want to consider unwrapping as part of the same RFC. Typecasting will no longer be reliable if OpenTracing middleware becomes common.

Relevant Issues and PRs

• Add unwrap to interfaces opentracing-java#282
• Add Span#unwrap opentracing-java#211

[austinlparker]

For reference, this was added to the C# Tracer in opentracing/opentracing-csharp#96

[carlosalberto]

@austinlparker Wondering if the names should be updated to the latest that the Java API has (ToTraceId() and ToSpanId()) - something to consider ;)

[austinlparker]

I don’t think it’d really be idiomatic C#; TraceId and SpanId are both accessed via getter auto-properties on ISpanContext, which is imo where I’d expect them to be in C#.

…

On Mon, Oct 15, 2018 at 12:38 PM Carlos Alberto Cortez < ***@***.***> wrote: @austinlparker <https://github.com/austinlparker> Wondering if the names should be updated to the latest that the Java API has (ToTraceId() and ToSpanId()) - something to consider ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD8uxIXtNmEpASTZxlegRQorPgiwjAC9ks5ulLoBgaJpZM4VKTPA> .

[felixbarny]

The to prefix signals that this these may not be simple properties but some implementations have to convert their internal representation to strings which results in memory allocations.

…

On Mon 15. Oct 2018 at 20:26, Austin Parker ***@***.***> wrote: I don’t think it’d really be idiomatic C#; TraceId and SpanId are both accessed via getter auto-properties on ISpanContext, which is imo where I’d expect them to be in C#. On Mon, Oct 15, 2018 at 12:38 PM Carlos Alberto Cortez < ***@***.***> wrote: > @austinlparker <https://github.com/austinlparker> Wondering if the names > should be updated to the latest that the Java API has (ToTraceId() and > ToSpanId()) - something to consider ;) > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > < #123 (comment) >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AD8uxIXtNmEpASTZxlegRQorPgiwjAC9ks5ulLoBgaJpZM4VKTPA > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACEDCOYoN_p7iNczN_j5R1zj6OKbk7xYks5ulNNsgaJpZM4VKTPA> .

[austinlparker]

I've forked this convo into the C# repo so we don't clog up this thread.

[codeman9]

I really like this idea. Right now the fact that SpanContext is essentially empty in the opentracing interface is a little strange and leaves open too many things. Something like traceId and spanId accessors with common naming would be wonderful to put in this interface.

[ghostsquad]

any movement on this?

[jsvensson]

Also curious about this one - with new tools like Grafana's Tempo that can correlate logs to traces and take you straight to the trace view from the log viewer, I definitely want to log the trace ID for that purpose.

[yurishkuro]

I updated the status in the description - it's implemented in Java/JS only. The RFC was approved, but the spec was not updated.

Unlikely to see much traction here since all efforts moved to OpenTelemetry.

[jsvensson]

Thanks for the update! We don't yet have any tracing where I work, but I'm trying to champion it and get it going. I've experimented with both OpenTracing and OpenTelemetry, but thus far I've leaned towards OpenTracing due to otel-go not yet having a stable enough API. I think we can manage that though.

[mukul-brevo]

Hi @yurishkuro

Is there any progress on adding the methods to Golang API?

I see the thread is inactive for past 2 years

[yurishkuro]

There won't be any progress, the project is deprecated.