internal/stats: Moved Labels to experimental/stats package

[seth-epps]

Related to #8446

This follows up on the discussion here

By moving Labels and the associated Get/Set functions to the exported experimental/stats package we give client/server implementations of stats.Handler access to telemetry labels, otherwise only accessible if instrumented using an OpenTelemetry provider.

With this change, a handler implementation can start tracking telemetry labels by calling SetLabels in TagRPC/Tag Conn

RELEASE NOTES:

• internal/stats: Move Labels to experimental/stats package

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: seth-epps / name: Seth Epps (ea3db1c)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.02%. Comparing base (58d4b2b) to head (ea3db1c).
⚠️ Report is 11 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8671      +/-   ##
==========================================
+ Coverage   81.76%   83.02%   +1.25%     
==========================================
  Files         417      417              
  Lines       40806    32296    -8510     
==========================================
- Hits        33367    26815    -6552     
+ Misses       6057     4097    -1960     
- Partials     1382     1384       +2     

Files with missing lines	Coverage Δ
experimental/stats/labels.go	100.00% <ø> (ø)
internal/stats/stats.go	100.00% <ø> (ø)
internal/xds/balancer/clusterimpl/picker.go	97.14% <100.00%> (+0.17%)	⬆️
stats/opentelemetry/client_metrics.go	88.11% <100.00%> (+1.44%)	⬆️

... and 359 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[eshitachandwani]

LGTM. Deferring to @easwars for another review.

[dfawley]

I believe the decision to make these internal was made deliberately for cross-language parity reasons. So we might not want to do this without checking with the other languages first.

Since we need a cross language discussion before making this change.

[seth-epps]

@eshitachandwani Let me know if there's anything I can help with / dig into regarding the other implementations

Thinking about this particular move, I could maybe try to tweak things a bit and offer an init function for the labels without an otel provider and only expose GetLabels(context.Context) to minimize external stat handler interference

something like

// package experimental/stats
import (
	"context"

	istats "google.golang.org/grpc/internal/stats"
)

// InitStatLabels configures the context stat labels. WARNING: this should not be used when configuring metric collection with an OpenTelemetry provider
func InitStatLabels(ctx context.Context) {
	var labels *istats.Labels
	if labels = istats.GetLabels(ctx); labels == nil {
		labels = &estats.Labels{
			TelemetryLabels: map[string]string{},
		}
		ctx = istats.SetLabels(ctx, labels)
}

// GetLabels returns the Labels stored in the context, or nil if there is one.
func GetLabels(ctx context.Context) *Labels {
	// !!! labelsKey isn't exported by istats
	labels, _ := ctx.Value(labelsKey{}).(*Labels)
	return labels
}

But that does introduce and import cycle and there would need to be some extra refactoring to expose the context key, which I'm not sure we would want to go down that rabbit hole

[eshitachandwani]

Hey @seth-epps , as Doug pointed out , we might want to look at other language implementation if they are have the functionality to expose these functions and if yes how do they do this and we might want to do something similar. In the mean time , we could open an issue and discuss your use case and figure out if there could be some workaround for your particular use case.

[eshitachandwani]

Closing the PR to discuss the issue and possible solutions on the issue : #8682