[exporter/loadbalancing] Add metrics routing_key=attributes support

[ajimenez1503]

Description

Adds routing_key: attributes support for metrics in the loadbalancing exporter. Metrics are split by composite keys built from resource/scope/datapoint attributes, matching the routing_attributes list.

Link to tracking issue

Fixes #45675

Testing

Added unit test for attribute routing.

Documentation

Updated exporter/loadbalancingexporter/README.md to describe metrics attribute routing.

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib.

Important reminders:

• Please review our Contributing Guidelines.
• Don't forget to sign the Contributor License Agreement (CLA) if you haven't already.

A maintainer will review your pull request soon. Thank you for helping make OpenTelemetry better!

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ajimenez1503 / name: Antonio Jimenez (3982484)

[ajimenez1503]

Hey,
Could someone please approve and run the CI workflows?
Thanks :)

[MovieStoreGuy]

I've run the pipelines for you, and also removed the additional reviewers added by mistake.

[rlankfo]

Thanks for this PR. Looks good to me overall. I left a couple of comments but the issues are relatively minor although would like your input there.

[rlankfo]

We could consider adding a delimiter here when the strings are concatenated. If routing attributes are ["a", "b"] with values a="foo", b="bar", the key is "foobar". But a="foob", b="ar" also produces "foobar". These should deterministically hash to the same endpoint every time though, so the routing is still consistent even if there's incorrect grouping. Looks like the trace implementation behaves the same way though so it's probably not an issue, although could result in suboptimal load distribution.

[rlankfo]

Also, iiuc, I believe val.Str() will return "" for non-string attribute values. A routing key with int values that differ would always get the same routing key for example. Again, I believe this is also consistent with the trace implementation though.

[ajimenez1503]

Thanks for the careful review!

• Delimiter / collisions: agreed this can collide. I kept the behavior aligned with existing trace attribute routing (no delimiter, missing attrs skipped). I’ve opened a follow‑up issue [exporter/loadbalancing] Add stable encoding for attribute routing keys #46095 to introduce a stable encoding with delimiters.

• Non‑string values: good call. For metrics and traces is used Str(), which can return an empty string for non‑string values; I agree this needs a deterministic stringify across all value types and signals. I’ve opened a separate issue for it [exporter/loadbalancing] Define routing behavior for non-string attribute values #46094

I am interested on working on those issues.
Thanks :)

[ajimenez1503]

@open-telemetry/collector-contrib-approvers anything else here? Could you please merge it?
Thanks :)

[odubajDT]

Generally looks very good, one additional point: I would vote to add a validation function for the configuration to mitigate routing to the same backend:

// Validate checks if the exporter configuration is valid
func (c *Config) Validate() error {
	// Validate that routing_attributes is specified when using attribute routing
	if c.RoutingKey == attrRoutingStr && len(c.RoutingAttributes) == 0 {
		return fmt.Errorf("routing_attributes must be specified when routing_key is '%s'", attrRoutingStr)
	}

	// Warn if routing_attributes is specified but not using attribute routing
	// This is not an error, but the attributes will be ignored
	if c.RoutingKey != attrRoutingStr && c.RoutingKey != "" && len(c.RoutingAttributes) > 0 {
		return fmt.Errorf("routing_attributes is specified but routing_key is '%s' (expected '%s'); the routing_attributes will be ignored", c.RoutingKey, attrRoutingStr)
	}

	return nil
}

[ajimenez1503]

Thank your for the feedback. Quite welcome ;)

[ajimenez1503]

@open-telemetry/collector-contrib-approvers Could you please merge it?
Thanks :)

[atoulme]

Approved by codeowner, will merge once CI passes.

[otelbot]

Thank you for your contribution @ajimenez1503! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey. If you are getting started contributing, you can also join the CNCF Slack channel #opentelemetry-new-contributors to ask for guidance and get help.