Since updating to Spring Boot 1.5.2 (Camden.SR6) Zipkin needs a configured service name. Otherwise the application is shown as "unknown" in traces. Setting spring.zipkin.service.name: ${spring.application.name} in application.yml is a workaround.
So you're saying that in the logs everything is fine but in Zipkin the service name is wrong? Are you using HTTP or messaging?
Here you have an example with messaging and everything seems ok - http://docsbrewing-zipkin-server.cfapps.io/traces/24dfbd55bc2fbddb?serviceName=brewing
I'm using spring-cloud-starter-zipkin. When querying the Zipkin server for the span via id in integration test, the service is named as "unknown". Previously this was the real service name.
Do you have a sample to show? Also can you run this in debug and tell me what does the ServerPropertiesEndpointLocatorState ? This code looks good - https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-zipkin/src/main/java/org/springframework/cloud/sleuth/zipkin/ServerPropertiesEndpointLocator.java#L75 I wonder why do you see things improperly.
Will do tomorrow. There was some misinformation: In integration test I'm using /V1/trace/{traceId} to get my trace from the server. Then I'm checking whether this contains the service name.
Can you paste the full JSON from Zipkin? So that we can check it out?
public ServerPropertiesEndpointLocator(ServerProperties serverProperties, String appName, ZipkinProperties zipkinProperties, InetUtils inetUtils) is called with appName = "unknown".
I had to anonymize half of the JSON, so this would probably not be useful for you. What could I be looking for?
unknown can be only when you don't provide the spring.application.name . Without a sample I can't really help you much.
though I had provided spring.application.name still unknown was coming for me in zipkin-server. After Setting spring.zipkin.service.name: ${spring.application.name} in application.yml, service name started coming
@elgohr or @shuchitaprasad can you please provide a sample. I can't replicate this without a sample
Tried to replicate it in https://github.com/elgohr/ZipkinErrorExample, but works as expected.
Also tried different variations of dependencies from the original project, without effect.
In this way I debugged a little more. Came to the point that DefaultEndpointLocatorConfiguration resolves @Value("${spring.application.name:unknown}") to "unknown".
This is weird, because it's present and used in the integration test for checking...
In integration test itself, @Value("${spring.application.name}") is resolved correctly.
The integration test is similar to https://github.com/elgohr/ZipkinErrorExample/blob/master/src/test/java/com/springboot/ZipkinErrorExampleApplicationTests.java
Interesting... Have you put the spring.application.name in application.yml or bootstrap.yml ? Try putting it in the latter and see if you have the same problem.
Tried both, same problem.
Ok, so is there a reason to have the appName separately in ServerPropertiesEndpointLocator?
zipkinProperties.getService().getName() is filled correctly, while appName is not.
Can you check out the Sleuth issues_#545_late_name_resolution branch, build it locally and run your sample with the version from that branch? I've changed the code to resolve the service name not in the constructor but later, when the name is to be resolved
Again shown as unkown
So if you put a breakpoint in that branch code the spring.application.name is resolved improperly at runtime? Regardless of what you put in application.yml or bootstrap.yml?
Finally reproduced the issue.
It appears when you use @EnableSwagger2
See https://github.com/elgohr/ZipkinErrorExample
After bumping the Swagger versions to
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger2</artifactId>
<version>2.6.1</version>
</dependency>
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger-ui</artifactId>
<version>2.6.1</version>
<scope>runtime</scope>
</dependency>
Everything is working fine. Can you confirm this and can we then close this issue?
Ping @elgohr ?
Confirmed. Thank you!
Most helpful comment
After bumping the Swagger versions to
Everything is working fine. Can you confirm this and can we then close this issue?