-
Notifications
You must be signed in to change notification settings - Fork 965
Span kind for method instrumentation / Declarative configuration tooling #14014
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?
Span kind for method instrumentation / Declarative configuration tooling #14014
Conversation
@laurit I hope this makes sense 😄 |
my preference would be for the method instrumentation to support declarative config, and only support this (and other) new features via declarative config instead of trying to encode more things into but I realize that is probably quite a bit more effort |
Yeah - that's a good point. If declarative config was ready to go, then I'd be happy to add it there. |
do you know what's missing that we still need? it feels like we're super close, maybe we could use this to motivate getting the final pieces in place? |
This is the error I get locally: The deadlock should have been avoided using https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/muzzle/src/main/java/io/opentelemetry/javaagent/tooling/TransformSafeLogger.java
|
@laurit can you help with fixing the test? I get this deadlock (see above) locally - and in GH actions there's no output:
|
Root cause: in memory exporters are not injected with config file. |
@jack-berg can you check if this integration makes sense? |
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.
Seems like the right approach to me!
instrumentation/methods/javaagent/src/declarativeConfigTest/resources/declarative-config.yaml
Outdated
Show resolved
Hide resolved
instrumentation/development: | ||
java: | ||
methods: | ||
include: |
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.
👍
.collect(Collectors.toList()); | ||
} | ||
|
||
private static Stream<MethodInstrumentation> parseMethodInstrumentation( |
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.
👍 looks about right.
I wish there was an easier way to parse the config that didn't rely on jackson
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.
It would help to define a schema for validation and auto-completion. Is there a way to do that (as a follow-up)?
@jaydeluca FYI
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.
How / where would you propose that schema is defined? And what tooling would interpret that schema and parse config to that representation?
I have some ideas on this of course, but think / hope this can be driven by instrumentation.
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.
BTW - added this to the SIG meeting agenda
How / where would you propose that schema is defined?
generated based on data from SDK and instrumentation
@jaydeluca is already working in extracting config options (and other metadat) from the java agent
And what tooling would interpret that schema and parse config to that representation?
yaml editors would consume this - as a special case, the spring boot editor already has a file format: https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/spring/spring-boot-autoconfigure/src/main/resources/META-INF/additional-spring-configuration-metadata.json
hope this can be driven by instrumentation
probably - since it's instrumentation specific
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.
Created #14082
24bdfa3
to
63bfcbf
Compare
@@ -13,7 +13,7 @@ group = "io.opentelemetry.instrumentation" | |||
dependencies { | |||
api("io.opentelemetry.semconv:opentelemetry-semconv") | |||
api(project(":instrumentation-api")) | |||
implementation("io.opentelemetry:opentelemetry-api-incubator") | |||
api("io.opentelemetry:opentelemetry-api-incubator") |
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.
63bfcbf
to
02fb7b6
Compare
From the stack trace I'd guess that there is an exception thrown from advice code that is applied to |
...eclarativeConfigTest/java/io/opentelemetry/javaagent/instrumentation/methods/MethodTest.java
Show resolved
Hide resolved
.../src/main/java/io/opentelemetry/javaagent/instrumentation/methods/MethodInstrumentation.java
Outdated
Show resolved
Hide resolved
...avaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/methods/MethodsConfig.java
Outdated
Show resolved
Hide resolved
...ain/java/io/opentelemetry/javaagent/instrumentation/methods/MethodInstrumentationModule.java
Outdated
Show resolved
Hide resolved
@trask I think we can remove this from 2.17 milestone. As it is the declarative configuration isn't fully functional with the agent anyway. |
well - it should be fully functional with this PR - but there's no need to rush |
@laurit can you check again? |
a0f980d
to
7a819f7
Compare
.../src/main/java/io/opentelemetry/javaagent/instrumentation/methods/MethodInstrumentation.java
Outdated
Show resolved
Hide resolved
@laurit can you check again? |
List<TypeInstrumentation> list = | ||
methods != null ? MethodsConfig.parseDeclarativeConfig(methods) : parseConfigProperties(); | ||
if (list.isEmpty()) { | ||
return Collections.singletonList(new MethodInstrumentation(null, Collections.emptyMap())); |
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 think there should be a comment here elaborating whey we are doing it.
Also I thought maybe it would be nicer if instead of Map<String, SpanKind>
we'd use Map<SpanKind, Collection<String>>
. Tried it out in
zeitlinger#6 wdyt?
Brings parity to
@WithSpan
where you can configure the span kind.Syntax example:
https://github.com/zeitlinger/opentelemetry-java-instrumentation/blob/3db95b4e48b527fa6f0c09be8c4cba8614951d99/instrumentation/methods/javaagent/build.gradle.kts#L18