Loadable initializer

[anuraaga]

Currently, it is possible to load an exporter in the agent by passing a jar

https://github.com/open-telemetry/opentelemetry-auto-instr-java/blob/master/agent-tooling/src/main/java/io/opentelemetry/auto/tooling/TracerInstaller.java#L56

It would be nice if this could be made more general by executing a generic initializer so a vendor could configure the agent to optimize the experience. For example, for xray we'd like to customize IdsGenerator and Propagation along with SpanExporter. Currently I don't think the former are customizable at all, and having separate customization points for each works ok too, ideally we could have a single entrypoint so users don't have to set as many system properties.

[anuraaga]

387 is probably also related, while xray hasn't quite gotten to diving into sampling we'll need to hook that into our centralized sampling eventually as well. I guess the theme is OpenTelemetrySdk is very pluggable, but we currently don't have a good way to take advantage of that in the agent.

[anuraaga]

I did some prototyping and was able to come up with a way to hack into SPI by adding to the bootstrap classpath

https://github.com/aws-samples/aws-xray-sdk-with-opentelemetry-sample/blob/both-otel-and-xray/awsagentprovider/build.gradle.kts https://github.com/aws-samples/aws-xray-sdk-with-opentelemetry-sample/blob/both-otel-and-xray/frontend/Dockerfile#L44

This approach doesn't do any classpath isolation so isn't a very good idea, but as a PoC it seems to be working. Adding too many dependencies to that project would likely break the app though :)

Some thoughts from this experiment, since OpenTelemetry already provides SPI for overriding the tracer implementation, there may not be a need for yet another SPI in the agent itself. Presumably, if the agent loaded my jar into the agent classloader, it would work as effectively as the current bootstrap classpath augmentation without polluting the app.

The main downside is creating this jar isn't easy due to needing to know the shading requirements of the agent. Not using the normal OpenTelemetry SPI may allow hiding this from implementers, but I'm not too sure of that either.

Hope this info helps, if we decide on a direction on how to add more customization, I'd be happy to help implement.

[anuraaga]

Oops - @trask maybe want to reopen this since that PR is just a prototype for now (and looks like you need write permission to reopen an issue, didn't know that!)

[trask]

Oh wow I didn't realize that an issue author couldn't re-open an issue if it was closed by someone else either (https://github.com/isaacs/github/issues/583)!

[anuraaga]

With the agent on jfrog now, (and the fresh off the oven exporter SPI, thanks!) I was able to set up a nice agent repackaging setup here

https://github.com/aws-samples/aws-xray-sdk-with-opentelemetry-sample/blob/both-otel-and-xray/otelagent/src/main/java/com/softwareaws/xray/opentelemetry/agentbootstrap/AwsAgentBootstrap.java

Just 3 lines of real code, more of it is Gradle

https://github.com/aws-samples/aws-xray-sdk-with-opentelemetry-sample/blob/both-otel-and-xray/otelagent/build.gradle.kts

Command to run a binary now is a much simpler set of flags https://github.com/aws-samples/aws-xray-sdk-with-opentelemetry-sample/commit/02f796cf132dd53b5168b02112d6bc899407836f#diff-532a2baa536d096a6bdd1b0483d0b920

This works very well because

• We have a single file with the agent and our configuration bundled together
• We can still publish the separate initializer too for users that choose to use the upstream agent and configure it themselves

[iNikem]

That is a very a nice setup, @anuraaga ! Thanks for sharing this with us. Fancy writing a blog post? ;)

[trask]

I think this is good to close, and we can open new issues for any future related work that arises.

Thanks @anuraaga!