Skip to content

[receiver/prometheusreceiver] Allow for the alternate stringlabels implementation of labels to be usable #31907

@braydonk

Description

@braydonk

Component(s)

receiver/prometheus

Is your feature request related to a problem? Please describe.

In the Prometheus SDK, there is an alternate implementation of the labels.Labels type that uses a string with length encodings to represent a collection of labels instead of a slice. In my non-rigorous testing I saw some pretty reasonable improvements when stress testing a collector built with -tags=stringlabels.

However I don't mean for this issue to be an argument about whether or not this should be used/how. This issue is intended to be about how the current implementation of the Prometheus Receiver assumes labels.Labels to be a slice under the hood, making it so building with -tags=stringlabels is impossible.

Describe the solution you'd like

labels.Labels has a set of public methods that allows you to interact with it in the same way regardless of which implementation it's built with. I'd like to change the spots that make the slice assumption to use the public methods to an equivalent result.

This issue can be considered closed when it is possible to build a collector with this receiver using the stringlabels build tag.

Describe alternatives you've considered

No response

Additional context

I learned about this alternate implementation of labels and why it improves memory usage from this OpenObservability Day 2023 talk: https://www.youtube.com/watch?v=29yKJ1312AM

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions