Support OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables #44394

nosan · 2025-02-21T12:18:31Z

This update introduces support for OTEL-specific environment variables. The behavior now aligns with OtlpMetricsPropertiesConfigAdapter, which automatically handles this through OtlpConfig.resourceAttributes.

The attribute order for OpenTelemetryResourceAttributes is as follows:

management.opentelemetry.resource-attributes
OTEL_RESOURCE_ATTRIBUTES and OTEL_SERVICE_NAME environment variables
Spring Environment 'spring.application.name' and 'spring.application.group' always apply if service.name and service.group are missing

See gh-43712

For consistency with OtlpMetricsPropertiesConfigAdapter, I do not merge attributes from management.opentelemetry.resource-attributes with attributes from environment variables.

https://github.com/nosan/spring-boot/blob/fdcc8d9d1f632f00dd71093d604c374b6d0a38d3/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/metrics/export/otlp/OtlpMetricsPropertiesConfigAdapter.java#L79-L87

nosan · 2025-02-22T10:26:14Z

Converted it to a draft until #44400 is resolved.

nosan · 2025-02-25T20:49:47Z

The PR has been updated, taking into account
#44400 (comment) and #43712 (comment)

This commit introduces the OpenTelementryAttributes class that fetches OTEL_RESOURCE_ATTRIBUTES and OTEL_SERVICE_NAME environment variables and merges it with user-defined resource attributes. Besides that, this commit includes spec-compliant proper handling of OTEL_RESOURCE_ATTRIBUTES in OtlpMetricsPropertiesConfigAdapter and OpenTelemetryAutoConfiguration. See spring-projectsgh-44394 Signed-off-by: Dmytro Nosan <[email protected]>

nosan · 2025-02-26T15:21:22Z

...pringframework/boot/actuate/autoconfigure/opentelemetry/OpenTelemetryResourceAttributes.java

+	 * @param value value to decode
+	 * @return the decoded string
+	 */
+	public static String decode(String value) {


I reviewed various SDKs, and each has a different approach to parsing OTEL_RESOURCE_ATTRIBUTES environment variable:

opentelemetry-dotnet: does not decode values at all.

opentelemetry-java: uses java.net.URLDecoder for decoding, where '+' is treated as a space (' ').

opentelemetry-python: decodes values the same way as the Java SDK.

opentelemetry-go: uses url.PathUnescape(strings.TrimSpace(v)) for decoding, treating '+' as a literal '+'.

I've not found information, that '+' should be decoded as a space (' ').

I was trying to implement parsing OTEL_RESOURCE_ATTRIBUTES environment variable based on the following:

OpenTelemetry Resource SDK

W3C

Yeah, the decoder looks dubious there.

as I know "implementation was borrowed from {@code org.apache.commons.codec.net.PercentCodec}". Reusing is always better then "borrowing".

stick to existing approach if it's not compromised yet. Replacing '+' to spaces seems to be simler then decoding. standardization makes life better. Might be java.net.URLDecoder

LeoTheDarvin

Russian lang is supported

LeoTheDarvin · 2025-02-26T15:46:28Z

...pringframework/boot/actuate/autoconfigure/opentelemetry/OpenTelemetryResourceAttributes.java

+	 * @param value value to decode
+	 * @return the decoded string
+	 */
+	public static String decode(String value) {


Yeah, the decoder looks dubious there.

as I know "implementation was borrowed from {@code org.apache.commons.codec.net.PercentCodec}". Reusing is always better then "borrowing".

stick to existing approach if it's not compromised yet. Replacing '+' to spaces seems to be simler then decoding. standardization makes life better. Might be java.net.URLDecoder

LeoTheDarvin · 2025-02-26T15:48:13Z

...project/spring-boot-docs/src/docs/antora/modules/reference/pages/actuator/observability.adoc

 If you have defined your own javadoc:io.opentelemetry.sdk.resources.Resource[] bean, this will no longer be the case.

 NOTE: Spring Boot does not provide auto-configuration for OpenTelemetry metrics or logging.
 OpenTelemetry tracing is only auto-configured when used together with xref:actuator/tracing.adoc[Micrometer Tracing].

+NOTE: The `OTEL_RESOURCE_ATTRIBUTES` environment variable consist of a list of key-value pairs. For example: `key1=value1,key2=value2,key3=spring%20boot`. All attribute values are treated as strings, and any characters outside the baggage-octet range must be **percent-encoded**.


Why encoding? Escaping seems more readable

Reference to specs is respectful.
But there're lots spesc prescribing opposite.

I think the following considerations should define what standard to follow:

What standard is already chosen and specified for our context(openTelemetry or Java)

What standard is more prefferable for guys reading(not writing) the attributes.

I'm not sure how https://docs.oracle.com/javase/specs/jls/se20/html/jls-3.html#jls-3.10.6 relates to this PR.
However, to clarify, I used the term "percent-encoded" instead of "escaped/escaping" or any other variation because, according to RFC 3986, it is named Percent-Encoding.

I wont insist on backslash-escaping. Let me just explain my point.

The guys who'll handle the variable are DevOps. DevOps would like to:

maintain the property unfomly for all applications(regardless lang)

use familiarsytax(less important)

As for the first, only a way to make the property format consistent throughout implementations is writing it in the official docs. Unfortunately the case is not documented there yet. So only a way is to predict the aspect relying on secondary considerations.

As for the second, it's valid to expect that DevOps teams would prefer to use standard CLI syntax conforming POSIX spec.

And my final argument for backslash-encoding.
Properties from environment variables could be overriden with configuration(json, yaml) or a string variable.
And surprizingly JSON, YAML and majority of langs are following backslash-escaping pattern.

Unfortunately the case is not documented there yet.

https://opentelemetry.io/docs/specs/otel/resource/sdk/#specifying-resource-information-via-an-environment-variable

I mean no disrespect and I could be mistaken but from my perspective, the responses seem auto-generated. With that said, I will stop responding to further comments and wait for feedback from the Spring Boot team. Thank you anyway.

Now see. Thx, you're right

LeoTheDarvin · 2025-02-26T15:55:09Z

...springframework/boot/actuate/autoconfigure/opentelemetry/OpenTelemetryAutoConfiguration.java

-		properties.getResourceAttributes().forEach(builder::put);
+		Map<String, String> attributes = new OpenTelemetryResourceAttributes(properties.getResourceAttributes())
+			.asMap();
+		attributes.computeIfAbsent("service.name", (key) -> getApplicationName(environment));


"service.name" is declared in OpenTelemetryResourceAttributes too.
Better to reuse a public constant from OpenTelemetryResourceAttributes.
Even better to reuse a constant from opentelemetry SDK.

For "service.group" the same note

LeoTheDarvin · 2025-02-26T15:57:40Z

...springframework/boot/actuate/autoconfigure/opentelemetry/OpenTelemetryAutoConfiguration.java

 		return builder.build();
 	}

+	private String getApplicationName(Environment environment) {
+		return environment.getProperty("spring.application.name", DEFAULT_APPLICATION_NAME);


Consider using a @value(${}) variable.
For "spring.application.group" too

The use of @Value(${..}) is uncommon in the Spring Boot codebase. Since we already have access to the Environment here, it is better to use it.

LeoTheDarvin · 2025-02-26T16:02:05Z

...framework/boot/actuate/autoconfigure/opentelemetry/OpenTelemetryResourceAttributesTests.java

+ *
+ * @author Dmytro Nosan
+ */
+class OpenTelemetryResourceAttributesTests {


If you're going to decode parameters from "%a3%3e"-like expression still need a test case

I have also included tests for this use case.

LeoTheDarvin · 2025-02-26T16:13:03Z

...ework/boot/actuate/autoconfigure/metrics/export/otlp/OtlpMetricsPropertiesConfigAdapter.java

-		result.computeIfAbsent("service.name", (key) -> getApplicationName());
-		result.computeIfAbsent("service.group", (key) -> getApplicationGroup());
-		return Collections.unmodifiableMap(result);
+		Map<String, String> attributes = new OpenTelemetryResourceAttributes(


Exact copy of config from OpenTelemetryAutoConfiguration. Consider reuse

LeoTheDarvin · 2025-02-26T16:29:12Z

...rg/springframework/boot/actuate/autoconfigure/metrics/export/otlp/OtlpMetricsProperties.java

@@ -95,17 +94,6 @@ public void setAggregationTemporality(AggregationTemporality aggregationTemporal
 		this.aggregationTemporality = aggregationTemporality;
 	}

-	@Deprecated(since = "3.2.0", forRemoval = true)


Do the "resource-attributes" have something to do with the issue? Why remove here?
Why not remove the property together?

This property has been deprecated since 3.2.0 and is scheduled for removal in 3.5.0. As I am making some changes in OtlpMetricsPropertiesConfigAdapter, I believe it is appropriate to remove this property entirely now.

Thanks for spotting this old deprecated code, @nosan. Given its deprecation in 3.2, it should have been removed in 3.4 but we must have missed it. I'd like it to be handled separately and I've opened #44468. I'll take care of it shortly. I hope rebasing on top of that change won't cause too much trouble.

Given its deprecation in 3.2, it should have been removed in 3.4

Oops, I've been thinking in 3.5.0 🤦

This commit introduces the OpenTelementryAttributes class that fetches OTEL_RESOURCE_ATTRIBUTES and OTEL_SERVICE_NAME environment variables and merges it with user-defined resource attributes. Besides that, this commit includes spec-compliant proper handling of OTEL_RESOURCE_ATTRIBUTES in OtlpMetricsPropertiesConfigAdapter and OpenTelemetryAutoConfiguration. See spring-projectsgh-44394 Signed-off-by: Dmytro Nosan <[email protected]>

This commit introduces the OpenTelementryAttributes class that fetches OTEL_RESOURCE_ATTRIBUTES and OTEL_SERVICE_NAME environment variables and merges it with user-defined resource attributes. Besides that, this commit includes spec-compliant proper handling of OTEL_RESOURCE_ATTRIBUTES in OtlpMetricsPropertiesConfigAdapter and OpenTelemetryAutoConfiguration. See gh-44394 Signed-off-by: Dmytro Nosan <[email protected]>

See gh-44394

mhalbritter · 2025-02-28T13:55:28Z

Thanks a lot @nosan !

spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 21, 2025

nosan force-pushed the 43712 branch 2 times, most recently from f84e68e to 5fdf53a Compare February 21, 2025 12:28

nosan marked this pull request as draft February 22, 2025 10:26

nosan force-pushed the 43712 branch 5 times, most recently from 4c0e932 to e27117b Compare February 25, 2025 20:45

nosan marked this pull request as ready for review February 25, 2025 20:45

nosan force-pushed the 43712 branch 6 times, most recently from eb0a823 to 573e67b Compare February 26, 2025 09:57

nosan force-pushed the 43712 branch from 573e67b to 60f5f29 Compare February 26, 2025 10:16

nosan force-pushed the 43712 branch from 60f5f29 to 575f721 Compare February 26, 2025 10:23

nosan force-pushed the 43712 branch from 575f721 to 413e7ab Compare February 26, 2025 14:08

nosan force-pushed the 43712 branch from 413e7ab to 925599a Compare February 26, 2025 14:24

nosan force-pushed the 43712 branch from 925599a to 9aca690 Compare February 26, 2025 14:25

nosan force-pushed the 43712 branch from 9aca690 to 590c024 Compare February 26, 2025 14:47

nosan force-pushed the 43712 branch from 590c024 to 583cc66 Compare February 26, 2025 15:01

nosan commented Feb 26, 2025

View reviewed changes

LeoTheDarvin reviewed Feb 26, 2025

View reviewed changes

nosan force-pushed the 43712 branch from 583cc66 to a6c0d1a Compare February 26, 2025 16:59

nosan force-pushed the 43712 branch from a6c0d1a to cd6dbd7 Compare February 26, 2025 17:03

wilkinsona mentioned this pull request Feb 27, 2025

Remove support for management.otlp.metrics.export.resource-attributes that has been deprecated since 3.2 #44468

Closed

nosan force-pushed the 43712 branch from cd6dbd7 to a8761c7 Compare February 27, 2025 21:28

mhalbritter mentioned this pull request Feb 28, 2025

Add support for OpenTelemetry's service.namespace #44411

Open

mhalbritter self-assigned this Feb 28, 2025

mhalbritter mentioned this pull request Feb 28, 2025

Support OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables #43712

Closed

mhalbritter changed the title ~~Add Support for OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES Environment Variables~~ Support OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables Feb 28, 2025

mhalbritter added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Feb 28, 2025

mhalbritter added this to the 3.5.x milestone Feb 28, 2025

mhalbritter added a commit that referenced this pull request Feb 28, 2025

Polish "Add support for OTel-specific environment variables"

8f4e051

See gh-44394

mhalbritter closed this in e886785 Feb 28, 2025

mhalbritter modified the milestones: 3.5.x, 3.5.0-M3 Feb 28, 2025

nosan mentioned this pull request Feb 28, 2025

Refine the handling of OpenTelemetry resource attributes #44494

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables #44394

Support OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables #44394

nosan commented Feb 21, 2025 •

edited

Loading

nosan commented Feb 22, 2025

nosan commented Feb 25, 2025

nosan Feb 26, 2025 •

edited

Loading

LeoTheDarvin Feb 26, 2025

LeoTheDarvin left a comment

LeoTheDarvin Feb 26, 2025

LeoTheDarvin Feb 26, 2025

nosan Feb 27, 2025

LeoTheDarvin Feb 27, 2025

nosan Feb 27, 2025

LeoTheDarvin Feb 27, 2025

nosan Feb 27, 2025

LeoTheDarvin Feb 27, 2025

LeoTheDarvin Feb 26, 2025

LeoTheDarvin Feb 26, 2025

nosan Feb 27, 2025

LeoTheDarvin Feb 26, 2025

nosan Feb 27, 2025

LeoTheDarvin Feb 26, 2025

LeoTheDarvin Feb 26, 2025

nosan Feb 27, 2025

wilkinsona Feb 27, 2025

nosan Feb 27, 2025

mhalbritter commented Feb 28, 2025

Support OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables #44394

Support OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables #44394

Conversation

nosan commented Feb 21, 2025 • edited Loading

nosan commented Feb 22, 2025

nosan commented Feb 25, 2025

nosan Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LeoTheDarvin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mhalbritter commented Feb 28, 2025

nosan commented Feb 21, 2025 •

edited

Loading

nosan Feb 26, 2025 •

edited

Loading