stats/opentelemetry: Add support for optional label grpc.lb.backend_service in per-call metrics

[mbissa]

Addresses A89

RELEASE NOTES:

• stats/opentelemetry: Add support for optional label grpc.lb.backend_service in per-call metrics

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.96%. Comparing base (ece7397) to head (acbd0fe).
⚠️ Report is 10 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8637      +/-   ##
==========================================
- Coverage   82.17%   81.96%   -0.22%     
==========================================
  Files         415      415              
  Lines       40709    40759      +50     
==========================================
- Hits        33453    33408      -45     
- Misses       5883     5992     +109     
+ Partials     1373     1359      -14     

Files with missing lines	Coverage Δ
internal/xds/balancer/clusterimpl/clusterimpl.go	82.47% <100.00%> (-0.98%)	⬇️
internal/xds/balancer/clusterimpl/picker.go	96.96% <100.00%> (+0.03%)	⬆️
stats/opentelemetry/client_metrics.go	86.66% <100.00%> (+0.07%)	⬆️

... and 34 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[dfawley]

LGTM thanks! Assigning @easwars for visibility

[dfawley]

Similar here.

[davinci26]

One small comment/question on the implementation given the dependency on istats.GetLabel would that label/metric be available for people who are using custom statsHandler?

[easwars]

One small comment/question on the implementation given the dependency on istats.GetLabel would that label/metric be available for people who are using custom statsHandler?

You are correct that a custom statsHandler would not have access to these labels. But if you have a reason to want access to these labels, we can have a discussion about it, and we could move this out of internal into an experimental package. That way, you will have access to the labels, but we will retain the right to make changes to the API.

Please let us know what you think. Thanks.

[davinci26]

@easwars yeah that works for me, I can add integration tests in my implementation and check before upgrades. As long as there is a method breaking changes are totally fine

[easwars]

@davinci26 : Please feel free to send us a PR. Thanks.