search

opentracing-contrib / java-specialagent

Automatic instrumentation for 3rd-party libraries in Java applications with OpenTracing.
Apache License 2.0
185 stars 46 forks source link

Specialagent 1.6.1 is giving me "Tracer was not specified with "sa.tracer" system property" even though I set it #596

Closed jgoeres closed 4 years ago

jgoeres commented 4 years ago

I am trying to get started with tracing and I am focusing on a springboot-based microservice for now.

After I ran into https://github.com/opentracing-contrib/java-specialagent/issues/589 I downgraded to version 1.6.1 of the specialagent and tried to get it running. I first overlooked that where 1.7.x requires the tracer to use to be configured with 

-Dsa.exporter=<tracer>

1.6.x requires

 -Dsa.tracer=<tracer>

I am setting the latter system property, but still the log gives me:

<<<<<<<<<<<<<<<<<<<< Loading Tracer Plugin >>>>>>>>>>>>>>>>>>>>>
Tracer was not specified with "sa.tracer" system property

This is my commandline (slightly obfuscated): 

java
-server
-XX:HeapDumpPath=/xyz/dumps
-XX:ErrorFile=/xyz/logs/hs_err_pid%p.log
-XX:+HeapDumpOnOutOfMemoryError
-XX:+CrashOnOutOfMemoryError
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintGCDetails
-Xloggc:/xyz/logs/gc.log
-XX:+LogVMOutput
-XX:LogFile=/xyz/logs/jvm.log
-Dzkc.working.dir=/abc/zkc
-Xrunjdwp:transport=dt_socket,address=9700,server=y,suspend=n
-Xmx1G
-Xss2m
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.port=9600
-Dcom.sun.management.jmxremote.rmi.port=9600
-Djava.rmi.server.hostname=127.0.0.1
-Dcom.sun.management.jmxremote.ssl=false
-Djava.io.tmpdir=/xyz/temp
-javaagent:/abc/opentracing-specialagent-1.6.1.jar
-DJAEGER_SERVICE_NAME=xyz-xyzserver-0
-Dsa.exporter=jaeger
-Dsa.tracer=jaeger
-Dsa.log.level=FINE
-Dsa.log.events=ERROR
-Dsa.integration.*.disable
-Dsa.integration.cassandra:driver:*.enable
-Dsa.integration.cassandra:driver:*.enable
-Dsa.integration.elasticsearch:*.enable
-Dsa.integation.apache:httpclient:*.enable
-XX:-UseContainerSupport
-jar /xyz/lib/xyz-service-1.0.0-SNAPSHOT-exec.jar

As you can see, I just set both the old and the new system property to select the tracer to use. Further, I decided to disable all integrations and only selectively enable those that I need to keep startup overhead small - I hope that it works like that. This is running on Azul OpenJDK in an Alpine Linux container:

java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (Zulu 8.46.0.20-SA-linux-musl-x64) (build 1.8.0_252-b14)
OpenJDK 64-Bit Server VM (Zulu 8.46.0.20-SA-linux-musl-x64) (build 25.252-b14, mixed mode)

Any idea what I am missing here?

THX

J

jgoeres commented 4 years ago

Actually, the issue https://github.com/opentracing-contrib/java-specialagent/issues/589 only affects Java 9 or later, but I tried to keep versions consistent across our stack (and most services are Java 11 or later). After switching this microservice (which is still running on Java 8) to specialagent 1.7.4, it seems to work - I can see traces in Jaeger, but interestingly the log still shows 

<<<<<<<<<<<<<<<<<<<< Loading Tracer Plugin >>>>>>>>>>>>>>>>>>>>>
Tracer was not specified with "sa.tracer" system property