Questions on the Distributed Trace extension
See original GitHub issue1. Why not just use traceparent
as the attribute?
There is already precedence for doing this with content-type
in the broader spec. Ex, from datacontenttype:
For some binary mode protocol bindings, this field is directly mapped to the respective protocol’s content-type metadata property.
Which is specified in the HTTP binding spec
For the binary mode, the HTTP Content-Type header value corresponds to (MUST be populated from or written to) the CloudEvents datacontenttype attribute. Note that a ce-datacontenttype HTTP header MUST NOT also be present in the message.
It doesn’t feel intuitive to allow both traceparent
and ce-traceparent
as distinct things. Which kinda leads to my next questions:
2. The spec says …
Given a multi hop event transmission, the Distributed Tracing Extension, if used, MUST carry the trace information of the starting trace of the transmission. In other words, it MUST NOT carry trace information of each individual hop, since this information is usually carried using protocol specific headers, understood by tools like OpenTelemetry.
2.1) What’s the purpose in changing the behavior of traceparent
here vs how the W3C spec says it should be? And why not rename it like “starting traceparent” or something if that’s the case?
2.2) Even if there is a good reason, the example seems to allow ignoring the original trace info (by the fact that there are two different traceIDs). Even if you were going to stick with saying traceparent MUST carry the trace information of the starting trace
– I feel like other trace info should at least be on the same tree.
Ex, current example (different trace-id, different parent-id):
-H ‘ce-traceparent: 00-0af7651916cd43dd8448eb211c80319c-b9c7c989f97918e1-01’
-H ‘traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01’ \
In this case, I’d expect something like (same trace-id, different parent-id):
-H ‘ce-traceparent: 00-0af7651916cd43dd8448eb211c80319c-b9c7c989f97918e1-01’
-H ‘traceparent: 00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01’ \
Issue Analytics
- State:
- Created a year ago
- Comments:8
@joaopgrassi @ntextreme3 thanks for the good chat - lots of good info in there!
If the same initial event is forwarded (or travels) to/from AppN, then all of those will link to App1. The simple way to think is: subsequent apps will extract whatever context is in the event and add it as a link to its own trace. If the initial event “goes through many hops” it’s then clear all of those hops will link to the initial
App1
.Yes, exactly. The multi hop ends when the next consumer doesn’t forward the event anymore. It “settles” it.
In your example, when
App2
receives the initial event fromApp1
, it will start its own trace, and extract the context (ce-traceparent
) from the event and add it as a link, linkingApp2
<>App1
. Then say, the event inApp2
caused some side effect andApp2
needs to send a new event toApp3
. Then the whole process starts again -App2
creates the new event, a new span and adds it inside of it. The new event is forwarded and, at some point,App3
receives it. Then you have a link ofApp3
<>App2
.I did some drawings for the case above, maybe it helps
Apps interaction:![image](https://user-images.githubusercontent.com/5938087/173035892-57032b9d-2e49-44ef-b677-ff28c9c8bd68.png)
Achieved trace, using the conventions from here/OpenTelemetry![image](https://user-images.githubusercontent.com/5938087/173037198-e96dcc2a-ca54-4bbc-9598-967fafc9b7da.png)
Of course, all other actions that happens in either apps will be part of each trace, as long there’s some auto-instrumentation in place. Say,
App2
makes some Db calls and those are instrumented. It will all be part ofApp2
’s trace.