[processor/transform] Add support for toggling scalar value types

[Mrod1598]

Is your feature request related to a problem? Please describe.
When collecting from prometheus, a value_type is assigned and sometimes incorrectly. Using this processor, it should be possible to toggle from double to int or the other way around in this processor.

Describe the solution you'd like
implementation of either the ability to use the set function to change it, or a new function to toggle it for a metric separate from the set function.

[TylerHelmuth]

@Mrod1598 the metrics context allows accessing (Get and Set) of a scalar value using value_double and value_int. You can update a NumberDataPoint's value using set. I added this test locally in metrics/processor_test.go and it passed

{
	query: []string{`set(value_int, 2) where value_double == 1.0`},
	want: func(td pmetric.Metrics) {
		td.ResourceMetrics().At(0).ScopeMetrics().At(0).Metrics().At(0).Sum().DataPoints().At(0).SetIntVal(2)
	},
},

[Mrod1598]

Got it thanks! is that documented somewhere that I missed?

[Mrod1598]

wait actually isn't that changing the value of the actual data point and not toggling the type? my scenario is where the value is stored as a double but should be stored as an int.

[TylerHelmuth]

Got it thanks! is that documented somewhere that I missed?

I think this is an instance where the README's statement of "everything can be accessed using the OTLP protobuf names" isn't completely honest. To handle how pdata represents the protobuf's requirements of value for NumberDataPoint the TQL had to make up a accessor and value_double and value_int were chosen. There are some other scenarios like that that should be improved in the README. In fact the whole README is getting kinda messy. I plan to address it with #11751.

wait actually isn't that changing the value of the actual data point and not toggling the type? my scenario is where the value is stored as a double but should be stored as an int.

pdata (what the Transform Processor is beholden to) doesn't have a concept of "change the value type without changing the value". pdata allows you to check the value type, but not set it. It allows you to set an int value (which updates the value type) and set a double value (which updates the value type)

For your scenario I tried:

set(value_int, value_double)

Which doesn't work because the float64 returned by value_double could not be asserted as an int64 during value_int's type assertion where it looks for an int64. So I actually don't think the TQL can handle this scenario right now bc it doesn't know to cast.

[TylerHelmuth]

I think we need a new Factory function that lets you cast to a Int. then we could do

set(value_int, Int(value_double))

[deepto98]

Can I pick this up?

[TylerHelmuth]

@deepto98 It's yours

[TylerHelmuth]

@mcdoker18 do you plan to update the transform processor with the new function?

[mcdoker18]

@TylerHelmuth sorry for the delay, I was on vacation :)

[bogdandrutu]

@TylerHelmuth qqs on this:

1. Why not using the lower letters for this? int()
2. Can the setter for the int_value be changed and do the cast in this case instead of asking user to do this?

[TylerHelmuth]

@bogdandrutu current naming guidelines are that Factory Functions be named with uppercase to differentiate from regular functions.

We could probably update setters to be smarter, checking the passed in value and seeing if it can be casted. That would be a more generic solution if it works.

But there might still be good reasons for a Factory Function like during comparison. I don't remember how many casting assumptions we make in there. Could also be usable when passing parameters to other functions.

The factory function is pretty flexible whereas the setter is only usable when the destination is involved with needing a type change.