API: Raw vs. other metrics / measurements are unclear

[yurishkuro]

Re-posting questions from open-telemetry/opentelemetry-java#226 (comment)

• in many other metrics APIs that allow recording gauges, timers, and/or histograms, the recording API is still about recording the raw measure, but behind the scene the library may or may not perform some form of aggregation, like LastValue for gauges, or Histogram for timers. So the distinction between raw measure and Gauge/Histogram is not clear to me, since from instrumentation point of view it's always recording the raw value.
• on the other hand, counters seem to be fundamentally different and can never be captured via raw measure, is that correct? This breaks the mental model for me.
• being able to change aggregation without touching instrumentation is great - I often wanted to see something like queue_length not as a gauge but as a histogram (incidentally tally didn't support histograms for non-timer values)
• application of request-scoped tags is also very tricky. As @bogdandrutu said, there are some stats that don't make sense to be labeled with request-scoped tags, e.g. CPU utilization. For measures where we do want to apply context tags, the ability to define views also provides a place to define context tag rules, potentially on a per-measure basis, e.g. "allow tags A and B for measureX, but only tag B for measure Y" (however, see next item).

[SergeyKanzhelev]

@yurishkuro is it somehting we need to finalize before API Complete milestone or we can change later?

[yurishkuro]

@SergeyKanzhelev I don't have a strong preference. I think improving metrics API is not in scope of v1, so I just wrote my concerns since I haven't used OpenCensus metrics API before, but it's not a blocker.

[SergeyKanzhelev]

deferring discussion for later

[jmacd]

@yurishkuro Can you clarify "counters seem to be fundamentally different and can never be captured via raw measure, is that correct?". I think in terms of a raw measurement being a simple numerical value. Whether we call something a count or a gauge depends on the aggregations that make sense. If you're thinking of something as a count, it means you intend to compute a sum or a rate, but you could meaningfully ask for a distribution of a count increments too.

[yurishkuro]

@jmacd that's fair

[tedsuo]

@yurishkuro I believe the new metric spec (#250) has changed significantly and addresses these issues. Can we close this issue?

[yurishkuro]

I suggest to mark the metrics spec PR as resolving this issue.

[jmacd]

I marked this as resolved in the corresponding OTEP but it doesn't show up in this repo.
See the bottom of https://github.com/open-telemetry/oteps/blob/master/text/0003-measure-metric-type.md
I'm not sure how else to "mark the PR" as resolving this issue, but happy to do so.

[yurishkuro]

I don't think you can auto-resolve issues from another repo. But the spec change is in the same repo so will auto resolve it

[jmacd]

To be clear, does this mean I should reference the issue from the spec somehow? Or is there a way to auto-resolve an issue from a GH PR?

…

On Mon, Oct 7, 2019 at 12:58 PM Yuri Shkuro ***@***.***> wrote: I don't think you can auto-resolve issues from another repo. But the spec change is in the same repo so will auto resolve it — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#83?email_source=notifications&email_token=AA3WFCO7H3POU4GXWG6MKVDQNOIFFA5CNFSM4HVX7PK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEARTJXA#issuecomment-539178204>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3WFCI6667RS53Q7HOW5Q3QNOIFFANCNFSM4HVX7PKQ> .

[yurishkuro]

In the PR description you can say "resolves ####" and the issue will be closed when PR is merged

[SergeyKanzhelev]

I believe it is resolved via #299