RFC 0003, 0007 updates (Metrics measure type, metrics handle specification), RFC 0004 (configurable aggregation) deleted

[jmacd]

Updates to 0003 following work session 8/21/2019

Some content has been moved to a new RFC on metric handles.

This captures most of the discussion from the 8/21 meeting and mostly eliminates the need for RFC 0004.

[lzchen]

In summary, these are the agreements that this RFC addresses:

1. Agreement on context association across the metrics surface.
2. Agreement: Two diff interfaces - 1) For defining local labels 2) Metric operations
   getHandle(labels) -> return handle object
   handle.set() or handle.add()
3. Agreement: Call site variables can be supported by context tags
4. Agreement: All defined labels are captured in handles
   Unspecified values will be accepted but will not be treated as empty
5. Agreement: Context tags do not override handles tags
   Do not list remote tags for pre-aggregation (when you declare the metric)
6. Agreement: No support delta metric type. All type should support increments and decrements (AI: come up with names for a-c)
   Set can have the option to restrict values to increase
   Add can have the option to restrict to +ive values
   Record can have the option to be restricted to only +ive values
7. Agreement: Metric type will have default aggregation and will have the option of enabling them.
8. Agreement: Support Context-less Set (aka callbacks) for observing current value metrics (snapshots) (bullet 6,7 applies to 8)

Agreements that still need to be addressed:

1. Agreement: Supporting order based and non order based getHandle()
   Order based handles can throw exceptions: as determined by language
   Non-order based handles can fill-in unspecified-value automatically (point 4 in addressed)
2. Agreement: Provide transformer for external metrics provider like drop-wizzard (rather than callback observer). (details on this?)
3. Agreement: Resources are associated with SDK Manager, Component is associated with Tracer/Meter, metric name is unique per component (in prometheus exporter we would add component name as prefix).
4. Vector metrics? (prometheus)

@jmacd Feel free to edit if I'm missing anything!

[lzchen]

Looks good! I think we can address the other agreements maybe as edits to this RFC in the future once they are decided or simply push them up into the spec.

[songy23]

https://circleci.com/gh/open-telemetry/oteps/115?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

./text/0003-measure-metric-type.md:5:2: "Foreward" is a misspelling of "Foreword"
./text/0003-measure-metric-type.md:113:294: "whic" is a misspelling of "which"

Please fix. (make misspell-correction should fix the typos.)

[reyang]

Having gauge.GetHandle(...) seems to be okay.
Having a class/type named Handle could be confusing.

[jmacd]

In the Go prototype, there is indeed a Handle type but it's for internal use. The types returned by the GetHandle() methods in Go PR#100 are like Float64GaugeHandle, Int64CumulativeHandle. Is this sufficiently clear?

[jmacd]

I will revise this RFC again tomorrow with some of the outcome of today's metrics meeting. For now, I've allocated number 0007-metric-handle, making it precede 0008-metric-observer in PR#39.

[jmacd]

Update: It's been suggested that this PR is too long to be useful, and I would like to propose merging it in the current "proposed" state. I will immediately open another PR for further comments as I begin another round of updates regarding the LabelSet discussion yesterday.

@bogdandrutu