Very basic Aggregation-configuration API in the SDK.

[jkwatson]

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

This first-cut 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

❗ No coverage uploaded for pull request base (master@d4583db). Click here to learn what that means.
The diff coverage is 53.70%.

@@            Coverage Diff            @@
##             master    #2037   +/-   ##
=========================================
  Coverage          ?   85.29%           
  Complexity        ?     2070           
=========================================
  Files             ?      235           
  Lines             ?     8013           
  Branches          ?      869           
=========================================
  Hits              ?     6835           
  Misses            ?      852           
  Partials          ?      326           

Impacted Files	Coverage Δ	Complexity Δ
...va/io/opentelemetry/sdk/metrics/ActiveBatcher.java	88.88% <0.00%> (ø)	5.00 <0.00> (?)
...o/opentelemetry/sdk/metrics/view/Aggregations.java	71.87% <0.00%> (ø)	4.00 <0.00> (?)
...in/java/io/opentelemetry/sdk/metrics/Batchers.java	53.84% <7.31%> (ø)	3.00 <0.00> (?)
...io/opentelemetry/sdk/metrics/MeterSdkProvider.java	94.44% <50.00%> (ø)	5.00 <1.00> (?)
...ava/io/opentelemetry/sdk/metrics/ViewRegistry.java	85.71% <85.71%> (ø)	5.00 <5.00> (?)
.../opentelemetry/sdk/metrics/AggregationChooser.java	95.34% <95.34%> (ø)	22.00 <22.00> (?)
...java/io/opentelemetry/sdk/trace/SpanProcessor.java	100.00% <0.00%> (ø)	2.00% <0.00%> (?%)
...elemetry/sdk/testing/assertj/AttributesAssert.java	97.43% <0.00%> (ø)	15.00% <0.00%> (?%)
.../propagation/B3PropagatorInjectorSingleHeader.java	100.00% <0.00%> (ø)	6.00% <0.00%> (?%)
.../main/java/io/opentelemetry/api/metrics/Meter.java	100.00% <0.00%> (ø)	1.00% <0.00%> (?%)
... and 231 more

---

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 d4583db...2f5862c. Read the comment docs.

[jkwatson]

If we want to go with this, I also need to write some unit tests. ;)

[anuraaga]

Mostly makes sense but I'm wondering why is this a best match? Shouldn't the aggregation configuration be more precise?

[jkwatson]

Well, I can imagine someone saying

1. By default, aggregate all ValueRecorders with MinMaxSumCount.
2. This particular ValueRecorder, named "http.request.latency"...that one I want Histograms for

So, "best match" will find the most precise selection and choose that, falling back to less precise ones. Is there a better name I could use?

[anuraaga]

I'd just name the method getAggregation and the loop can have a comment // See if user defined a specific configuration for this descriptor, the definition itself seems precise, not best-effort.

[anuraaga]

Comment is just a nit, LGTM. Is there more work on this PR?

[anuraaga]

I'd just name the method getAggregation and the loop can have a comment // See if user defined a specific configuration for this descriptor, the definition itself seems precise, not best-effort.

[jkwatson]

Comment is just a nit, LGTM. Is there more work on this PR?

If we think this is viable, I need to write a bunch of unit tests. I was holding off to get some feedback on the general approach before finishing that work.

[anuraaga]

Think you can use Objects.hashCode instead of your own null checks

[jkwatson]

I just had IDEA generate this code. Hate to mess with generated code in general.
We should document what we want to do with generated equals/hashcode/toString implementations, so we don't have to discuss it. :)

[jkwatson]

I'm going to merge, and we can iterate on this as we move forward with the metrics implementation.