-
Notifications
You must be signed in to change notification settings - Fork 288
SelfRef, Trace & Span IDs representation #510
Comments
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) |
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:
|
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. |
@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. |
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. |
Thanks!
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). |
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:And then I decorate it with a new tag:
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:
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?
The text was updated successfully, but these errors were encountered: