Remove UseDatadog from tracing config

[mrdg]

This was introduced in #247 to allow applications to
use the datadog tracing api directly instead of an opentracing compatible version.

The issue is that when UseDatadog is enabled, opentracing.GlobalTracer is set to a noop tracer
so other packages in netlify-commons that emit traces (e.g router) don't work as expected.

We don't actually need this option because opentracer.New already calls tracer.Start so
applications should be able to use both the opentracing and datadog tracing api.

[paulo]

Nice catch!

[mheffner]

We don't actually need this option because opentracer.New already calls tracer.Start so

Does it call the tracer from ddtrace?

ddtrace and opentracing aren't compatible, are we sure this will propagate traces to a ddtrace only app?

[mrdg]

Does it call the tracer from ddtrace?

Yeah: https://github.com/DataDog/dd-trace-go/blob/v1/ddtrace/opentracer/tracer.go#L35

ddtrace and opentracing aren't compatible, are we sure this will propagate traces to a ddtrace only app?

This change is running on nfsvr staging right now and I don't see any missing traces. Is there something specific I should look for?

[mheffner]

So mongotrace that we use for tracing mongo queries is a ddtrace package. It requires us to use DD tracing or else the mongo spans aren't connected to parent request spans.

[mrdg]

So mongotrace that we use for tracing mongo queries is a ddtrace package. It requires us to use DD tracing or else the mongo spans aren't connected to parent request spans.

Right, yeah as long as those parent spans are created with the ddtrace package that will still work. I just tested it and and the mongo spans are still connected to the http request spans. The only effect of this change is that traces created via the opentracing package (such as the ones created in netlify-commons/router) are now also emitted.

Side note: longer term we should really pick one approach

[mheffner]

Yeah, I guess when I tested in this in the past the parent http spans were created with OT so they didn't connect since DD uses a different context key. It sounds like we are still using DD for those http spans but just using OT for commons router?

[mrdg]

Yeah, I guess when I tested in this in the past the parent http spans were created with OT so they didn't connect since DD uses a different context key. It sounds like we are still using DD for those http spans but just using OT for commons router?

yes exactly