Agent appears to be tied to spring

[ribrewguy]

As indicated by the rule (https://github.com/opentracing-contrib/java-agent/blob/master/opentracing-agent/src/main/resources/otarules.btm) this seems to be a spring-specific project. Ideally this would be adjusted to work for any java application, but short of that this should be renamed/moved to make this clear.

[objectiser]

This rule is only triggered if the referenced spring class is loaded, so in non-spring apps it is a noop.

The rule exists to allow other rules defined within a spring application (and therefore associated with a child classloader) to be loaded.

Does it cause a particular issue in your non-springboot application?

[objectiser]

Looking at the stack trace on the google group thread, I think this is because you are including the opentracing-agent-rules-java-net dependency, which has been removed in version 0.1.0 - which is also the version required to be compatible with the latest opentracing-java API 0.30.0.

[ribrewguy]

I pulled the agent rules dependency out. A redeploy to the cluster resulted in the same manual span being recorded as before (ref from google thread), but nothing else. Do I need to explicitly provide otarules for anything to be recorded by the agent? This is unclear in the documents.

[objectiser]

Yes otarules.btm files need to be provided for any instrumentation that needs to be done.

In the most recent version of the agent, there are rules to install the servlet and okhttp instrumentations - but if there are specific technologies that you want instrumented (and are of general relevance) then please raise a separate issue for each, and we can look at supporting them.

Just to be clear - unlike the hawkular apm agent, which had rules that directly instrumented the technologies, this agent works differently - the rules are intended as a mechanism to install the actual instrumentation code developed in other opentracing-contrib repos - to avoid duplication of work. So for example, the servlet rules https://github.com/opentracing-contrib/java-agent/blob/master/rules/java-web-servlet-filter/src/main/resources/otarules.btm install the ServletFilter from https://github.com/opentracing-contrib/java-web-servlet-filter in Jetty or Tomcat.

The rules can also be used to introduce custom (internal) business logic instrumentation https://github.com/opentracing-contrib/java-agent/blob/master/README.md#creating-custom-rules - so another test you could try is writing such a rule for one of your internal classes/methods.

[ribrewguy]

Ok. Thanks for your timely feedback! This was helpful. This is a more manual approach than expected. It might be worthwhile to expand on this in docs. If I understand correctly users need to

1. Write code that creates spans for business logic (optionally in a separate jar)
2. Write otarules that connect the join points with the code
3. Package it all together and deploy

My wishlist would include having a mechanism that worked like "create a span around every method like do* in package foo.bar" without having to write supporting code. This does not exist right?

[ribrewguy]

Also, I bundled this (basically) simple rule in the otarules.btm file and I'm getting nothing:

RULE Query foos
CLASS foo.bar.FooResource
METHOD query
HELPER io.opentracing.contrib.agent.OpenTracingHelper
AT ENTRY
IF TRUE
DO
  getTracer().buildSpan("query").startActive();
ENDRULE

The documents suggest that using this would create a span for every invocation of query on FooResource.

[objectiser]

In terms of your previous questions - you don't need to write code to create the spans, as you are trying with the rule above.

The code + rules approach is only being used in relation to the technologies that have already been instrumented in other opentracing-contrib repos.

The rule you have listed only starts the span - do you have another rule with AT EXIT that deactivates the active span?

Note: the approach being used to manage active spans will be changing in the next version of the Opentracing Java API - just to beware that any rules that make use of this mechanism will need to be updated. Hopefully it won't be a significant change.

[objectiser]

Closing. Please re-open if there are further questions.