opentracing/specification

Standard tag for version

Opened this issue · 4 comments

objectiser commented

Should we introduce a reserved tag name for version?

In a microservices environment, with continuous deployment, different versions of the same service may be deployed at any particular point in time - using various deployment strategies to route traffic. Therefore it would be useful for understand which version of a particular service is being used within a trace instance.

wu-sheng commented

+1

yurishkuro commented

I have a couple of problems with this.

  1. The name version is too generic. For example, when we say component within the context of a single span, one can reasonably assume it's the component that's creating the span. But version is very ambiguous - is it a version of the component? Of the application? Something else? The name app.version might be more precise.
  2. app.version doesn't belong to a span! If I have an Dropwizard HTTP server, the span is created by dropwizard instrumentation, not by my service, so instrumentation wouldn't know that it needs to set a tag with my service's version. Jaeger supports the notion of a Process that is meant to describe the actual process (service, app) emitting the span. Process can have tags (aka tracer-level tags) that are set once at tracer initialization, by the service itself, and those tags are not part of any span. Internally at Uber we do use them to capture the service version, among other things. However, the tracer-level tags are not a standard mechanism in OpenTracing, so we can't really talk about standardizing on their names.
objectiser commented

Agree regarding point 1 - the actual name is something to be agreed.

In terms of point 2 - also agree that it is a 'process/tracer' level tag - so maybe as well as defining the standard tag, the Tracer also needs to be enhanced to standardise providing such tags?

wu-sheng commented

version is more likely belong to service or app. The app.version can be based on CI/CD, belongs to application, sure. But the service has their own version too. In same cases for upgrade, we will put serviceA-v1 and serviceA-v2 online at the same time.