What should we call the Tags package?

[tedsuo]

Current Issue:

• Tags in OpenTracing currently maps to Attributes in OpenTelemetry.
• Tags in OpenCensus are also slightly different: no getters, and they are only available for metrics.

There is a fair amount of evidence that using the name Tags to describe this package is confusing to existing users of the previous projects.

Potential names:

• Baggage
• Labels
• ???
• Live with Tags and confuse some people...

FAQ: What is the difference between Tags with TTL=0 and Context?

• If you put a value in Tags, that value is available via for OpenTelemetry to consume in metrics, traces, and logs. Context is purely for propagating application information within a single process: Context information not placed directly in Tags is not visible to the telemetry system.

Conclusion:

Currently, there is a preference for calling this Baggage.

• Users may want to propagate baggage for reasons beyond just labelling telemetry data. For example, feature flagging in a distributed system.
• The term Baggage helps indicate to users that they are bloating their RPC calls with this information, so they should be careful about what they put in there. The costs associated with using this mechanism is a very important thing for users to understand.

We are planning to go with Baggage for now. Please post questions and comments if you feel this name is not accurate.

[tylerbenson]

I thought there was also discussion about removing this concept and letting it be inherently part of the separate Context system?

[yurishkuro]

I don't think this decision contradicts that goal. If the Context system uses strongly typed keys for accessing context objects, then we do need this "baggage" layer on top of it that would provide access to propagated baggage vs. just some random objects stashed by the application in the context.

[tylerbenson]

I realize I'm trying to fight a battle I won't win, but I would much prefer for baggage/tags to be completely removed from the scope of this project. I realize there are many use cases for it, but I don't think it needs to be coupled with the tracing systems and should be an independent project.

Perhaps if the discussion were around just propagated attributes, not something that is intended to be read by the application, then I might feel differently. Allowing the user to read these values is the part that feels wrong to me.

[yurishkuro]

@tylerbenson did you see my article https://medium.com/jaegertracing/embracing-context-propagation-7100b9b6029a ?

Without support for baggage OpenTelemetry is not backwards compatible with OpenTracing. And without telemetry data being able to use propagated data it's not backwards compatible with OpenCensus either.

We still haven't decided where the context propagation will live (I actually reserved github.com/contextprop if there's an appetite to move it out), but we did agree that it should be an underlying fabric on top of which tracing and metrics and logging APIs will operate. The context propagation framework itself (completely independent of tracing & metrics) is described in https://docs.google.com/document/d/1UxrEYOaQlF_E4gtiPoFmcZ4YKKe1GxohvCvQDuwvD1I/

[tylerbenson]

@yurishkuro I've read both. I like the context api design and think we should formalize it. with regards to your blog post, some (most?) of those use cases would probably be covered with my suggestion of a propagated attribute where the application doesn't need access to the propagated data.

Without support for baggage OpenTelemetry is not backwards compatible with OpenTracing. And without telemetry data being able to use propagated data it's not backwards compatible with OpenCensus either.

I think both of the bridge/shim projects should implement this functionality directly against the context API and not entangle it with the core API.

[bogdandrutu]

We need to support this in the core API.

[yurishkuro]

@tylerbenson most of use cases in my article actually explicitly require application's access to propagated metadata, or some custom framework in the application. If we only restrict access to baggage to internal telemetry functions, it's not a real universal context propagation framework. Not to mention that it would be impossible to do precisely what you're proposing - making propagation a stand-alone underlying layer on top of which telemetry APIs are built.

The way I would like to see it working is

               +----------------------------------------------------+
               |                                                    |
  +------------+ custom application logic or specialized frameworks |
  |            |                                                    |
  |            +-------------------------------------+--------------+
  |                                                  |
  |    +---------+ +------+ +--------+               |
  |    |         | |      | |        |               |
  |    | metrics | | logs | | traces +---+           |
  |    |         | |      | |        |   |           |
  |    +----+----+ +---+--+ +---+----+   |           |
  |         ^          ^        ^        |           |
  |   +-----+----------+--------+-----+  |           |
  |   |                               |  |           |
  +--->            baggage            |  |           |
      |                               |  |           |
      +---------------+---------------+  |           |
                      |                  |           |
+---------------------+------------------+-----------+-------------------+

             Universal context propagation layer <-----> marshaling
                                                          plugins

[bogdandrutu]

@yurishkuro exactly on point. Trace may also consume tags/baggages for example by associating them at the start or end of the Span.

[yurishkuro]

Amended:

• metrics / traces / logs typically don't need to write to baggage, only read from it
• the application writes to baggage, either telemetry labels or general-purpose baggage
• both types of baggage reuse the same marshaling plugin (e.g. w3c Correlation-Context header)
• application may also write other stuff to context and provide custom marshaling (although this is questionable since it's not going to be universal - another application may not register the same marshaller and as a result not propagate the additional metadata)
• tracing has separate marshaling plugin for trace context that is separate from baggage

[SergeyKanzhelev]

metrics / traces / logs typically don't need to write to baggage, only read from it

Exceptions may be tracing that sets some context tags that can be used to slice metrics. Or logs framework setting log "scope" consumed by tracing. In both cases you can think of it as specialized frameworks. I'm not actually sure what specialized framework means.

[SergeyKanzhelev]

In open-telemetry/opentelemetry-java#11 we decided DistributedContext

[SergeyKanzhelev]

Closing as it was decided. If there are alternative proposals - please file a new issue