specification icon indicating copy to clipboard operation
specification copied to clipboard

Clarification on multi-valued tags

Open objectiser opened this issue 8 years ago • 7 comments

As mentioned here https://github.com/opentracing-contrib/java-observer/pull/3#issuecomment-313011451, it would be good to get clarification regarding whether a tracer should support multiple values for the same tag key? And if so, describe the use cases.

The spec currently says "A set of zero or more key:value Span Tags. The keys must be strings. The values may be strings, bools, or numeric types."

Although it doesn't necessarily impact the current Tracer API either way, the application developer should have a clear understanding of whether using the same key will result in multiple values being stored, or any existing value being overwritten.

If we need to support both types of tracer, then it should be clearly stated that this is a tracer implementation detail.

objectiser avatar Jul 06 '17 08:07 objectiser

The APIs in most languages imply unique keys by using setTag instead of addTag methods.

My preference is to be restrictive in the API but permissive in the implementations, meaning the end users may not count on multiple values to be stored by the backend, but implementations do not have to guarantee that only one key wins. In other words, the behavior of calling setTag with the same key more than once is implementation specific rather than defined by the spec.

yurishkuro avatar Jul 06 '17 13:07 yurishkuro

+1 on implementation specific. And why this will help supporting multi types of tracer?

wu-sheng avatar Jul 07 '17 03:07 wu-sheng

The main reason for raising the point was because in the Observer API we need to provide access to the tags, so wanted to get clarification on whether multivalues are supported.

However from an app developer perspective, it may be best to be clear that this is impl specific, as they may develop their app against one tracer that records multiple values for a tag, so their application takes advantage of that - but then later they switch to a different impl and find they are no longer able to search their traces based on the complete set of values.

objectiser avatar Jul 07 '17 08:07 objectiser

I understand your concern about the different tag features. But I even can't convince myself which one is better. In sky-walking, because of Entry and Exit spans exist, they even provided different feature for tag:

  • Entry span override the tag value
  • Exit span ignore the new tag value

And including your choice of multi-values, these are more choice to make. Hard to tell which is better, and forbid to do others.

But in the Observer API, there may be a easy solution, return a List<TagEntity>, TagEntity include a key and a value. By doing this, multi-values and one value are supported. Thoughts? @objectiser

wu-sheng avatar Jul 07 '17 08:07 wu-sheng

@wu-sheng I've added a similar suggestion to https://github.com/opentracing-contrib/java-observer/pull/3#issuecomment-313618255 - although the valid point made by @felixbarny is that it adds complexity where in most cases there will only be a single value per key.

objectiser avatar Jul 07 '17 08:07 objectiser

@objectiser I see. But still, for me, shouldn't make the decision for tracer implementations. It hurts OT's populazation and understanding. : )

wu-sheng avatar Jul 07 '17 09:07 wu-sheng

The nuance I think we are aiming for is "OT supports the idea that you screw up sometimes, and accidentally set a tag twice. There is no other reason for setting multiple tag values." Does that sound correct?

tedsuo avatar Jul 14 '17 19:07 tedsuo