Redesign Labeler

[pellared]

Consider making Labeler reusable across multiple instrumentation libraries. Maybe a separate helper package?

The Labeler type is for metrics but isn't clearly connected to the rest of the API. It purpose and how it is represented in the API needs to be re-thought.

Originally posted by @MrAlias in #8107

[pellared]

CC @dmathieu

[sonalgaud12]

Let me know What you guys think about this

// EnsureLabeler returns the Labeler already stored in ctx via
// [ContextWithLabeler], or injects a fresh one and returns the updated context.
// This is the recommended way for instrumentation middleware to obtain a
// per-request Labeler: the returned context always has a live Labeler so that
// any attributes added by downstream handlers will be collected.
//
//	ctx, labeler := EnsureLabeler(ctx)
//	// pass ctx to the next handler; retrieve labeler.Get() when recording metrics
func EnsureLabeler(ctx context.Context) (context.Context, *Labeler) {
	l, ok := ctx.Value(labelerContextKey).(*Labeler)
	if !ok {
		l = &Labeler{}
		ctx = ContextWithLabeler(ctx, l)
	}
	return ctx, l
}

[pellared]

It may be beneficial for each instrumentation to have its own Labeler type. This would give the operator (application developer) a fine-grained way to attach attributes to metrics, especially in cases where the same context instance is shared across multiple instrumentations, otherwise we risk attribute bleed when the same context is used by multiple instrumentations (or even server->client within the same library).

[pellared]

At the same time, I think the API surface could be further refined. For example, we could unexport the Labeler type and make it internal. Instead, the user-facing API could provide a helper such as:

otelhttp.AddHandlerMetricsAttributes(ctx context.Context, attrs ...attribute.KeyValue)

This would preserve flexibility for users while keeping the underlying implementation details encapsulated.

[MrAlias]

@dmathieu can you take a look at this proposal and let us know what you think?

[dmathieu]

I agree that hiding the labeler itself would make a lot of sense, and would be the thing that allows having a similar interface for all instrumentations.

I'm not sure about the name, but I don't have any better suggestion at the moment.