Stricter matches for RuleBasedRoutingSampler

[iNikem]

I have just discovered that RuleBasedRoutingSampler uses Matcher.find method to decide if given span attribute matches rule's pattern, as opposed to Matcher.matches(). The difference is that the former "looks for a substring matching given pattern" and the latter "matches whole input sequence". E.g.

Pattern.compile("/front").matcher("http://localhost:1234/front").finds() == true
Pattern.compile("/front").matcher("http://localhost:1234/front").matches() == false

For some reason I was under impression from the discussion of #70 that we wanted to have a behaviour of matches, not that of the finds. Although I feel that finds is more user friendly. Should we change it or not?

@anuraaga @jkwatson

[jkwatson]

I think the "looks for a substring matching the given pattern" is going to be more useful, especially since the hostname may not be known at compile time.

[anuraaga]

Another issue is that the performance of find can be ok but isn't that great, compared to exact match or prefix match. The annoyance of adding the wildcard at least makes it more obvious what is happening to performance.

Though we had also consider restricting to a glob language instead of regex. That seems good to me too, but would need to require wildcards to allow exact match. What do you think about glob syntax?

[iNikem]

Globs may be faster, but UX question still remains. What is the common case: substring or exact match? I really don't think that forcing users to always add * (or .*) around the pattern is a good idea.

[trask]

I tend to find full matching slightly less surprising, but I don't think there's a clear winner

does anyone know if the collector regex attribute processors use full or substring matching? that could be worth aligning with, especially when it comes to pushing this to the spec

re: glob vs regex, I'm slightly pro regex "just in case", but globs could be better for consistent cross-language support

(sorry to have no helpful opinions or answers 😂)

[iNikem]

I reviewed once more semantic attributes for incoming http requests.

The following attributes most probably will need exact match: method, host, scheme.

The following attributes most probably will need substring match: url, target, route, user agent.

I suspect that nobody will actually use this sampler with attributes from the first group. Only from the second. Thus the common use case will be substring match. Thus I will leave current implementation as is.

[anuraaga]

Matching behavior of collector is a nice benchmark - collector uses find too