[processor/k8sattributesprocessor] support regex capture groups in tag_name

[newly12]

Description:
support configure key prefix in k8sattributesprocessor

Link to tracking Issue:
#8844

Testing:

Documentation:

[newly12]

@pmm-sumo @dmitryax could you have a look at this PR?

[dmitryax]

Also please add documentation to the new capabilities

[dmitryax]

If we have formatter as a string with regexp caption e.g. k8s.namespace.annotations.$0, we can drop this condition along with the else block, right?

[newly12]

It seems to fully leverage $0 it has certain requirements for the regexp, which might lead to some breaking changes, so far basically the difference I found is how it behaviors between * and .*, e.g. https://go.dev/play/p/yUbTV_SKWCj

[dmitryax]

Sorry I don't understand your point. Can you elaborate please

[newly12]

$0 doesn't always represent the entire key, i.e. in https://go.dev/play/p/yUbTV_SKWCj, given the key is annotation1, name is annotations.$0,

• given the key_regex is an*, $0 would be ann and a(both matches the regexp), after 2 iterations(the for loop in the sample code), we got the result annotations.annannotations.a (annotations.ann + annotations.a).
• given the key_regex is an.*, $0 would be annotation1 as the matched string is the entire key, thus just one iteration and we got the expected result annotations.annotation1

[dmitryax]

This seems like an incorrect expansion logic. the result should not be composition of several matches.

[newly12]

Just wrapping a regexp supplied by user with ^ and $should do the trick

would it be tricky to wrap it with ^ and $, given that user may have ^ or $ in their regexp, ^ and $ probably has to be appended during validation phase, where we need to handle cases like

• ^an.*
• ^an.*$
• (^an.*)
• (^an.*$)

[dmitryax]

would it be tricky to wrap it with ^ and $, given that user may have ^ or $ in their regexp, ^ and $ probably has to be appended during validation phase, where we need to handle cases like

Yes, this would be the right approach. But let's not do it for now and keep this change as clean enhancement without breaking behavior

[newly12]

@dmitryax yeah the reason I noticed that an* is while making this change and noticed failures from current UT, which is expecting k8s.namespace.annotations.annotation1.

opentelemetry-collector-contrib/processor/k8sattributesprocessor/internal/kube/client_test.go

Lines 650 to 663 in 29dd412

	{
	name: "all-annotations",
	rules: ExtractionRules{
	Annotations: []FieldExtractionRule{{
	KeyRegex: regexp.MustCompile("an*"),
	From: MetadataFromNamespace,
	},
	},
	},
	attributes: map[string]string{
	"k8s.namespace.annotations.annotation1": "av1",
	},
	},
	}

[pmm-sumo]

But I still believe that we should do strict match and make an* do not match annotation1, only annnnnn. @pmm-sumo if you agree on this behavior, I believe we can introduce this breaking change as another PR.

Yeah, I have the same sentiment @dmitryax @newly12

[dmitryax]

Created a ticket #9716. @newly12 feel free to pick it up if you are interested

[newly12]

@dmitryax updated doc.

[dmitryax]

Please address other comments

[dmitryax]

LGTM