Do we intend to support non-number values for Gauges?

[bogdandrutu]

If yes, then I think we should change Gauge DataPoints to be a different message than "NumberDataPoint". That will allow us to diverge from Sum. This is not a breaking change for the wire protocol (neither proto nor json), but breaks things like collector pdata, etc.

I think we should make a decision asap here, so we don't block Collector Pdata 1.0 release.

[tigrannajaryan]

Do we intend to support non-number values for Gauges?

What non-number values are you envisioning? Things like enumerations to represent a state, e.g. (idle, running, stopped)? Or something else?

[jmacd]

I do not support non-numeric gauge points. There is an existing convention for "info" metrics from OpenMetrics which are 1-valued, where you may put all sorts of values as attributes.

[bogdandrutu]

@tigrannajaryan

Enums is an example, others may be "String" (i've seen this in stackdriver). I am not suggesting to do it, just want to make sure we understand the implication.

[pirgeo]

In the semantic conventions, we have been using an Attribute to solve the Enum use-case in the past. If we really need such a data type, we can always add it as a separate datatype in a non-breaking way later. My vote is to keep the gauge value number only.

[tigrannajaryan]

I think we should use attributes for such use cases. Alternatively, it should be an event (LogRecord). Yet another alternate is to record this as an Entity and its attribute (Entity is a possible future new signal type).

I am closing this as "won't do". Please feel free to reopen if you think we still need it.