New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@NewSpan annotation doesn't work #617
Comments
Hi! Thanks for the issue. Could you please upload the sample to Github as a project? Thanks |
@marcingrzejszczak You may import Maven project from https://github.com/zavale/spring-cloud-sleuth-NewSpan-annotation-defect Please note, Zipkin server is supposed to run on http://localhost:9411/ but even if it doesn't run there, you will be able to see the @NewSpan annotation being ignored from Sleuth debug logs. |
It's not working cause you need to put the annotated method in a separate class. We're creating a proxy of the object so if you're calling a proxied method from the proxy itself then the method will be called directly without going through the proxy logic. I'll try to update the docs with that warning |
@marcingrzejszczak I moved annotated method to the separate class, and it's still not working for me. I pushed the modification to https://github.com/zavale/spring-cloud-sleuth-NewSpan-annotation-defect master. The span from the annotation is not created - I cannot observe it, neither in the Sleuth debug logs or Zipkin traces. Could you please take a look? |
Of course it's not working - you need to register it as a bean. That's how proxies work in Spring. Just annotate it with |
@marcingrzejszczak Thanks for the response - I added
Pushed to master here: https://github.com/zavale/spring-cloud-sleuth-NewSpan-annotation-defect But span still doesn't appear in the trace - not in the logs, and not on the locally running Zipkin. Could you please refer me to the working code sample? |
@marcingrzejszczak Thanks for the reference, looking there, I managed to make my example working. Just wanted to summarize my understanding of how to make @NewSpan annotation working, and limitations that it imposes
Could you please clarify that my understanding is correct. Thanks again! |
Hi @zavale. your understanding is correct, with one single exception. Making a bean of ClassOfFoo not necessarily means, that there can't be multiple instances. There are ways to create beans for every Web-Request or for every Session for example using the scopes "request" or "session". Also with "prototype" scope, there can be any number of instances for a specific bean type. Please refer to the reference documentation of the spring framework (here). |
@Koizumi85 speaks the truth :) case closed :D |
@marcingrzejszczak @Koizumi85 Thanks for the help. I think that the limitation of "no spans generated" when methods of the same class call each other significantly reduces the usability. |
It's not the limitation of Sleuth - it's how proxies work in Spring. You can file an issue in Spring if you want to change this approach. As for the usability, I completely don't agree but I guess it's a matter of preference discussion. |
@zavale Also I have to say, that I am wondering how you are using Sleuth, if this behaviour is such a great limitation to you. Sleuth is about tracing distributed systems. So you would create spans if you leave/enter a specific system. For example if you call another microservice, a database or a third-party service. And usually for such calls, you would have a class only doing this specific stuff. |
@marcingrzejszczak @Koizumi85 Thanks |
I have a problem with @NewSpan doesn't generate new span and as a result is not reported to Zipkin server. Explicit spans, created not by annotation, are successfully generated and reported. For reproducing the problem, please run attached Maven project. The project is based on a Maven project generated by https://start.spring.io/, with just a few components - Web, Sleuth and Zipkin client.
For reproducing, hit the endpoint http://localhost:8080/test
The simple Controller should generate the implicit trace with a custom span, but custom span is not generated - observed in the logs, and also on the locally running Zipkin server.
Few suspicious log generated during the application start are:
Where beans related to sleuth reported as not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
demo-no_annotations_working.zip
The text was updated successfully, but these errors were encountered: