Resurrect "default tags" feature

[codefromthecrypt]

The old Collector component in brave had the ability to set default tags. The use cases for this weren't foreground, and we deprecated it a while back with no-one noticing (or at least complaining).

There is a use case for "default tags", particularly for platform details like runtime information. For example, in https://github.com/openzipkin/zipkin-reporter-java/issues/33 docker and aws info were mentioned, hinting at a Platform Tags provider.

This is tricky to do at the current abstraction of zipkin-reporter for reasons including its interference with size information and even knowing the type of the span that's in use. Most importantly, zipkin-reporter has no idea what the local endpoint is, and this is a required parameter for tags (binary annotations). Hence, it is best to implement this here, at least for now.

[devinsba]

This is a necessary feature for us in the apps that are on plain brave, my work on opentracing has lead me toward creating a Tracer that applies our metadata to each span at creation time. I can gist that up if you'd like to see what that looked like.

[codefromthecrypt]

This is a necessary feature for us in the apps that are on plain brave, my work on opentracing has lead me toward creating a Tracer that applies our metadata to each span at creation time. I can gist that up if you'd like to see what that looked like.

Thanks. especially I'd like to see if you can get by with supplying KV, or if you need to defer resolution with some supplier function.

[codefromthecrypt]

anyone want to give this a try? Maybe Tracer.Builder.Tags?

[codefromthecrypt]

incidentally, this can be accomplished with https://github.com/openzipkin/brave/blob/master/brave/src/main/java/brave/handler/FinishedSpanHandler.java

[codefromthecrypt]

In https://github.com/openzipkin/brave/pull/801 show how to do this, especially only once per-hop:

/**
 * This shows how you can add a tag once per span as it enters a process. This is helpful for
 * environment details that are not request-specific, such as region.
 */
public class DefaultTagsTest {
  List<zipkin2.Span> spans = new ArrayList<>();
  Tracing tracing = Tracing.newBuilder()
      .addFinishedSpanHandler(new FinishedSpanHandler() {
        @Override public boolean handle(TraceContext context, MutableSpan span) {
          if (context.isLocalRoot()) {
            // pretend these are sourced from the environment
            span.tag("env", "prod");
            span.tag("region", "east");
          }
          return true;
        }
      })
--snip--

[devinsba]

Excellent Adrian, I'll be playing with this in our starter. I think this would work really nicely alongside the pattern soundcloud uses: https://developers.soundcloud.com/blog/using-kubernetes-pod-metadata-to-improve-zipkin-traces

I would recommend adding as little to the span as you can, and then extending it at collection time if you have that ability

[codefromthecrypt]

haven't implemented this yet, but will for 5.12 coming out soon, as we now have a template MutableSpan which is easy to add stuff to