feat: add support for MetricTypeSum

[perebaj]

Description

Prometheus translation rw2 add support for MetricTypeSum.

The current work was inspired by #36353

Link to tracking issue #33661

[dashpole]

Error: prometheusremotewrite/metrics_to_prw_v2.go:118:88: (*prometheusConverterV2).addSample - result 0 (*github.com/prometheus/prometheus/prompb/io/prometheus/write/v2.TimeSeries) is never used (unparam)
func (c *prometheusConverterV2) addSample(sample *writev2.Sample, lbls []prompb.Label) *writev2.TimeSeries {

[dashpole]

lgtm after lint errors are fixed

[perebaj]

I’m encountering inconsistent behavior with the TestFromMetricsV2 test case. It sometimes passes but fails at other times, even though I haven’t made any changes related to its functionality. I’m trying to understand what’s causing this issue...

[perebaj]

I finally identified the issue:

The test function func TestFromMetricsV2(t *testing.T) is executed twice. During the first execution, it processes a metric of type Sum (monotonic) and calls the addGaugeNumberDataPoints function. In the second execution, it processes a gauge metric, which also calls addGaugeNumberDataPoints.

When the addSample function is invoked, it relies on the c.symbolTable (line 120 below). This function assigns a numerical reference to each individual label.

For example, consider the following labels:

"series_name_1", "value-1", "series_name_2", "value-2", "__name__", "sum_1", "gauge_1"

First Execution
If the label order is:

series_name_1, value-1, __name__, sum_1, series_name_2, value-2

The corresponding map will look like this:

{
    series_name_1: 1,
    value-1: 2,
    __name__: 3,
    sum_1: 4,
    series_name_2: 5,
    value-2: 6
}

Thus, the LabelsRefs generated will be:

1, 2, 3, 4, 5, 6

Second Execution

Now, if the labels arrive in a different order, such as:

__name__, gauge_1

The updated map will become:

{
    series_name_1: 1,
    value-1: 2,
    __name__: 3,
    sum_1: 4,
    series_name_2: 5,
    value-2: 6,
    gauge_1: 9
}

the final LabelsRefs will be:

3, 9

The issue with the current approach is that the outcome of the second execution is directly influenced by the order of labels processed in the first execution. The simplest way that I found to address this, was sorting the labels before assigning the numerical reference. Is that makes sense?

opentelemetry-collector-contrib/pkg/translator/prometheusremotewrite/metrics_to_prw_v2.go

Lines 111 to 132 in 23117ab

	func (c *prometheusConverterV2) addSample(sample *writev2.Sample, lbls []prompb.Label) *writev2.TimeSeries {
	if sample == nil || len(lbls) == 0 {
	// This shouldn't happen
	return nil
	}
	buf := make([]uint32, 0, len(lbls)*2)
	var off uint32
	for _, l := range lbls {
	off = c.symbolTable.Symbolize(l.Name)
	buf = append(buf, off)
	off = c.symbolTable.Symbolize(l.Value)
	buf = append(buf, off)
	}
	ts := writev2.TimeSeries{
	LabelsRefs: buf,
	Samples: []writev2.Sample{*sample},
	}
	c.unique[timeSeriesSignature(lbls)] = &ts
	return &ts
	}

[dashpole]

Should the labels just be sorted before comparing in the test? If we aren't required to sort them for the protocol (or are we?), then we should probably avoid doing that?

[perebaj]

Should the labels just be sorted before comparing in the test? If we aren't required to sort them for the protocol (or are we?), then we should probably avoid doing that?

Taking a deep look into the places where we sort labels. We are already doing it inside addGaugeNumberDataPoints

opentelemetry-collector-contrib/pkg/translator/prometheusremotewrite/number_data_points_v2.go

Lines 24 to 32 in ab56d0a

	labels := createAttributes(
	resource,
	pt.Attributes(),
	settings.ExternalLabels,
	nil,
	true,
	model.MetricNameLabel,
	name,
	)

opentelemetry-collector-contrib/pkg/translator/prometheusremotewrite/helper.go

Line 139 in 5af8c70

sort.Stable(ByLabelName(labels))

but we are doing that before add the __name__ label name in the slice.

What do you recommend in this case? I'm not sure if it's possible to sort the labels before comparing in the test.