opentracing
Standard tag for version
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.
I have a couple of problems with this.
- The name
versionis too generic. For example, when we saycomponentwithin the context of a single span, one can reasonably assume it's the component that's creating the span. Butversionis very ambiguous - is it a version of the component? Of the application? Something else? The nameapp.versionmight be more precise. -
app.versiondoesn'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 aProcessthat is meant to describe the actual process (service, app) emitting the span.Processcan 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.
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?
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.