static instrumentation approach

[jhalliday]

I've been looking over the maven plugin work and I really like the possibilities this opens up for reducing the deployment footprint and runtime complexity for microservices. I'm especially liking the potential of a build time approach for native image construction in e.g. quarkus or micronaut, given the slow progress on making GraalVM play nice with agents.

I can see why wrapping the existing agent was an expedient approach for the static injector project at AGH, but with a view to getting the core of this capability into the mainline opentelemetry codebase, I'd like to gather some views on the best long term design for it.

Currently I see the Java instrumentation as consisting of the rulebase (patches to the 3rd party libs and the advices that tell the injector where to wire them) plus the injector that inserts them, which is structured as an agent. For providing buildtime rather than runtime injection, wrapping the existing agent has some advantages in allowing much code reuse, but some drawbacks in complicating the usage and in the fragility of the integration. Patching into private agent methods that may be refactored between versions seems like a recipe for maintenance headaches. One option may be to extend the agent to provide formal extension points for this, or even to include the functionality directly - perhaps a cmd line option on the agent to provide a dir to which instrumented classes would be written out for consumption by other tooling.

An alternative may be to add a new module to the instrumentation project that provides a static instrumenter as a peer to the agent, rather than as a wrapper around it. I expect this would share much of the same code, certainly all the rulebase parts. However, it could perhaps work by using bytebuddy's ability to rewrite classes without needing to load them and could work as an embeddable library rather than requiring a separate process to be spawned, making it simpler to consume in other tooling such as the quarkus build chain.

I'd be interested in the view of the maintainers and prospective users on what's most likely to be suitable here. Quarkus could certainly benefit from this capability, but likely only if it's mainline rather than contrib, so looking at ways we can get the core capabilities promoted to a more maintained and supported state is a priority.

Regards

Jonathan Halliday
Java engineering, Red Hat

[trask]

hi @jhalliday!

We also view this as a very promising project!

I think it makes sense for @kubawach and @Enkelian to finish contributing their initial implementation (which they are upstreaming from https://github.com/agh-static-x/Maven-Plugin piece-by-piece to make it easier for reviewers), and then we would love to continue evolving it with the broader community.

likely only if it's mainline rather than contrib

This is a common misconception about the contrib repository. There's nothing inherently unmaintained or unsupported about components in it.

That said, this particular component could make a lot of sense in the instrumentation repo to evolve it side-by-side with the javaagent runtime instrumentation.