feat: dynamically named usage groups

[aleks-p]

Adds a special meaning to usage groups with placeholders (${labels.label_name}) in their names. When encountered AND there is a match with the provided selector, we replace placeholders with the actual label values.

This allows for a simpler and more powerful configuration of usage groups where this:

    distributor_usage_groups:
      cart-service: '{service_name="cart-service"}'
      user-service: '{service_name="user-service"}'
      order-service: '{service_name="order-service"}'

can be replaced with:

    distributor_usage_groups:
      '${labels.service_name}': '{}'

Benchmark results:

go test -bench=BenchmarkUsageGroups -benchmem ./pkg/validation
goos: darwin
goarch: arm64
pkg: github.com/grafana/pyroscope/pkg/validation
cpu: Apple M2 Pro
BenchmarkUsageGroups_Regular-10            	12253587	        93.08 ns/op	      80 B/op	       1 allocs/op
BenchmarkUsageGroups_Dynamic-10            	 4551181	       265.0 ns/op	     200 B/op	       6 allocs/op

Notes:

• Both styles of usage groups can co-exist (though if there is overlap, attribution would count towards all groups)

[simonswine]

Not 100% sure myself yet if I like it. It obviously is pretty aligned with label selectors.

I also could think something more like ${label.service_name} could be quite nice, but then that's something completely different to the label selector.

Edit: Forgot to say: Plus 100 to the feature itself, the current feature is not really usable, esp. as long as its not self service.

[aleks-p]

Not 100% sure myself yet if I like it. It obviously is pretty aligned with label selectors.
I also could think something more like ${label.service_name} could be quite nice, but then that's something completely different to the label selector.

Named placeholders are arguably safer than positional ones. I also think it can fit the usage group model as well, the label selector would be used purely for filtering / segmentation (like today), while the name can be independently controlled, e.g.:

"${label.service_name}": "{}"

I will try this and see how it looks / feels.

[aleks-p]

Switched to named placeholders now. One added benefit is that we can now pre-parse the placeholders (once when the config is read) and can apply it more efficiently. The added overhead decreased quite a bit compared to using regex capture groups.

[kolesnikovae]

Just in case: have we considered adding another internal/private label, like __usage_group, to be used in conjunction with relabeling rules?

This would:

• Unify the different implementations
• Allow users to explicitly specify usage groups
• Simplify everything significantly

As I understand it, relabeling rules should be able to do everything that both the proposed and current implementations can do. In 99.(9)% of cases, it's just a simple mapping from service_name.

[aleks-p]

Just in case: have we considered adding another internal/private label, like __usage_group, to be used in conjunction with relabeling rules?

This would:

• Unify the different implementations
• Allow users to explicitly specify usage groups
• Simplify everything significantly

As I understand it, relabeling rules should be able to do everything that both the proposed and current implementations can do. In 99.(9)% of cases, it's just a simple mapping from service_name.

@kolesnikovae that is an interesting idea. It can work for simpler cases (like the service_name example) but usage groups can and often span multiple dimensions. E.g., a profile can contribute towards the usage statistics for a service, environment, team/department. A single label wouldn't work for this. We could bend the relabelling rules system to accommodate this, but ultimately it serves a different purpose.

[simonswine]

While I agree with Anton's sentiment that this is very close to relabelling rules, I do think we decided to go down this slightly separate route and this an enhancement, which is essential to make the feature usable without developing further automation (like a cron listing service_name and creating usage groups on the back of that).

LGTM