-
Notifications
You must be signed in to change notification settings - Fork 939
Add property to allow autoconfiguration of SDK telemetry version #8037
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| /* | ||
| * Copyright The OpenTelemetry Authors | ||
| * SPDX-License-Identifier: Apache-2.0 | ||
| */ | ||
|
|
||
| package io.opentelemetry.exporter.otlp.internal; | ||
|
|
||
| import io.opentelemetry.sdk.autoconfigure.spi.ConfigProperties; | ||
| import io.opentelemetry.sdk.autoconfigure.spi.ConfigurationException; | ||
| import io.opentelemetry.sdk.common.InternalTelemetryVersion; | ||
| import java.util.Locale; | ||
|
|
||
| /** | ||
| * Reads the desired SDK internal telemetry version from {@link ConfigProperties}. | ||
| * | ||
| * <p>This is the same as {@code io.opentelemetry.sdk.autoconfigure.InternalTelemetryConfiguration}. | ||
| * Any changes should be reflected there as well. | ||
| */ | ||
| final class InternalTelemetryConfiguration { | ||
|
|
||
| static InternalTelemetryVersion getVersion(ConfigProperties config) { | ||
| String version = config.getString("otel.experimental.sdk.telemetry.version"); | ||
| if (version == null) { | ||
| return InternalTelemetryVersion.LEGACY; | ||
| } | ||
|
|
||
| switch (version.toLowerCase(Locale.ROOT)) { | ||
| case "legacy": | ||
| return InternalTelemetryVersion.LEGACY; | ||
| case "latest": | ||
| return InternalTelemetryVersion.LATEST; | ||
| default: | ||
| throw new ConfigurationException("Invalid sdk telemetry version: " + version); | ||
| } | ||
| } | ||
|
|
||
| private InternalTelemetryConfiguration() {} | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,39 @@ | ||
| /* | ||
| * Copyright The OpenTelemetry Authors | ||
| * SPDX-License-Identifier: Apache-2.0 | ||
| */ | ||
|
|
||
| package io.opentelemetry.sdk.autoconfigure; | ||
|
|
||
| import io.opentelemetry.sdk.autoconfigure.spi.ConfigProperties; | ||
| import io.opentelemetry.sdk.autoconfigure.spi.ConfigurationException; | ||
| import io.opentelemetry.sdk.common.InternalTelemetryVersion; | ||
| import java.util.Locale; | ||
|
|
||
| /** | ||
| * Reads the desired SDK internal telemetry version from {@link ConfigProperties}. | ||
| * | ||
| * <p>This is the same as {@code | ||
| * io.opentelemetry.exporter.otlp.internal.InternalTelemetryConfiguration}. Any changes should be | ||
| * reflected there as well. | ||
| */ | ||
| final class InternalTelemetryConfiguration { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Too bad we need two copies of this code. Maybe each can have a note in the javadoc referencing the other to increase the chance of keeping changes in sync?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah added the references |
||
|
|
||
| static InternalTelemetryVersion getVersion(ConfigProperties config) { | ||
| String version = config.getString("otel.experimental.sdk.telemetry.version"); | ||
| if (version == null) { | ||
| return InternalTelemetryVersion.LEGACY; | ||
| } | ||
|
|
||
| switch (version.toLowerCase(Locale.ROOT)) { | ||
| case "legacy": | ||
| return InternalTelemetryVersion.LEGACY; | ||
| case "latest": | ||
| return InternalTelemetryVersion.LATEST; | ||
| default: | ||
| throw new ConfigurationException("Invalid sdk telemetry version: " + version); | ||
| } | ||
| } | ||
|
|
||
| private InternalTelemetryConfiguration() {} | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey I was thinking about internal telemetry and defaults more. Right now, we have SDK components which have different versions of internal telemetry according to their programmatic config API. For example,
SdkTracerProvider/SdkLoggerProvider/SimpleSpanProcessor/SimpleLogRecordProcessordid not emit any telemetry prior to the new semantic conventions, and so they default to the latest.BatchSpanProcessor,BatchLogRecordProcessor,Otlp{Signal}{Protocol}Exporterall emit legacy by default.That means that if
otel.experimental.sdk.telemetry.versionis omitted, or ifotel.experimental.sdk.telemetry.version=legacy, the SDK ends up emitting split brain telemetry.I think we need to address that here in and in #8045. My proposal:
otel.experimental.sdk.telemetry.versionis unspecified..instrumentation/development.java.otel_sdk.internal_telemetry_versionis unspecifiedBatchSpanProcessor,BatchLogRecordProcessor,Otlp{Signal}{Protocol}Exporter.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Metric names are just names, I don't know if there is any actual negative user impact from having inconsistent naming conventions in legacy mode, most commonly they wouldn't notice the new metrics, or appreciate them existing vs not (and maybe it gives a carrot for users to update to latest? ;) ). Agree that it feels a bit weird but not sure it's better to hide the new metrics to avoid the split brain. Should be simple to implement if we'd like that though.
To confirm, in the other PR we discussed it could be confusing if the default is different for the two config mechanisms but looks like we'd go for that. Does it mean we need to add
InternalTelemetryVersion.DISABLED?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See, I was thinking that omitting them from legacy would provide a carrot to update to latest 😂
I was imagining implementing this by calling
setMeterProviderwith a noop, to avoid adding InternalTelemetryVersion.DISABLED and having two ways to accomplish the same thing.Yes and I agree that its confusing. The crux for me right now is whether or not we are allowed to migrate declarative config to change the default in the future when semconv stabilizes. I know you made the argument that its reasonable to do so with sufficient lead time and easy config knobs, but right now the precedent for opentelemetry-java and for the broader opentelemetry project is that such a change is breaking and only allowed in major versions. I think that declarative config is likely to be the dominant config mechanism in the long term, and so the top priority for me is making sure that it doesn't carry around the legacy internal telemetry baggage indefinitely. Can accomplish this by:
Option 2 is a two way door. With option 1, the otel-java SIG needs to convince itself that this type of change is allowed, and we need to hope that the broader otel community doesn't come out with very explicit guidance to the contrary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, that's a much better carrot - reworked so the autoconfiguration knob now does not enable new metrics (by not setting a MeterProvider) when set to legacy, and made the default explicitly legacy instead of null.