-
Notifications
You must be signed in to change notification settings - Fork 867
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
Idea: deprecate Config
, add agent-only InstrumentationConfig
#6264
Idea: deprecate Config
, add agent-only InstrumentationConfig
#6264
Conversation
String value = config.getString("otel.instrumentation.experimental.span-suppression-strategy"); | ||
if (value != null) { | ||
System.setProperty("otel.instrumentation.experimental.span-suppression-strategy", value); | ||
} |
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.
If there are distros setting the default value of this, we need to copy the value over to system properties so that instrumentation-api
code can get the correct value.
/** | ||
* TraceConfig Instrumentation does not extend Default. | ||
* | ||
* <p>Instead it directly implements Instrumenter#instrument() and adds one default Instrumenter for | ||
* every configured class+method-list. | ||
* | ||
* <p>If this becomes a more common use case the building logic should be abstracted out into a | ||
* super class. | ||
*/ |
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.
I found a super outdated comment 😄
@@ -34,5 +34,7 @@ public void onCommit(Map<TopicPartition, OffsetAndMetadata> offsets) {} | |||
public void close() {} | |||
|
|||
@Override | |||
public void configure(Map<String, ?> configs) {} | |||
public void configure(Map<String, ?> configs) { | |||
// TODO: support experimental attributes config |
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.
Later, in a separate PR, we should refactor this classes so that they use a similar way to configure themselves as introduced in #6138 -- it seems to be the "idiomatic" approach for kafka extensions, I guess
ConfigPropertiesUtil.getBoolean( | ||
"otel.instrumentation.aws-sdk.experimental-span-attributes", false)) |
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.
library-autoconfigure
modules have to keep on using env var/system prop configuration, as it's their only way of configuring themselves.
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.
This seems like a good approach until we have an opportunity to do something more radical with autoconfigure's config
Okay, I'll mark this PR as ready for review. There's quite a lot of changes to be done to deprecate |
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.
👍
7cdc80a
to
745ce4c
Compare
... and bridge
InstrumentationConfig
calls to SDK'sConfigProperties
. I tried drafting something that implements ideas from #6250, i.e.: makingConfig
/InstrumentationConfig
an internal, agent-only class.