Closed aknuds1 closed 3 months ago
Wonder you thought about this already, I think this could get more efficient if we sort the configured promote attributes when read from configuration once, then range on settings.PromoteResourceAttributes, append when incoming attribute exist in the settings.
@ying-jeanne what you gain by sorting the configured attributes to promote beforehand is to avoid sorting promotedAttrs
? You also have to make sure that the list of attributes to promote is unique though, this is why I range over resourceAttrs
instead. There should be relatively few attributes to promote (assuming a limit prevents the user from promoting too many), so I guess iterating over this list, after making sure it's unique, should be fast. By the same argument (relatively few attributes to promote), though, I don't think pre-sorting gives you anything.
You also have to make sure that the list of attributes to promote is unique though, this is why I range over resourceAttrs instead.
@ying-jeanne in retrospect I realize that it doesn't matter if the list of attributes has duplicates, since labels stemming from promoted attributes are only added if the label isn't already in the set. This is effectively deduplication.
I've pushed a revision optimizing the promotion loop, PTAL.
Closing in favour of upstream PR (already merged).
Add support to OTLP ingestion for promoting OTel resource attributes to labels.
We agreed to test this functionality in our Prom fork before proposing it upstream.