search

jaegertracing / jaeger

CNCF Jaeger, a Distributed Tracing Platform
https://www.jaegertracing.io/
Apache License 2.0
20.57k stars 2.45k forks source link

Repeated/unique tag/log fields #974

Open pavolloffay opened 6 years ago

pavolloffay commented 6 years ago

Requirement - what kind of business use case are you trying to solve?

Support repeated tags/logs keys. The support can be divided into client (e.g. https://github.com/jaegertracing/jaeger-client-java/issues/25) and server side (storage implementation). If we cannot guarantee repeated keys it should be documented somewhere.

Proposal - what do you suggest to solve the problem or improve the existing situation?

Offer the same feature across clients and storage implementations.

pavolloffay commented 6 years ago

TODO

yurishkuro commented 6 years ago

Support repeated tags/logs keys.

why not unique tags instead?

pavolloffay commented 6 years ago

I mean multiple tags with the same key.

yurishkuro commented 6 years ago

I know, I'm saying if we want to discuss this, why not consider going in the other direction? Many other systems (zipkin, census, canopy, etc) explicitly restrict tags to single value. Even OpenTracing API sort of implies it by calling methods SetTag. Treating tags as a map affords certain optimizations in some storage backends. I don't recall a practical example when having multi-value tags was beneficial.

pavolloffay commented 6 years ago

I am fine with that. Although it might be a breaking change for some users. We should know if there are use cases for repeated tags and also what performance improvements can be done by forcing unique keys.

In zipkin I have seen something like http.path: path1,path2. I am not sure it's on purpose bc zipkin does not support repeated keys.

wotc-baynhas commented 6 years ago

Chiming in here that I'd like to see one-key/one-value, if only because the opentracing-go documentation says that is what will happen: https://github.com/opentracing/opentracing-go/blob/master/span.go#L50