Skip to content
This repository has been archived by the owner on May 23, 2024. It is now read-only.

SelfRef, Trace & Span IDs representation #510

Closed
IurmanJ opened this issue May 5, 2020 · 6 comments
Closed

SelfRef, Trace & Span IDs representation #510

IurmanJ opened this issue May 5, 2020 · 6 comments

Comments

@IurmanJ
Copy link

IurmanJ commented May 5, 2020

Requirement - what kind of business use case are you trying to solve?

Decorate a span (finished or not) with a new tag, thanks to SelfRef.

Problem - what in Jaeger blocks you from solving the requirement?

When I start a new span, it is reported as (e.g.) 528a0623c620e047:528a0623c620e047:0000000000000000:1. Am I right to assume that the span ID is the same as the trace ID? Is it expected and why? From this, I'm able to create the same context with:

// 528a0623c620e047 = 5947573008613826631
ctx := jaeger.NewSpanContext(
                jaeger.TraceID {
			//High: 0,
			Low:  5947573008613826631,
		},
		jaeger.SpanID(5947573008613826631),
		jaeger.SpanID(0)
		false,
		nil,
)

And then I decorate it with a new tag:

span := tracer.StartSpan(
		"self-span",
		jaeger.SelfRef(ctx),
)
span.SetTag("foo", "bar")
span.Finish()

However, it adds a new span to the trace and I can see a warning in its UI block that says "duplicate span ID" (well, of course, that's what I want). I was expecting to see the new tag inside the "old" span (no matter if it's already finished or not when reporting the new tag). Maybe it is related to timestamps? It looks like they are not merged correctly. Here is a screenshot of the result:

Screenshot from 2020-05-05 13-32-07

Proposal - what do you suggest to solve the problem or improve the existing situation?

I don't know. This issue is more a check to see if it's expected behavior. If it is so, what can I do?

@yurishkuro
Copy link
Member

yurishkuro commented May 7, 2020

I think this is my mistake regarding SelfRef, I thought we had a deduping logic on the backend, but we only have it for Zipkin shared spans https://github.com/jaegertracing/jaeger/blob/16d7e09e960f5efbd975d00165f73ff775729abe/model/adjuster/span_id_deduper.go#L32.

We will need to add another standard adjuster on the backend that can merge spans like yours. It may also make sense to automatically mark spans created from SelfRef as partial (related ticket: jaegertracing/jaeger#729)

@IurmanJ
Copy link
Author

IurmanJ commented May 22, 2020

Right, I think I'll find a temporary workaround. Also, at span creation with the Go client, is it expected to have Trace Id == Span Id (see description above)? With the Python client, I correctly have a 64bits Trace Id which is different from the Span Id:

Reporting span 7c035e0eb507cd5d:d86c41ebb745435:0:1 API Request.span_check

@yurishkuro
Copy link
Member

is it expected to have Trace Id == Span Id

It is common for root spans, but not required (i.e. don't make anything depend on that). If you use 128bit IDs (recommended), then this condition will never hold.

@IurmanJ
Copy link
Author

IurmanJ commented May 28, 2020

@yurishkuro Thanks. Here is a link to the project (Cross Layer Telemetry) I'm working on, which should bring some context to my questions. I think it might be of interest to Jaeger (and maybe OpenTelemetry) to standardize something for IOAM data (right now, this is stored as tags). Thanks to IOAM, we now have L2-L7 tracing visibility instead of the current L5-L7. Let me know what you think.

@yurishkuro
Copy link
Member

Neat!

It's probably a bit early for OTEL standard semantics to reflect IOAM given that it's not part of regular kernels, from what I understood from your readme.

@IurmanJ
Copy link
Author

IurmanJ commented May 29, 2020

Neat!

Thanks!

It's probably a bit early for OTEL standard semantics to reflect IOAM given that it's not part of regular kernels, from what I understood from your readme.

Indeed, you're right. Actually, I'm busy on writing the official patch to be merged in recent kernel versions, so this is planned for soon. This patch is for pure IOAM (data plane & control plane). For the CLT, of course, we'll need to check if the CLT patch could be accepted as is or if it'd require some adaptations. The challenge with CLT is about three things: (1) passing Trace/Span IDs to the data plane (which is what the CLT patch does); (2) having different programming language libraries "compatible", which means being able to provide an already open socket to an http connection (some programming languages have their own hacks to allow that, python for instance, but it'd be nice to have something less hacky); and (3) having something dedicated (other than tags) on Jaeger side, which means OTEL standard semantics for IOAM.

By the way, IPv6 IOAM drafts (draft-ietf-ippm-ioam-ipv6-options and draft-ietf-ippm-ioam-data) are about to be standardized at the IETF (a matter of weeks).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants