Add support for OpenTelemetry's service.namespace

[thecooldrop]

Add OTEL service attribute service.namespace. The value is set to same value as service.group currently. Since there is no specific environment variable to specify the service.namespace prescribed by OTEL, following chain is used to decide the value:

• management.opentelemetry.resource-attributes configuration property
• OTEL_RESOURCE_ATTRIBUTES environment variable
• If service.group is configured, then set it to same name
• Otherwise empty

Closes #44411

[nosan]

Thank you so much, @thecooldrop
I've left some comments for your consideration.

Please don't do anything until the Spring Boot team had a chance to review it.

I’ve opened #44494 to eliminate the duplications in OpenTelemetryAutoConfiguration and OtlpMetricsPropertiesConfigAdapter, consolidating everything in one place.

[nosan]

I think that instead of reusing the existing getApplicationGroup method, a new method,
getServiceNamespace, can be introduced. This would make it possible to mark the
existing method with the @Deprecated annotation and include appropriate javadoc.

private String getServiceNamespace(Environment environment) {
    return environment.getProperty("spring.application.group");
}
/**
 * @deprecated ...
 */
@Deprecated(since = "3.5.0", forRemoval = true)
private String getApplicationGroup(Environment environment) {
}

Using the @Deprecated annotation would make it easier to ensure that the
service.group property is deleted in future versions.

The same could be done in OtlpMetricsPropertiesConfigAdapter

[thecooldrop]

Makes sense. As per your note, will wait for input from Spring team.

[mhalbritter]

Thanks @nosan, i think that's a good idea.

[nosan]

It would be great to include a similar test in OpenTelemetryAutoConfigurationTests as well. Since OpenTelemetryAutoConfigurationTests already contains a test for checking service.group, you could potentially reuse that.

[thecooldrop]

I was looking for that in exactly that class, but somehow I missed it in the mass.

Thanks for pointing this out. I will add this.

[thecooldrop]

Given that entire logic for determining the attributes, which are included is now contained in OpenTelemetryResourceAttributes, I will place the tests only once in this class.

[thecooldrop]

There is a bit of a weird corner case. If service.group is populated via OTEL_RESOURCE_ATTRIBUTES env variable, and overrides spring.application.group configuration from Environment, then the question is if service.namespace should be populated from OTEL_RESOURCE_ATTRIBUTES as well, or from the service.application.group.

My expectation would be to populate it from service.application.group, as long as it is not listed in OTEL_RESOURCE_ATTRIBUTES

This choice is reflected in following test (note the similar, but different values for two entries):

	@Test
	void otelResourceAttributesShouldTakePrecedenceOverSpringApplicationGroupName() {
		this.environmentVariables.put("OTEL_RESOURCE_ATTRIBUTES", "service.group=spring-boot");
		this.environment.setProperty("spring.application.group", "spring-boot-app");
		assertThat(getAttributes()).hasSize(3)
			.containsEntry("service.name", "unknown_service")
			.containsEntry("service.group", "spring-boot")
			.containsEntry("service.namespace", "spring-boot-app");
	}

[mhalbritter]

Could you please also rebase your changes on top of main? There has been some changes to the OpenTelemetry variables handling.

[thecooldrop]

Could you please also rebase your changes on top of main? There has been some changes to the OpenTelemetry variables handling.

Done

[mhalbritter]

Thanks @thecooldrop !