Prototype of a very basic Aggregation-configuration API in the SDK.

[jkwatson]

Note: related OTEP: open-telemetry/oteps#126

This prototype supports the following:

• select instruments to customize by instrument type and name.
• specify the aggregation and the temporality of the aggregation to be used.

An example of how you could use it:

// get a handle to the MeterSdkProvider
 MeterSdkProvider meterProvider = OpenTelemetrySdk.getMeterProvider();

 // create a selector to select which instruments to customize:
 InstrumentSelector instrumentSelector = InstrumentSelector.newBuilder()
  .instrumentType(InstrumentType.COUNTER)
  .build();

 // create a specification of how you want the metrics aggregated:
 ViewSpecification viewSpecification = 
      ViewSpecification.create(Aggregations.minMaxSumCount(), Temporality.DELTA);

 //register the view with the MeterSdkProvider
 meterProvider.registerView(instrumentSelector, viewSpecification);

[codecov]

Codecov Report

Merging #1412 into master will decrease coverage by 0.03%.
The diff coverage is 86.95%.

@@             Coverage Diff              @@
##             master    #1412      +/-   ##
============================================
- Coverage     92.50%   92.46%   -0.04%     
- Complexity      939      955      +16     
============================================
  Files           117      119       +2     
  Lines          3348     3385      +37     
  Branches        270      274       +4     
============================================
+ Hits           3097     3130      +33     
- Misses          169      173       +4     
  Partials         82       82              

Impacted Files	Coverage Δ	Complexity Δ
...va/io/opentelemetry/sdk/metrics/ActiveBatcher.java	87.50% <0.00%> (-12.50%)	4.00 <0.00> (ø)
...in/java/io/opentelemetry/sdk/metrics/Batchers.java	92.98% <50.00%> (-1.57%)	4.00 <0.00> (ø)
...io/opentelemetry/sdk/metrics/MeterSdkProvider.java	94.44% <50.00%> (-5.56%)	5.00 <1.00> (ø)
...ava/io/opentelemetry/sdk/metrics/ViewRegistry.java	88.23% <93.54%> (+24.59%)	16.00 <12.00> (+10.00)
...try/sdk/metrics/view/AggregationConfiguration.java	100.00% <100.00%> (ø)	2.00 <2.00> (?)
...telemetry/sdk/metrics/view/InstrumentSelector.java	100.00% <100.00%> (ø)	4.00 <4.00> (?)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 78ed649...cbbe742. Read the comment docs.

[anuraaga]

API seems reasonable to me, guess some more javadoc to add?

[anuraaga]

Think we'd usually order specification.temporality() == or use a switch

[jkwatson]

I've seen it both ways...I don't think there's much of a standard, or even agreement on this. Back in the day, I'd use .equals() even for enums, since someone could change it from an enum and break code if you use ==. :)

[anuraaga]

Not sure but it seems like this could be applicable as a top level enum (outside the realm of views)

[jkwatson]

possibly, yes. I think this will become a top-level concept eventually, so if/when that happens, we'll definitely make it more first-class.

[mxiamxia]

Wondering why we don't want ViewRegistry per MeterSdk instance level? What if I have Metric instruments with the same type and name but I want it have different custom aggregation & temporality on different instrumentationName?

[jkwatson]

The SDK user won't in general know what named Meters are available, so I don't know how you would access the specific Meter in order to have a registry at that level. How were you thinking that an operator would know how to use this if the API were available only on the individual Meters?

[tylerbenson]

@jkwatson what needs to happen to make progress here? I feel this is a blocker for my work in adding an additional aggregation option.

[jkwatson]

@jkwatson what needs to happen to make progress here? I feel this is a blocker for my work in adding an additional aggregation option.

Well, aside from a rebase... we'd have to decide this was something we wanted to implement, even though it's not really spec'd at this point.

[jkwatson]

closing in favor of #2037 (rebasing this proved messy and I no longer work for NR, so didn't want to use their fork as the basis for the PR)