[Metrics] Measure.absolute vs Gauge/Counter.monotonic

[markwolff]

From: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/api-metrics.md#measure

Currently monotonic and absolute accomplish almost the same things, but have different names based on if used in a Gauge/Counter or in a Measure. Could their naming be converged to reflect their overall similarities? E.g. remove absolute and use monotonic for all 3, or vice versa? Otherwise could we add some clarification on how they are different and are kept separate?

[dyladan]

Moved from PR discussion in JS SIG:

IMO absolute and monotonic don't mean the same thing at all. absolute means non-negative, monotonic means only counts up. An absolute, non monotonic measure may measure something like disk usage which can go up and down but never be below zero.

[jmacd]

The sum of an absolute measure is monotonic, but these terms definitely have different meaning. I would be happy to leave this open and try to improve the explanation of these terms.

[dyladan]

I still think they both should be in there. It seems to me monotonic implies absolute, but absolute does not imply monotonic:

component	monotonic	absolute
temperature (C)	no	no
cpu usage (%)	no	yes
processing duration (s)	yes	yes

Unless I am misunderstanding something.

[markwolff]

I am fine with both being in there. My issue is that each metric type only takes 1 of these options and so I am wondering if it would make sense to rename them s.t. the meanings are all merged (if such a word exists!), e.g. allowNegatives. If you think a new shared name would be more confusing for users, then this issue would be a no-op :)

[jmacd]

In the exporter interfaces for the Go SDK we use the term "Alternate" to describe the alternate behavior for each kind of instrument. It can't strictly be defined as "allow negatives" without contortions, saying e.g., that it refers to the change of a gauge but to the value of a counter and a measure. I recognize the cognitive trouble here, but I don't think consolidating on "monotonic" or "allow negatives" is really better. I'm open to a magical word that does better than "Alternate" though.

[dyladan]

I understand the motivation to consolidate into a single alternate flag in the export interface, but this only really matters when it is sent over the wire anyways (for instance when using a collector) where binary protocols like gRPC are typically used. In a binary protocol, removing a single boolean flag is so minor an optimization as to be almost negligible. You may also run into an issue in the future where you have the potential for something that requires both flags, or a new flag that is introduced.

I would argue for the increased readability and understandability of the interface to have both flags.

[jmacd]

I accept. This update will go into the SDK specification, since this is a matter related to the export interfaces. The currently open PR #347 is in flight, I will continue to work on it.

[jmacd]

These options were written out of the v0.3 specification.