Propose "Named Tracers"

[z1c0]

No description provided.

[bogdandrutu]

I am requesting more changes because:

1. This does not address the Metrics part;
2. This change adds the notion of a Resource back in the API. I do agree that the Resource is a good concept to have, but I think this belongs to the implementation (in our case SDK) not the API.

[z1c0]

@bogdandrutu I'm not quite sure how we left off after yesterday's discussion in the spec meeting. Are you OK with the approach that we propose a dedicated RFC for metrics (and also logs at some later point in time) to have a better separation of concerns?
Metrics and logs get a mention in "Future possibilities" (i.e. "very near future" for metrics).

[bogdandrutu]

@z1c0 I would prefer to not postpone the metrics:

1. This is a major API change that we need for Meter as well before alpha.
2. All reasons that we need this for Trace apply to Metrics as well.
3. We want to be consistent between Meter/Tracer in general if possible.

I suggest that we just re-write a bit the first few paragraphs to generalize the motivation for metrics as well.

Everything else stays the same:

// Create a tracer/meter for given instrumentation library in a specific version.
Tracer tracer = OpenTelemetry.getTracerFactory().getTracer("io.opentelemetry.contrib.mongodb", "semver:1.0.0");
Meter meter = OpenTelemetry.getMeterFactory().getMeter("io.opentelemetry.contrib.mongodb", "semver:1.0.0");

Also do we need a way to access unnamed Tracer/Meter?

[z1c0]

@bogdandrutu metrics are now included in this proposal.
Unnamed Tracers/Meters are mentioned in the last "Explanation" paragraph.

[tigrannajaryan]

LGTM, subject to addressing Bogdan's comments regarding having uniform handling for Metrics as well (or a plan for it if it is not addressed in this PR).

[Oberon00]

Seems like this is ready to merge then?

[bogdandrutu]

@z1c0 please in parallel start two PRs:

1. To mark this approved.
2. A PR to change specs accordingly.