What is the classloader structure for Exporters pulled in by the auto instrumentation?

[jsuereth]

I'm trying to make sure the Google Cloud auto exporters align with the direction the community has taken the past few months around classloaders, shading and stability.

Specifically:

1. Do we have the parent-child classloader relationship documented for -Dotel.exporter.jar? I'd like to know what I need to shade on my end to avoid possible conflicts with shared classes between exporter + agent jar. AFAIK exporters are loaded in their own classloader, but I was curious if you're using a filtered-parent for JUST the API/SDK or just "everything in the agent".
2. Are the rules on shading for my jar? Right now we're just bundling everything into the fat jar. I'd be happy to reduce the size by NOT including the API/SDK though :)
3. My exporter takes a dependency on gRPC + protobuf 3.0. I can shade/rename these in addition to bundling, but wanted to check if that's mandatory or not based on the classloader design of the agent.

[anuraaga]

Looks like we need to add the exporter jar to our classloader docs here though do check out what's in the "Agent classloader"

https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/contributing/javaagent-jar-components.md

But the quick answer should be that you don't need to do any shading - we apply shading at runtime in the classloader

https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/javaagent-tooling/src/main/java/io/opentelemetry/javaagent/tooling/ExporterClassLoader.java#L31

The parent of the exporter is the agent classloader

https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/javaagent-tooling/src/main/java/io/opentelemetry/javaagent/tooling/AgentTracerProviderConfigurer.java#L69

So it includes the OpenTelemetry SDK and exporters, meaning it also includes gRPC. I think that means that you would want to shade gRPC + protobuf to not conflict with what's in there, but you could get something back by not including the OTel API / SDK. Not entirely sure on it though, @trask can you confirm?

[trask]

Hey @jsuereth!

The other vendors I'm aware of (Splunk, AWS, Microsoft, Lightstep, NewRelic, Traceable) are releasing custom distros of the otel javaagent, and so we have much better docs and example about how to do that: https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/examples/distro

This would be my recommendation, unless you have specific desire to use otel.exporter.jar (the one advantage of otel.exporter.jar is that you don't need to release each time a new otel javaagent is released).

[jsuereth]

@trask Interesting, so otel.exporter.java exists, but isn't recommended?

[jsuereth]

The parent of the exporter is the agent classloader

https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/javaagent-tooling/src/main/java/io/opentelemetry/javaagent/tooling/AgentTracerProviderConfigurer.java#L69

Rather than shading the agent classlsoader, why not "filter what's visible" from the Parent classloader, e.g. https://github.com/sbt/launcher/blob/1.x/launcher-implementation/src/main/scala/xsbt/boot/FilteredLoader.scala#L13

What this does:

• We limit the classes visible in the classloader to ONLY the public API used by "plugins"
• Beneath it is a real classloader with everything.
• We load plugins with this filtered loader as its parent, and it meanss our "plugin interface" classes are shared but nothing else, no shading necessary.

Effectively you'd have:

[ OpenTelemetryInstaller classloader ] <- [ Filtered classloader only exposing `sdk`/`api` packages ] <- [Agent Exporter classloader]

Happy to try to throw together a prototype if you think this would be useful / help reduce maintainance burden (that list of shaded packages seems like an area of churn to me, vs. "here's what is stable").

As far my problem, it sounds like we either need to make our own instrumentation jar or we should likely shade/rename our exporter.jar unless we contribute more to the existing shading.

[trask]

Rather than shading the agent classloader, why not "filter what's visible" from the Parent classloader

This sounds like a great idea

Happy to try to throw together a prototype if you think this would be useful

👍