Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

example: add temporality selector option to metrics-basic #2217

Merged

Conversation

pitoniak32
Copy link
Contributor

@pitoniak32 pitoniak32 commented Oct 16, 2024

Follow up PR from this comment: #2204 (review)

Changes

Add Temporality selector option to metrics-basic example

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)

@pitoniak32 pitoniak32 requested a review from a team as a code owner October 16, 2024 12:25
Copy link

codecov bot commented Oct 16, 2024

Codecov Report

Attention: Patch coverage is 43.28358% with 38 lines in your changes missing coverage. Please review.

Project coverage is 79.3%. Comparing base (f677458) to head (0c9e5c6).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
opentelemetry-otlp/src/metric.rs 0.0% 15 Missing ⚠️
opentelemetry-sdk/src/metrics/manual_reader.rs 0.0% 8 Missing ⚠️
opentelemetry-stdout/src/metrics/exporter.rs 0.0% 6 Missing ⚠️
opentelemetry-otlp/src/exporter/http/mod.rs 0.0% 3 Missing ⚠️
opentelemetry-sdk/src/metrics/instrument.rs 70.0% 3 Missing ⚠️
opentelemetry-otlp/src/exporter/tonic/mod.rs 0.0% 2 Missing ⚠️
opentelemetry-sdk/src/metrics/mod.rs 90.9% 1 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##            main   #2217     +/-   ##
=======================================
+ Coverage   79.2%   79.3%   +0.1%     
=======================================
  Files        122     121      -1     
  Lines      20986   20944     -42     
=======================================
- Hits       16623   16612     -11     
+ Misses      4363    4332     -31     

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

@pitoniak32 pitoniak32 force-pushed the example/metrics-basic-temporality branch 3 times, most recently from 23494fc to 773803c Compare October 17, 2024 22:15
Used the full path so it can just be uncommented without needing to adjust imports
@pitoniak32 pitoniak32 force-pushed the example/metrics-basic-temporality branch from c8e1fa1 to 2e6a0af Compare October 17, 2024 23:42
@pitoniak32 pitoniak32 force-pushed the example/metrics-basic-temporality branch from 2e6a0af to a7210f6 Compare October 17, 2024 23:45
@@ -945,7 +944,11 @@ mod tests {

assert_eq!(sum.data_points.len(), 1, "Expected only one data point");
assert!(!sum.is_monotonic, "Should not produce monotonic.");
assert_eq!(sum.temporality, Temporality::Delta, "Should produce Delta");
assert_eq!(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename this test method to no_attr_up_down_counter now that its behavior has changed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated to no_attr_up_down_counter_always_cumulative, and updated the assertion reason to indicate why Cumulative would be selected when Delta is provided for clarity in the future.

@@ -183,7 +183,7 @@
//! .with_resource(Resource::new(vec![KeyValue::new("service.name", "example")]))
//! .with_period(Duration::from_secs(3))
//! .with_timeout(Duration::from_secs(10))
//! .with_temporality_selector(DefaultTemporalitySelector::new())
//! .with_temporality(Temporality::default())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following the same thing as #2217 (comment), we could just remove this.

Copy link
Contributor

@utpilla utpilla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall!

The public APIs exposed on MetricReader and PushMetricExporter traits might be updated in the future. That's mainly because it could be beneficial to push the "temporality + instrument kind" configuration solely to the exporter. That discussion and decision can happen independent of this PR.

@pitoniak32
Copy link
Contributor Author

Looks good overall!

The public APIs exposed on MetricReader and PushMetricExporter traits might be updated in the future. That's mainly because it could be beneficial to push the "temporality + instrument kind" configuration solely to the exporter. That discussion and decision can happen independent of this PR.

Awesome! I would be happy to take part in the discussion and decision around this topic when it comes up, I have been enjoying contributing to this code base and would like to take part more often :)

I will also update the CHANGELOG now that the larger concerns were addressed

@cijothomas cijothomas merged commit 4852a5e into open-telemetry:main Oct 18, 2024
24 of 25 checks passed
@cijothomas
Copy link
Member

Looks good overall!
The public APIs exposed on MetricReader and PushMetricExporter traits might be updated in the future. That's mainly because it could be beneficial to push the "temporality + instrument kind" configuration solely to the exporter. That discussion and decision can happen independent of this PR.

Awesome! I would be happy to take part in the discussion and decision around this topic when it comes up, I have been enjoying contributing to this code base and would like to take part more often :)

I will also update the CHANGELOG now that the larger concerns were addressed

Thanks!
some rough ideas:

  1. Make temporality selection purely a configuration on MetricReader, and keep exporters away from it.
  2. Exporters may offer methods that take MeterProviderBuilder as input, and returns the MeterProviderBuilder as output to make it easy for end users to enable exporters of their choice without having to worry about temporality.
    eg:
    meter_provider::builder()
    .configure_resource(..)
    .addFooExporter();

AddFooExporter() is offered by vendors/exporter authors which will add the right metric_reader with correct temporality etc automatically.

Of course this is not a requirement, so users can add reader themselves.

Alternatively, these traits can be provided with default implementation, so exporters need to override only if they wish to.

Closely related to that is the below issue. I am not a fan of OTLPExporter exposing duplicate concepts as that of SDK, so this could use some cleanups.
#1810

@pitoniak32 If you are up for it, please take a look at the above! Very happy to see more contributions from you.

@pitoniak32 pitoniak32 deleted the example/metrics-basic-temporality branch October 18, 2024 19:34
@pitoniak32
Copy link
Contributor Author

@pitoniak32 If you are up for it, please take a look at the above! Very happy to see more contributions from you.

For sure! I will take a look at this one after work today

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants