Proposal: Resource Scope and Namespace API about oteps

[dyladan]

Thanks for writing this up @jmacd. The quick run-through in the spec meeting last week was a little too much for me to follow in real-time so I appreciate having a full writeup. I do have some concerns over the general complexity of this, especially in the simple/average use case. I think this could be easily misunderstood and misused by SIG maintainers and end-users alike.

In addition, I have some more specific questions:

Would it be fair to say that this is a fancy way to add attributes and labels to metrics and spans automatically, based on their current scope? Does it provide anything else?

What is meant by "preventing the construction of a Scope providing a name"? Was this meant to say "preventing the construction of a Scope without providing a name"?

Is this meant to live alongside named tracers/meters, or to replace it? If replace, then how would it solve the core use case where a disabled instrumentation library should get a no-op tracer?

This is not meant as a proposal to be incorporated into the v1.0 OpenTelemetry API.

Does that mean you are in favor of moving forward with the current named tracers and this would be an addition on top of it later?

[jmacd]

Would it be fair to say that this is a fancy way to add attributes and labels to metrics and spans automatically, based on their current scope? Does it provide anything else?

It combined the notion of a namespace. Although I think namespace can be separated from the tracer/meter object (e.g., it could be attached to the name instead), I prefer it be implied by the tracer/meter.

It has the notion that a single Scope manages a reference to both a Tracer and a Meter at once. It makes it the default that these interfaces will be coordinated with the same resources and library name. I worry that we've created interfaces that are too separate. Tying the resources to the scope ensures they are coordinated across tracer and meter.

Was this meant to say "preventing the construction of a Scope without providing a name"?

Yes. (Updated.)

Is this meant to live alongside named tracers/meters, or to replace it? If replace, then how would it solve the core use case where a disabled instrumentation library should get a no-op tracer?

I am not sure I would say "replace". I was trying to separate the matter into separate discussions, as in:
(1) If tracer/meters had resources baked in, we could use resources to determine library name
(2) If we used resources to determine library name, we might still require an obligatory name be provided.

I see this (2) as the fundamental concern, but you asked how to solve the use-case. If the resources are stored as a map[Key]Value, then any time a tracer/meter is used you can perform a lookup in a map of disabled libraries (i.e., LibraryConfig[Resources[LibraryNameKey]].IsDisabled). This can be done when scopes are created, to avoid computing this for every method call.

This approach supports disabling tracing or metrics based on other resource values, potentially on boolean predicates over multiple resource values. Say you want to disable mongodb for a specific database name, for example.

Does that mean you are in favor of moving forward with the current named tracers and this would be an addition on top of it later?

I agree that we could turn these library names into resources later. I'm not sure we can retrofit something like a Scope in, which would make it easier to coordinate resources across tracer/meter impls.

[evankanderson]

This looks useful to me as an implementer of a multi-tenant service. I can see a few different ways that this helps:

1. This is useful for associating metrics (or spans) with logical Resources based on work done on their behalf (i.e. activation work when scaling from zero in Knative)
2. For storage services, this is useful for exporting logical Resources which may be "data at rest" rather than actual computation (i.e. data used/quota for a particular bucket or keyspace)

Being able to use a Resource bound to the context when performing this work makes it easier to share a common set of base labels (disk=XYZ, zone=Q, service=ABC, etc) across several different measurements which may not have the same full labelset. (In Knative, an example of this is request metrics including both queue size (with no additional labels) and request statistics (with response code labels).

[andrewhsu]

from the spec issue triage mtg today, taking metrics label off since this issue kinda applies to more

[Oberon00]

It looks like the problem that issue proposes to solve, is now solved only slightly differently by #201. At least I believe so. Or are there some leftover use cases that the solution in this issue would solve that #201 does not?

[jmacd]

I consider this effectively replaced by #207.