AgentTracer for explicitly instrumented code.

[pavolloffay]

Agent should handle situations when an application code is explicitly instrumented with OpenTracing API. Users would initialize tracer with AgenTracer instance and all calls would be propagated to the tracer used by the agent.

[objectiser]

I'm currently looking at this at the moment: https://github.com/opentracing-contrib/java-agent/issues/19

The issue is that we could get two cases:

• Application is using OT API and registers an agent with GlobalTracer - so the agent then needs to reuse that
• Application does not use OT API at all, in which case the agent must resolver and register the GlobalTracer

So currently looking at an approach that, upon first access of a tracer by the rules, it checks if the GlobalTracer is currently using the NoopTracer, and if so, then tries to use TracerResolver and register it.

[sjoerdtalsma]

@objectiser Please be advised that there is currently no easy way to determine whether a GlobalTracer was registered or not. You always get its singleton instance from GlobalTracer.get(). I think your use-case may require some isRegistered / isInitialized method on the GlobalTracer.

[objectiser]

@sjoerdtalsma Thanks for the heads up - I'll submit something.

[pavolloffay]

I would propose a different approach:

Have multiple agent-provider-specific (zipkin, jaeger,..) and then agent-plain which would get tracer impl via GlobalTracer (for cases when an app is explicitly instrumented for instance business logic).

We cannot make an assumption that every tracer would be possible to create via java SPI. Usually, there is a lot of configuration at tracer creation time. I think we should provide these adapters and all the configuration would be done through system/env properties.

cc @yurishkuro @bhs

To go bit further these agent-specific-provider could contain all framework integrations or just an agent (build could produce both e.g. -all) for usages when users could set class path for the agent like here: https://github.com/objectiser/java-agent-spring-boot-example https://github.com/opentracing-contrib/java-agent#tracer-and-framework-integrations-on-classpath

If the users would like to exclude specific integration from agent-provider-specific-all.jar they would for example fork, exclude and build an agent what is best for them. Or via system properties, there are more options.

[objectiser]

I'm not keen on the idea of having provider specific builds of the agent in this repo - they should exist in the tracer specific project's own repos.

[pavolloffay]

The build would still provide a generic agent which could be used by any OT provider. Problem is taht currently this agent is hard to use, build does not provide any complete agent with tracer and instrumentations.

[objectiser]

Agree that having a complete agent, with tracer and integration+rules, would be useful - just mean that I think such an agent should be built and located within the tracer's project.

This repo should remain independent on any specific tracer implementation.