Change the Agent API to wrap OpenTelemetry API/SDK instead of wrapping the existing internal model.

This should not require any changes to existing instrumentation, but will require changes to instrumentation tests which will need to validate now against (in-memory) OpenTelemetry Exporter.

This is an intermediate step. The end goal is for instrumentation to use OpenTelemetry API directly (#12).

Since OpenTelemetry API/SDK does not support the continuation feature from the existing Agent API, we can first no-op that part of the Agent API in order to limit changes to the instrumentation, and then come back after and remove that part of the Agent API completely in a subsequent PR. [the continuation feature was removed in #48]

I recently rebased one of my branches from the latest master. Looks like some new code from Datadog was pulled in. I haven't really looked at the details, but it appears that setting an IntegerRangeSet to null used to be a no-op. Pulling in the latest code from master, it appears that it tries to interpret null as a list of integers, which fails with the stack trace below. I think the problem may be in ConfiUtil::withConfigOverrride.

    10:26:54.549 [Test worker] WARN io.opentelemetry.auto.api.Config - Invalid config for http.client.error.statuses: 'null'. Must be formatted like '400-403,405,410-499'.
    10:26:54.549 [Test worker] WARN io.opentelemetry.auto.api.Config - Invalid configuration for http.client.error.statuses
    java.lang.NumberFormatException: null
        at io.opentelemetry.auto.api.Config.parseIntegerRangeSet(Config.java:474)
        at io.opentelemetry.auto.api.Config.getPropertyIntegerRangeValue(Config.java:429)
        at io.opentelemetry.auto.api.Config.<init>(Config.java:173)
        at sun.reflect.GeneratedConstructorAccessor19.newInstance(Unknown Source)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:80)
        at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:257)
        at io.opentelemetry.auto.test.utils.ConfigUtils.withConfigOverride(ConfigUtils.groovy:24)
        at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrap.invoke(StaticMetaMethodSite.java:131)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:100)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:224)
        at io.opentelemetry.auto.decorator.HttpClientDecoratorTest.$spock_feature_3_2(HttpClientDecoratorTest.groovy:94)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.spockframework.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:200)
        at org.spockframework.runtime.model.MethodInfo.invoke(MethodInfo.java:113)
        at org.spockframework.runtime.BaseSpecRunner.invokeRaw(BaseSpecRunner.java:484)
        at org.spockframework.runtime.BaseSpecRunner.invoke(BaseSpecRunner.java:467)
        at org.spockframework.runtime.BaseSpecRunner.runFeatureMethod(BaseSpecRunner.java:408)
        at org.spockframework.runtime.BaseSpecRunner.doRunIteration(BaseSpecRunner.java:322)
        at org.spockframework.runtime.BaseSpecRunner$6.invoke(BaseSpecRunner.java:306)
        at org.spockframework.runtime.BaseSpecRunner.invokeRaw(BaseSpecRunner.java:484)
        at org.spockframework.runtime.BaseSpecRunner.invoke(BaseSpecRunner.java:467)
        at org.spockframework.runtime.BaseSpecRunner.runIteration(BaseSpecRunner.java:285)
        at org.spockframework.runtime.BaseSpecRunner.initializeAndRunIteration(BaseSpecRunner.java:275)
        at org.spockframework.runtime.ParameterizedSpecRunner.runIterations(ParameterizedSpecRunner.java:139)
        at org.spockframework.runtime.ParameterizedSpecRunner.runParameterizedFeature(ParameterizedSpecRunner.java:41)
        at org.spockframework.runtime.BaseSpecRunner.doRunFeature(BaseSpecRunner.java:259)
        at org.spockframework.runtime.BaseSpecRunner$5.invoke(BaseSpecRunner.java:243)
        at org.spockframework.runtime.BaseSpecRunner.invokeRaw(BaseSpecRunner.java:484)
        at org.spockframework.runtime.BaseSpecRunner.invoke(BaseSpecRunner.java:467)
        at org.spockframework.runtime.BaseSpecRunner.runFeature(BaseSpecRunner.java:235)
        at org.spockframework.runtime.BaseSpecRunner.runFeatures(BaseSpecRunner.java:185)
        at org.spockframework.runtime.BaseSpecRunner.doRunSpec(BaseSpecRunner.java:95)
        at org.spockframework.runtime.BaseSpecRunner$1.invoke(BaseSpecRunner.java:81)
        at org.spockframework.runtime.BaseSpecRunner.invokeRaw(BaseSpecRunner.java:484)
        at org.spockframework.runtime.BaseSpecRunner.invoke(BaseSpecRunner.java:467)
        at org.spockframework.runtime.BaseSpecRunner.runSpec(BaseSpecRunner.java:73)
        at org.spockframework.runtime.BaseSpecRunner.run(BaseSpecRunner.java:64)
        at org.spockframework.runtime.Sputnik.run(Sputnik.java:63)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
        at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
        at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
        at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
        at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
        at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
        at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:412)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.lang.Thread.run(Thread.java:748)

Should use direct access to Opentelemetry APIs.

In some test cases, root spans are manually generated by calling activateSpan(startSpan("test"), true). We have been trying to replace that with the following sequence of statements:

def span = TEST_TRACER.spanBuilder("test").startSpan()
def scope = TEST_TRACER.withSpan(span)

This yields the following error:

assertTraces(1) { trace(0, 3) { span(0) { operationName "test" errored false parent() tags { } } span(1) { operationName "twilio.sdk" errored false tags { "$MoreTags.SERVICE_NAME" "twilio-sdk" "$MoreTags.RESOURCE_NAME" "api.v2010.account.MessageCreator.createAsync" "$MoreTags.SPAN_TYPE" SpanTypes.HTTP_CLIENT "$Tags.COMPONENT" "twilio-sdk" "$Tags.SPAN_KIND" Tags.SPAN_KIND_CLIENT "twilio.type" "com.twilio.rest.api.v2010.account.Message" "twilio.account" "AC14984e09e497506cf0d5eb59b1f6ace7" "twilio.sid" "MMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "twilio.status" "sent" } } span(2) { operationName "twilio.sdk" errored false tags { "$MoreTags.SERVICE_NAME" "twilio-sdk" "$MoreTags.RESOURCE_NAME" "api.v2010.account.MessageCreator.create" "$MoreTags.SPAN_TYPE" SpanTypes.HTTP_CLIENT "$Tags.COMPONENT" "twilio-sdk" "$Tags.SPAN_KIND" Tags.SPAN_KIND_CLIENT "twilio.type" "com.twilio.rest.api.v2010.account.Message" "twilio.account" "AC14984e09e497506cf0d5eb59b1f6ace7" "twilio.sid" "MMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "twilio.status" "sent" } } } }
    |
    groovy.lang.MissingMethodException: No signature of method: io.opentelemetry.sdk.trace.RecordEventsReadableSpan.call() is applicable for argument types: (Integer, test.TwilioClientTest$__spock_feature_2_7_closure13$_closure60$_closure61) values: [0, test.TwilioClientTest$__spock_feature_2_7_closure13$_closure60$_closure61@74e47365]
    Possible solutions: wait(), any(), end(), collect(), grep(), find()
        at test.TwilioClientTest.$spock_feature_2_7_closure13$_closure60(TwilioClientTest.groovy:679)
        at test.TwilioClientTest.asynchronous call(TwilioClientTest.groovy:677)

        Caused by:
        groovy.lang.MissingMethodException: No signature of method: io.opentelemetry.sdk.trace.RecordEventsReadableSpan.call() is applicable for argument types: (Integer, test.TwilioClientTest$__spock_feature_2_7_closure13$_closure60$_closure61) values: [0, test.TwilioClientTest$__spock_feature_2_7_closure13$_closure60$_closure61@74e47365]
        Possible solutions: wait(), any(), end(), collect(), grep(), find()
            at test.TwilioClientTest.$spock_feature_2_7_closure13$_closure60(TwilioClientTest.groovy:679)

Some things to rename:

• Change package names to io.opentelemetry.auto.*
• Change maven artifact groupId to io.opentelemetry.auto
• Remove or change dd- prefix on module names
• Remove or change DD prefix on class names

[as opposed to using an APM vendor's agent that wraps this project and embeds the vendor's exporter]

This is a bit tricky because the OpenTelemetry API and SDK that the agent use are shaded, so the exporter must be shaded as well to match.

There are (at least) two options for shading the user exporter:

• Provide a tool that end users can run to shade the OpenTelemetry exporter that they want to use
• Shade the OpenTelemetry exporter dynamically at runtime before loading it

Option to capture logs as events on the current span, instead of (or in addition to?) the current behavior of adding the trace and span ids to the logging output via MDC integration.

• log4j 1 (#181)
• log4j 2 (#182)
• logback (#183)
• java.util.logging (#175)

Preserving these files that are already in master:

• README.md
• LICENSE
• CODEOWNERS

And overwriting this file:

• .gitignore

Should use then Opentelemetry APIs.

The BaseDecorator needs some rework. In particular, I would like to address this:

• Better handling of the default tracer and removing the need to declare the tracer separately in each subclass.
• Add convenience methods for starting spans, creating scopes, injecting/extracting attributes etc.
• Add javadoc to all public methods.
• Remove redundant/unused methods.

Some details. Please comment if I'm getting this wrong.

• BaseDecorator::beforeFinish() doesn't do anything and there are no implementations in subclasses. I suggest we remove this method as it is called in the critical path of every interaction. If an instrumenter needs some specific handling of span finishing, it should (and already does) implement that directly.
• The code in BaseDecorator::afterStart() should be moved to the suggested new method BaseDecorator::beginSpan() eliminating a method call from most instrumenters.
• BaseDecorator::instrumentationNames() is never called and it's not clear whether it's needed. Should we remove?
• The entire idea of implementing specialized handling of instrumentation both by subclassing the decorator and by implementing specific functionality in Advice-methods feels a bit redundant and confusing to me. There was probably a really good and sound design idea behind this in the beginning, but it seems that, over time, many instrumenters are implemented according to different design principles. Putting this here as a topic for discussion.

Please assign this to me.

Many of the instrumenters are obtaining the parent(?) span by calling request.getAttribute(SPAN_ATTRIBUTE) on the request passed through the context to OnMethodEnter. Here is an example:

https://github.com/open-telemetry/opentelemetry-auto-instr-java/blob/1d474353a5ea310966d44e85ece4bbb75282ae70/java-agent/instrumentation/spring-webmvc-3.1/src/main/java/io/opentelemetry/auto/instrumentation/springweb/HandlerAdapterInstrumentation.java#L72

This attribute, however, contains an AgentSpan, which is not compatible with instrumenters refactored for the new APIs. Is there an alternative way of obtaining this span?

Should use direct access to Opentelementry APIs.

Some things we could probably share with contrib instrumentation:

• The decorator hierarchy
• HttpTextFormat Getters and Setters
• OkHttp3 interceptor
• MongoDB listener
• tests!

Remove functionality that should be delegated to the OpenTelemetry SDK / Exporters:

• Sampling (#17)
• Trace context propagation formats (#24)
• Service name split by tags (#20)
• Service name mappings (#23)
• Trace interceptors (#21)
• Exporter (#25)
• Report hostname (#31)
• Globally applied tags (#32, #42)
• Remove tag decorators (#33, #34, #36, #37, #38, #39)

It should use direct access to Opentelemetry APIs.

It should use direct access to Opentelemetry APIs.

Sampling should be delegated to the embedded (shaded or class loader isolated) OpenTelemetry SDK.

(The embedded SDK will be configurable by users via some TBD mechanism)

The netty test for connection refused is matching the error message including the server address. Since this is a hardcoded IPV4 address (127.0.0.1), it will not match when the OS decided that the connection should be set up over IPV6.

Continuations automatically keep the local root span open until all nested spans are finished, e.g. the duration of the trace below would be ~1 second, instead of the ~1 millisecond that it takes to return from the method.

@Trace
public Future<String> execute() {
    activeScope().setAsyncPropagation(true); // enables continuation support for this trace
    return executor.submit(() -> {
        Thread.sleep(1000);
        return "Hello!";
    });
}

It's a nice feature, but also brings significant complexity, so I think it's worth removing.

Also, there's no equivalent OpenTelemetry API feature, so this would require a special agent API, and then instrumentation that relied on this would further diverge from manual (contrib) instrumentation.

Should use the new API.

Please assign to @prydin

Things to clean up after updating to the next API/SDK release:

• remove all the null conditionals surrounding calls to setAttribute (done in #257)
• set attributes directly on the span builder where possible (instead of on the created span) (moved to #303)
• remove try catch blocks around HttpTraceContext::extract (probably need to do this and handle the API change at the same time as updating to the next API/SDK release) (done in #257)
• Various compilation errors, e.g. naming changes: Factory --> Provider (done in #257)
• Use the new SpanExporterFactory and Config interfaces (open-telemetry/opentelemetry-java#912) (done in #285)

The dropwizard tests fail to randomize the admin port and there's some ipv6/ipv4 confusion when calling the test endpoints.

The Span::setAttribute() method is commonly used in interceptors to copy attributes from an invocation to span attributes. This method will, by design, throw a NullPointerException if a null value is supplied. Given that many frameworks may treat certain attributes as optional, there's a chance that attributes with null values are present on the invocation objects.

The current implementation instrumenters/decorators are wrapping the calls to setAttribute() in null-checking if-statements whenever it is suspected that a null value may be supplied.

However, since the exact rules for which attributes may contain null aren't well documented for all frameworks, there's a high risk that a null-check is omitted by mistake, causing hard to find errors at runtime.

Should we implement a setAttributeOrNull() method that can be used when the presence of null values isn't known? Should we change the behavior of setAttribute()? What is the reason we don't allow null values in the first place? Could we change the behavior to make an assignment of a null value to an attribute a no-op?

See https://github.com/open-telemetry/opentelemetry-auto-instr-java/tree/dd-master/.circleci

Should use Opentelemetry APIs directly.

Hibernate instrumentation should use the Opentelemetry APIs directly.

See agent-jmxfetch.

JMX metrics likely make sense for this project, but this doesn't seem like the best starting point.

Throughout the code, there are some methods that get things but that don't have the getX naming pattern. I believe that pattern is used in the opentelemetry-java project, so we should follow the same standard. Examples are instrumentationNames(), component() and spanType().

If we have already made a decision to not use the getX-naming, please disregard and close this issue!

It should use direct access to Opentelemetry APIs.

Some instrumentation was commented out during the transition to OpenTelemetry API (#51 and #12). We need to figure out a way to bring these back.

• log4j1 (work moved to #133)
• log4j2 (work moved to #133)
• slf4j-mdc (work moved to #133)
• kafka-streams-0.11 (resolved in #109)
• aws-java-sdk-2.2 (resolved in #109)
• rabbitmq (resolved in #109)
• spring-webflux-5 (http client)

JAX-RS instrumentation was not commented out, but there was potentially some loss during the transition, as it previously used getLocalRootSpan() and now just uses the parent span, which makes all the same tests pass, but may have some impact in the real world.

• jax-rs-annotations-1
• jax-rs-annotations-2

I get this error message when trying to use the IntelliJ debugger to run test cases:

Exception in thread "main" org.spockframework.util.InternalSpockError: Failed to instantiate spec 'TwilioClientTest'
	at org.spockframework.runtime.BaseSpecRunner.createSpecInstance(BaseSpecRunner.java:110)
	at org.spockframework.runtime.BaseSpecRunner.run(BaseSpecRunner.java:62)
	at org.spockframework.runtime.Sputnik.run(Sputnik.java:63)
	at io.opentelemetry.auto.test.SpockRunner.run(SpockRunner.java:139)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of <bootloader>) previously initiated loading for a different type with name "io/opentelemetry/auto/instrumentation/api/AgentTracer$TracerAPI"
	at io.opentelemetry.auto.instrumentation.api.AgentTracer.<clinit>(AgentTracer.java:48)
	at io.opentelemetry.auto.test.AgentTestRunner.<clinit>(AgentTestRunner.java:85)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.lang.Class.newInstance(Class.java:442)
	at org.spockframework.runtime.BaseSpecRunner.createSpecInstance(BaseSpecRunner.java:104)
	... 8 more

This seems to be consistent across all test cases.

When running the unittests, some of the cassandra tests fail with the following error message.

> Task :java-agent:instrumentation:datastax-cassandra-3:test FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':java-agent:instrumentation:datastax-cassandra-3:test'.
> Process 'Gradle Test Executor 51' finished with non-zero exit value 1
  This problem might be caused by incorrect test process configuration.
  Please refer to the test execution section in the User Manual at https://docs.gradle.org/6.0.1/userguide/java_testing.html#sec:test_execution

The servlet instrumenter needs to comply to the new APIs, otherwise Servlet container instrumenters that rely on the SPAN_ATTR attribute won't work.

This will resolve #69 .

It should use direct access to OpenTelemetry APIs.

The reason behind this is to be able to use the same instrumentation in the future for both auto-instrumentation and whitebox instrumentation where possible.

Since instrumentation can be injected into any class loader (including the bootstrap class loader), the instrumentation's use of the OpenTelemetry API will need to be shaded, and the agent will need to provide a shaded version of the OpenTelemetry API in the bootstrap class loader.

This may have a downstream impact whether the OpenTelemetry SDK exporters need to be shaded (or at least partially shaded to match the API shading), but there are several options available to us here, including shading a user-supplied exporter at runtime if needed (vendors could shade their own exporter at compile time when bundling everything together).

Tracking modules as they are updated to use the OpenTelemetry API directly below.

If you want to work on one that has not already been updated, open an issue (e.g. #83, #84, #85) to let everyone know that you are going to work on it (to avoid two people working on the same one). Someone will assign it to you if you don't have rights to assign it to yourself.

See PRs #55, #67, #72, #75, #81, #87 to see how several of the modules have already been updated to use the OpenTelemetry API directly.

• akka-http-10.0
• apache-httpasyncclient-4
• apache-httpclient-4
• aws-java-sdk-1.11.0
• cdi-1.2
• couchbase-2.0
• couchbase-2.6
• datastax-cassandra-3
• dropwizard
• elasticsearch
• glassfish
• google-http-client
• grizzly-2
• grpc-1.5
• hibernate
• http-url-connection
• hystrix-1.4
• java-concurrent
• jax-rs-annotations-1
• jax-rs-annotations-2
• jax-rs-client-1.1
• jax-rs-client-2.0
• jboss-classloading
• jdbc
• jedis-1.4
• jedis-3.0
• jetty-8
• jms
• jsp-2.3
• kafka-clients-0.11
• lettuce-5
• mongo
• netty-4.0
• netty-4.1
• okhttp-3
• osgi-classloading
• play-2.4
• play-2.6
• play-ws-1
• play-ws-2
• play-ws-2.1
• ratpack-1.4
• reactor-core-3.1
• rmi
• rxjava-1
• servlet
• sparkjava-2.3
• spring-data-1.8
• spring-webflux-5
• spring-webmvc-3.1
• spymemcached-2.12
• tomcat-classloading
• trace-annotation
• twilio
• vertx

1. Remove functionality that should be delegated to the OpenTelemetry SDK / Exporters (#16) ✔️
   • The goal of doing this first is that it reduces the surface area that we have to work across during subsequent steps.
2. Remove OpenTracing interoperability (#6) ✔️
   • The goal of doing this next is to strip away the abstraction layer that it brings, and to further reduce the surface area, leaving behind only code that is used by the instrumentation.
3. Remove continuation feature (#48) ✔️
   • There's no equivalent OpenTelemetry API feature, so it will makes things easier if we remove this before switching over to OpenTelemetry API.
4. Change instrumentation to use OpenTelemetry API (indirectly) (#43) ✔️
   • This is a big milestone!
5. Rename package to io.opentelemetry.auto (#7) ✔️
6. Change instrumentation to use OpenTelemetry API directly (#12) ✔️
   • So we can start work on sharing code between auto and contrib instrumentation (#45)
7. Support the Jaeger exporter (#115) ✔️
   • After this, the project should be ready for end users to start testing!
8. Release v0.1.0

The current design for OpenTracing interoperability revolves around OpenTracing being in the bootstrap class loader, which leads to version conflicts.

I think it will be easier to remove everything that supports this interoperability, and start fresh with a new design for OpenTelemetry interoperability that will isolate us from version conflicts.

Current startup overhead on Azure App Service P1V2 instances (single core) is ~40 seconds.

Initial goal is to get this under 10 seconds in this environment.

And then we can open new issues for subsequent goals. We (Azure) eventually need to get this way under 10 seconds.

Remove dependencies to AgentSpan et al.

Maintainers: Please assign this to me!

Because of test hierarchy, probably easiest to do this once #12 is completed.

Should use Opentelemetry APIs directly.

spring-data, spring-webflux and spring-webmvc need refactoring to use the new APIs.

This is one of the fundamental requirements for this project.

From https://github.com/open-telemetry/oteps/blob/master/text/0001-telemetry-without-manual-instrumentation.md:

Explicit, whitebox OpenTelemetry instrumentation must interoperate with the “automatic” / zero-source-code-modification / blackbox instrumentation.

If the blackbox instrumentation starts a Span, whitebox instrumentation must be able to discover it as the active Span (and vice versa)

Relatedly, there also must be a way to discover and avoid potential conflicts/overlap/redundancy between explicit whitebox instrumentation and blackbox instrumentation of the same libraries/packages

That is, if a developer has already added the “official” OpenTelemetry plugin for, say, gRPC, then when the blackbox instrumentation effort adds gRPC support, it should not “double-instrument” it and create a mess of extra spans/etc

I will start and share a google doc in a few days to gather feedback on potential design for how this could work. Once we work out the design and get agreement, we'll move the design doc back into this repo (this issue? wiki? README.md? other?).