feat: add OpenTracing example

[hieven]

Which problem is this PR solving?

• closes Add OpenTracing shim example #550

Short description of the changes

• Add an example for how to use shim-opentracing

[codecov-io]

Codecov Report

Merging #581 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #581      +/-   ##
==========================================
- Coverage   90.45%   90.44%   -0.01%     
==========================================
  Files         181      177       -4     
  Lines        9166     8990     -176     
  Branches      815      787      -28     
==========================================
- Hits         8291     8131     -160     
+ Misses        875      859      -16

Impacted Files	Coverage Δ
...kages/opentelemetry-metrics/test/mocks/Exporter.ts	66.66% <0%> (-33.34%)	⬇️
...res/opentelemetry-plugin-pg/test/assertionUtils.ts	96.29% <0%> (-3.71%)	⬇️
...core/src/context/propagation/BinaryTraceContext.ts	96.72% <0%> (-1.62%)	⬇️
...opentelemetry-base/test/resources/resource.test.ts	100% <0%> (ø)	⬆️
packages/opentelemetry-tracing/src/config.ts	100% <0%> (ø)	⬆️
packages/opentelemetry-tracing/src/utility.ts	100% <0%> (ø)	⬆️
...ges/opentelemetry-exporter-zipkin/src/transform.ts	100% <0%> (ø)	⬆️
...telemetry-plugin-grpc/test/utils/assertionUtils.ts	100% <0%> (ø)	⬆️
packages/opentelemetry-tracing/test/Span.test.ts	100% <0%> (ø)	⬆️
.../opentelemetry-plugin-dns/test/utils/assertSpan.ts	100% <0%> (ø)	⬆️
... and 25 more

[dyladan]

The fact that this file does OpenTracing and OpenTelemetry things together might be confusing, especially since the names are so similar. I would rather have one file that sets up open tracing the way you would normally set it up with open tracing, and another file called something like shim.js that sets up the shim. This way the example more clearly shows where the shim happens.

// shim.js

exports.shim = function shim(serviceName) {
  const tracer = new NodeTracer();
  tracer.addSpanProcessor(new SimpleSpanProcessor(getExporter()));

  return new TracerShim(tracer);
}

function getExporter() {
  const type = process.env.EXPORTER || "jaeger";
  if (type.match(/^z/)) {
    return new ZipkinExporter({ serviceName });
  }
  return new JaegerExporter({ serviceName, flushInterval: 100 });
}

// client.js
const shim = require("./shim").shim("http_client_service");

opentracing.initGlobalTracer(shim);

[hieven]

I was initially imagining people usually have a tracer package which does initialization for open tracing and vendor specific instance (e.g. Zipkin or Jaeger). In this case, open telemetry is just another vendor so I made this decision to put all of them together.

I'm wondering if this makes sense to you and if adding some comments in the code can help or it will still be better to be separated as you suggest?

Many thanks for the suggestion! 👍

[dyladan]

I think i can go either way. I would still rather have the shim separate from the opentracing tracer so it is clear where the break is

[hieven]

Sure, as your suggestion, I've created a shim file to make thing more clear. Thanks!

[OlivierAlbertini]

Great! Added few comments.

[mayurkale22]

Thanks for the PR, added a few comments.

[mayurkale22]

lgtm, added one comment.

[mayurkale22]

@open-telemetry/javascript-approvers: We need more reviews for this one!

[mayurkale22]

@hieven please rebase with the master, looks good to merge.