2a1b4befba
This supports 128-bit traces via a new field traceIdHigh, which matches other zipkin implementations. In encoded form, the trace ID is simply twice as long (32 hex characters). With this change in, a 128-bit trace propagated will not be downgraded to 64-bits when sending downstream, reporting to Zipkin or adding to the logging context. This will be followed by a change to support initiating 128-bit traces.
Running Zipkin Server
There are 3 parts to Zipkin: the instrumented client apps, the backend database and the Zipkin server. The database for this implementation is MySQL.
There is a running instance on PWS: http://zipkin-web.cfapps.io. It is backed by a
zipkin-serverwith a MySQL backend and RabbitMQ (Spring Cloud Stream) for span transport.
Instrumenting Apps
Depend on Spring Cloud Sleuth Stream. Bind to a rabbit service (or redis if you prefer - normal Spring Cloud Stream process).
Zipkin Server
Depend on spring-cloud-sleuth-zipkin-stream and enable the server:
@SpringBootApplication
@EnableZipkinStreamServer
public class ZipkinStreamServerApplication {
public static void main(String[] args) throws Exception {
SpringApplication.run(ZipkinStreamServerApplication.class, args);
}
}
Zipkin has a web UI, which is enabled by default when you depend on io.zipkin.java:zipkin-autoconfigure-ui.
Bind to MySQL and the same Stream service that you did in the apps (rabbit, redis, kafka). Set spring.datasource.initialize=true the first time you start to initialize the database.
Uses the zipkin-server library from the OSS as well as spring-cloud-sleuth-stream.
NOTE: running in the "test" profile you don't need MySQL (the span store is in memory). You could even run in PWS without MySQL.