-
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
Instrument SpanKey directly #5933
Conversation
instrumentation/opentelemetry-instrumentation-api/javaagent/build.gradle.kts
Outdated
Show resolved
Hide resolved
...main/java/io/opentelemetry/javaagent/instrumentation/instrumentationapi/SpanKeyBridging.java
Outdated
Show resolved
Hide resolved
...main/java/io/opentelemetry/javaagent/instrumentation/instrumentationapi/SpanKeyBridging.java
Show resolved
Hide resolved
// if you want to test them anyways, comment out "alpha" from the exclusions in AcceptableVersions.kt | ||
versions.set("[1.14.0-alpha,)") | ||
assertInverse.set(true) | ||
excludeInstrumentationModule("io.opentelemetry.javaagent.instrumentation.opentelemetryapi.OpenTelemetryApiInstrumentationModule") |
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 is my solution (for now at least) to #798
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's not pretty but...
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.
Instead of using class name, WDYT about using the instrumentation name? Most of them (or all; should be all) use the same name as gradle submodules, they're a lot shorter than the class names, and I suppose maybe consistent with how you disable instrumenations in runtime.
merging to move forward, but happy to revisit anything in here later on |
@@ -65,7 +67,9 @@ class MuzzleGradlePluginUtil { | |||
.invoke(null, userClassLoader, assertPass) | |||
as Map<String, List<Any>> | |||
|
|||
allMismatches.forEach { moduleName, mismatches -> | |||
allMismatches.filterKeys { | |||
!excludedInstrumentationModules.contains(it) |
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.
@mateuszrzeszutek were you thinking of instantiating the class it
here in order to check its instrumentation name? or were you thinking of suppressing the instrumentation ahead of time using the instrumentation name suppression?
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 was thinking on passing the set of excluded instrumentation names over to ClassLoaderMatcher
(which instantiates the InstrumentationModule
s) and excluding them there. I don't think that suppressing them ahead of time would work, we ignore the enabled flag in the muzzle plugin.
* Instrument SpanKey directly * feedback * Make muzzle work * Revert unrelated change
I think it makes sense to introduce
opentelemetry-instrumentation-api-shaded-for-instrumenting
so we can do full-blown instrumentation of the instrumentation-api.This allows moving
SpanKey
instrumentation out of the:instrumentation:opentelemetry-api:opentelemetry-api-1.0:javaagent
and into:instrumentation:opentelemetry-instrumentation-api:javaagent
.I will move instrumentation for
LocalRootSpan
andHttpRouteState
in a follow-up if this looks good.