Implement "Named Tracers and Meters"

[z1c0]

The "Named Tracers and Meters" RFC (https://github.com/open-telemetry/oteps/blob/master/text/0016-named-tracers.md) has been approved and was added to the specification (open-telemetry/opentelemetry-specification#264).

Please make sure to also update the documentation if necessary (tracer, meter creation).

OpenTelemetry language repositories now need to implement this mechanisms.

[fbogsany]

TBH, based on my reading of the spec, I have no idea of how to either implement or use this mechanism. I'd ask for clarification, but I don't know where to start 😞.

[z1c0]

Heres the OTEP/RFC that was the basis for the changes in the specification:
https://github.com/open-telemetry/oteps/blob/master/text/0016-named-tracers.md
Maybe this one clear that up a little bit.

Also, the PR for named tracers in .NET might help:
open-telemetry/opentelemetry-dotnet#239

[fbogsany]

I read the OTEP. It didn't help. Specifically, the motivation seemed weak and the extra complexity doesn't seem justified. I think the intent is to build additional functionality on top of this, but that functionality isn't spelled out in the OTEP, so it's a little too opaque. Some code examples (in the OTEP) for instrumentation and application authors might have gone a long way to improving clarity.

[louy2]

Instrumentation libraries can easily "spam" backend systems, deliver bogus data or - in the worst case - crash or slow down applications.

This sentence in the OTEP reminds me of when systemd spammed kernel log on debug (FreeDesktop Bug 76935). Linux kernel ended up gaining an option to prevent all user-space applications from writing to the kernel log, akin to "a Sampler [...] that discards Spans or Metrics from certain libraries".

[fbogsany]

This is done, at least the API side and the tracing part of the SDK. We don't have a SDK spec for metrics yet.