Add a static Trace Class

[gideonkorir]

Add a static Trace class with the following properties:

public static class Trace
{
   static ITracer tracer = new NullTracer();

   public static ITracer Tracer
   {
      get { return tracer; }
      set { tracer = value ?? new NullTracer(); }
}

The Tracer property is initialized during application startup and provides entry point for accessing the tracer. This pattern is similar with those provided by many loggers e.g. Serilog has something akin to:

public class Log
{
  public ILogger Logger { get; set; }
}

[cwe1ss]

Sorry for not replying - I’m on a sabbatical right now. Please see #52 for a topic that IMO should be resolved before we do any further changes.

[cwe1ss]

This is not part of the core API but Java has a GlobalTracer in its utils-library. I'll probably create this library once #50 is merged (which brings the core API up to date with the Java version).

[ndrwrbgs]

Are we sure we don't want this in the library? It seems like such a common usage scenario it should be promoted to being part of the package (like how System.Buffers offers an ArrayPool<T>.Shared for everyone to use)

More actionable reply: how do we go about suggesting that a shared static tracer be part of the cross-language standard?

[cwe1ss]

AFAIK the plan is to keep the core API library as small as possible and to only add stuff to it once it has proven its value. For that reason, implementations like GlobalTracer and ThreadLocalScopeManager are in the utils-project in Java for now. Someone correct me if I'm wrong.

Anyway, it's in opentracing-util in Java right now so to make sure we achieve parity with Java ASAP, we should follow their lead. Should we decide to move it one day, we just have to keep the namespace to keep the impact to a minimum.

[gideonkorir]

I personally think that having a static Trace/GlobalTracer part of the package is a necessary evil, if I had to go DI with the tracer I'd go bonkers especially since I'm combining tracing, logging and metrics (I have 3 dependencies at the very least but these are cross cutting).

I agree with following the java reference impl but in this case I think the benefits far outweigh the cost of deviation.

One less nuget package that I need to know is also an added advantage.

[ndrwrbgs]

I thought the same, but I had misunderstood what Christian meant. In this case, java has it in the same package (or at least repo) but a different folder from the core API interfaces.

Regarding your 3 dependencies though, you may want to take a look at opencensus -- (apologies for the cross-advertising but I think everyone should know of their options :) )

[gideonkorir]

@ndrwrbgs thanks for the update. I'll look at opencensus thanks for letting me know.

In that case I don't have any objection.

[cwe1ss]

I thought the same, but I had misunderstood what Christian meant. In this case, java has it in the same package (or at least repo) but a different folder from the core API interfaces.

It's different packages - see https://mvnrepository.com/search?q=io.opentracing

I proposed in #55 to combine Java's "mock", "util" and "noop" into one C# OpenTracing.Utils project. We'll see if anyone has some feedback on that.

if I had to go DI with the tracer I'd go bonkers especially since I'm combining tracing, logging and metrics (I have 3 dependencies at the very least but these are cross cutting).

"Ideally" you would only instrument with OT and add your logs to spans. Tracing/Metrics/Logging systems would be subscribers of this data. However, there's no good story for this yet in .NET (as there's no proper public implementations at all).

Regarding your 3 dependencies though, you may want to take a look at opencensus -- (apologies for the cross-advertising but I think everyone should know of their options :) )

I understand OpenCensus as an "implementation" framework. IOW, OpenTracing is very valuable to be used in public libraries and frameworks for "instrumentation" purposes where you don't want to take any dependencies on wire formats etc.. In your application, you would either use a vendor-specific implementation-library (e.g. zipkin, ...) or use OpenCensus which can be configured to send data to many systems (e.g. zipkin). Both would be subscribers to the OpenTracing data. However, there's no .NET story for this yet either.

(Disclaimer: I've only looked at OpenCensus very briefly so far so this might be wrong 😄)

[cwe1ss]

I'll close this since we will have Java's GlobalTracer in the upcoming release. There's also already an open PR for it (#61), so feel free to review that.