Catalog of well-known Correlation Context key names

[SergeyKanzhelev]

In order to improve interoperability of tracers we may start cataloguing the well-known names of correlation context key names. This issue is to discuss whether this catalog will be helpful and to collect the initial set of names.

[yurishkuro]

fwiw, our primary use of correlation context / baggage at Uber is for custom metadata, like tenancy, auth tokens, fault injection instructions. The only requirement from the tracers is that they pass it through and make available to the apps (via OpenTracing Baggage API). There's Uber-internal standardization, but not an external one.

[jacpull]

+1. I'm not sure if there is value in having a global standard set of pass through keys. Even simple things like partner or scenario or flight Id have different meanings to different parties involved and there can be multiple of each in a nontrivial flow. One approach we were thinking was based on name spacing keys to standardize on an org basis. So perhaps all we need is a marker to distinguish between custom keys unique to a component versus a standardized key. This will help in offering offloading prioritization if the context gets too large.

[SergeyKanzhelev]

I've been thinking of headers like representing common distributed tracing concepts like:

1. Caller's application name
2. Root operation name
3. User & session ID
4. Flag that the operation is synthetic (initiated by test)
5. Flag that the context was passed-thru (proxy that didn't modify the header may set it)
6. Tracing vendor identity & tenant

Other?

It may be in a form of catalog, not as a standard. Like http headers and their semantics being catalogued.

Having common names like this will enable better telemetry correlation between vendors and will minimize the need to use namespaced names all the time.

[jacpull]

• Of these, I found 1, 2 and 4 to be useful and sufficiently universal. For 1, I would interpret this as id of the component that started the trace.
• user Id and device Id seems to be useful as well. But there can multiple types of these, although there is benefit in having default/prioritized fields for them.
• The semantics of a session Id seem hazy to me. As is any notion of scenario Id/scenario type.
• 5, Not clear on use case.
• 6, useful but can be overloaded. Multiple tenants and tracing vendors may be involved in a flow.

[wu-sheng]

Here is Skywalking APM did in HEAD belongs to Correlation Context :

1. Parent Application Instance Id. Generate by collector from caller's application name for each instance/process.
2. Entry Application Instance Id. Generate by collector from root's application name for each instance/process.
3. Peer Host. ipv4/ipv6/hostname + port) of the server, from client side.
4. Entry Operation Name. Id or name of root's service name. Service name usually is an url.
5. Parent Operation Name. Id or name of caller's service name. Service name usually is an url.
6. Parent Trace Segment Id. Skywalking create a new trace segment id for each thread in the distributed trace. So this is not a trace id.

@SergeyKanzhelev Skywalking APM 's heads are very different from any other open source project. :P

[wu-sheng]

And Skywalking uses only one head key, and put all these elements in a value field, these fields are split by |.

[SergeyKanzhelev]

Not much feedback. Closing for now to clean up issues list