Which version of Java agent to use for productive use cases ?

[santoshkashyap]

Hi Team,

I would like to instrument java applications and ship traces to a tracing backend from CloudFoundry and K8S runtimes.
I tried the latest JavaAgent 1.19.1. Below is a sample span visualisation in a tracing backend service for spring mvc:

Similarly, for JDBC and tomcat it has "alpha" suffix. Also verified the previous version 1.18.x. It too seems to have alpha quality for framework support.

Now, randomly tried out older versions of java agent like 1.11.1 and 1.12.0. These do not have alpha suffix.

I have also seen the notice on the instrumentation repository :

"Note that all artifacts other than io.opentelemetry.javaagent:opentelemetry-javaagent have the -alpha suffix attached to their
version number, reflecting that they are still alpha quality and will continue to have breaking changes........"

My question is which version of Java agent is recommended for productive use cases ? Any recommendations for a stable version(slightly older is also fine)

Best Regards,
Santosh

[mateuszrzeszutek]

Hey @santoshkashyap

My question is which version of Java agent is recommended for productive use cases ? Any recommendations for a stable version(slightly older is also fine)

We recommend using the latest version of the javaagent. The agent itself is considered stable; the instrumentations that are included in it are not. This pretty much means that we are allowed to change the telemetry data that is being emitted by the agent, e.g. span names or attributes. This is caused by the fact that the OTel semantic conventions that we're based on are not stable themselves, so until the conventions outlined in the spec stabilize we cannot stabilize the instrumentations.

Now, randomly tried out older versions of java agent like 1.11.1 and 1.12.0. These do not have alpha suffix.

That is actually an unfortunate bug, all of the instrumentations contained in the previous javaagent versions were still unstable, we were just emitting the javaagent version as instrumentationLibrary.version, not the instrumentation version itself.