AggregationSelector is not needed anymore

[fraillt]

Hello,

I'm not sure if this is a right way to approach this, but basically I think that AggregationSelector trait, and many with_aggregation_selector configuration methods on various public SDK types is not needed anymore, because newly introduced Views feature fully replaces this trait and removing AggregationSelector only makes things simpler/more understandable.

I created this PR as a proof to show that we can simply remove it without loosing any current functionality.

The only issue is this sentence in SDK:

If the MeterProvider has no View registered, take the Instrument and apply the default Aggregation on the basis of instrument kind according to the MetricReader instance’s aggregation property.

If I'm not missing anything, I think it could be changed to:

If the MeterProvider has no View registered, take the Instrument and apply the default aggregation.

What do you think, do you agree, or I'm missing something important here?

Changes

• Remove AggregationSelector trait
• Remove with_aggregation_selector configuration function from many public types.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: fraillt / name: Mindaugas Vinkelis (0f016ce)

[cijothomas]

This looks okay to me, thanks. We need have CLA agreement signed (one-time) before accepting any changes to the repo, as this is the mandatory requirement from OpenTelemetry/Linux-Foundation organization which hosts the project.

Though Views allow one to change default aggregation, I haven't observed demand for that capability yet!. That capability is not exposed in OTel .NET Metrics, and no one has ever asked for it so far (its been GA since late 2021). We could even remove that capability from OTel Rust too for first stable release to keep public API surface minimal, but this can be separately discussed.

[fraillt]

Thanks for guidance and your input!

For my use case it was enough when AggregatorSelector had signature of fn aggregator_for(&self, descriptor: &Descriptor) -> Option<Arc<dyn Aggregator + Send + Sync>>. It wasn't super convenient to use, but having instrument name and kind was enough to set proper histogram bucket sizes.
Views are more powerful and I like to have a power, but in my opinion they are too powerful, especially considering that they are not requested that much :). Regarding .NET i'm a bit surprised, maybe they have non-compatible (with SDK) ways to achieve same things? (worst case you implement your own MetricReader :))

In my opinion, supporting 0-N number of views was a mistake, because it's not obvious how things behave without reading very carefully SDK (or even better source code), and what is worse, you'll get warnings if you use * to change default.
If it would be exactly 1 view, things could be much simpler. I would be happy to have a simple interface with a fn change_view(&self, stream: StreamView) -> StreamView.

• Default implementation would be stream
• Drop everything would be stream.aggregation(Drop)
• For more complicated scenarios StreamView could have some helper functions like matches_name that could use * and ?, but for the most part you would write simple code.

if stream.matches_name("histogram*") {
  return stream.aggregation(Sum)
} 
if stream.scope.name =="mylib" {
  return stream.allowed_attributes([Key::new("size")])
} 
if stream.scope.name == "otherlib" && if stream.name == "my_metric" {
  return stream.description("even nicer description for other lib")
    .unit("X")
}
stream // leave unchanged default
// or .stream.aggregation(Drop) to drop the rest

Anyway, thanks again, and I'll try to get CLA signed.

[cijothomas]

Regarding .NET i'm a bit surprised, maybe they have non-compatible (with SDK) ways to achieve same things? (worst case you implement your own MetricReader :))

No there is no other way. OTel .NET simply don't allow one to change aggregation. Ofcourse it does allow one to change HistogramBuckets, and also flip between Explicit vs Exponential Histogram, but thats about it. One cannot take a Counter and ask it to be aggregated as Histogram and things like this.

[cijothomas]

@fraillt Your concerns are valid. Views does have valid use cases, but it is also true that its somewhat easy to mis-use and cause issues. My original plan was to remove Views completely from 1st stable release.. It is entirely possible we do that, or possible that we trim it down.

The most common use case for Views is to change Histogram Buckets - @utpilla is looking at fixing #1241 so one can change Histogram Buckets without having to learn about Views.

Is your scenario also just about customizing histogram buckets?

Irrespective of this, the direction of this PR is good.

[fraillt]

Yes, currently I need to customize histogram buckets, but I actually I might want to use rename or aggregation drop functionality as well... :)
Don't get me wrong, I actually think that views are very good addition, and given what they provide I think they have good design. It's just it might be too powerful and that power adds a costs in terms of user experience.

Anyway, what should I do to finish my work? Is updating appropriate CHANGELOG.md files would be enough?

[cijothomas]

Anyway, what should I do to finish my work? Is updating appropriate CHANGELOG.md files would be enough?

Please pick latest main, and see if the CI turns green. I'll get back to reviewing this after the #2088 release is done! Thanks for waiting!

[codecov]

Codecov Report

Attention: Patch coverage is 66.66667% with 7 lines in your changes missing coverage. Please review.

Project coverage is 78.2%. Comparing base (5269660) to head (0f016ce).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
opentelemetry-otlp/src/metric.rs	0.0%	2 Missing ⚠️
opentelemetry-sdk/src/metrics/pipeline.rs	87.5%	2 Missing ⚠️
opentelemetry-otlp/src/exporter/http/mod.rs	0.0%	1 Missing ⚠️
opentelemetry-otlp/src/exporter/tonic/mod.rs	0.0%	1 Missing ⚠️
opentelemetry-sdk/src/metrics/manual_reader.rs	0.0%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #2085     +/-   ##
=======================================
+ Coverage   78.0%   78.2%   +0.2%     
=======================================
  Files        121     121             
  Lines      20936   20849     -87     
=======================================
- Hits       16332   16314     -18     
+ Misses      4604    4535     -69     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fraillt]

This test is flaky.

 ---- prometheus_exporter_integration stdout ----
thread 'prometheus_exporter_integration' panicked at opentelemetry-prometheus/tests/integration_test.rs:412:5:
assertion `left == right` failed: sanitized attributes to labels

Do you know if anyone is working on it? What should I do?

How to reproduce:

1. Apply this patch on main

diff --git a/opentelemetry-prometheus/Cargo.toml b/opentelemetry-prometheus/Cargo.toml
index 3bbe65e3..22a33737 100644
--- a/opentelemetry-prometheus/Cargo.toml
+++ b/opentelemetry-prometheus/Cargo.toml
@@ -21,13 +21,13 @@ rustdoc-args = ["--cfg", "docsrs"]
 
 [dependencies]
 once_cell = { workspace = true }
-opentelemetry = { version = "0.24", default-features = false, features = ["metrics"] }
-opentelemetry_sdk = { version = "0.24", default-features = false, features = ["metrics"] }
+opentelemetry = { default-features = false, features = ["metrics"], path = "../opentelemetry" }
+opentelemetry_sdk = { default-features = false, features = ["metrics"], path = "../opentelemetry-sdk" }
 prometheus = "0.13"
 protobuf = "2.14"
 
 [dev-dependencies]
-opentelemetry-semantic-conventions = { version = "0.16" }
+opentelemetry-semantic-conventions = { path = "../opentelemetry-semantic-conventions" }
 http-body-util = { workspace = true }
 hyper = { workspace = true, features = ["full"] }
 hyper-util = { workspace = true, features = ["full"] }

2. run a test several times cargo test --package opentelemetry-prometheus --test integration_test -- prometheus_exporter_integration --exact --show-output

After investigation with git bisect here's the results

528e0a6c1403f7642a9fd6cfbaf3fd1d7ae8acab is the first bad commit
commit 528e0a6c1403f7642a9fd6cfbaf3fd1d7ae8acab
Author: Cijo Thomas <cijo.thomas@gmail.com>
Date:   Tue Aug 6 17:29:02 2024 -0700

    Metric refactor - 2x perf and allocation free (#1989)
    
    Co-authored-by: Utkarsh Umesan Pillai <66651184+utpilla@users.noreply.github.com>

 opentelemetry-sdk/benches/metric_counter.rs   |   6 +-
 opentelemetry-sdk/src/metrics/internal/sum.rs | 177 ++++++++++++++------------
 opentelemetry-sdk/src/metrics/mod.rs          |  56 ++++++++
 stress/src/metrics_counter.rs                 |   3 +
 4 files changed, 160 insertions(+), 82 deletions(-)

[cijothomas]

The changes look good. Thank you for your contirbution!

Requesting changes just to remove the Prometheus exporter changes from this PR. Please submit that as a separate PR, and we can get it in, and do a release of Prometheus as well.

[cijothomas]

Thanks a lot for your contributions! Would love to see more contributions.