root@toolbox-6d4dcc8778-kkn5n:/# curl http://elasticsearch-master-headless:9200
{
"name" : "elasticsearch-master-0",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "6Jhjdj57SwiBqygkAzApmQ",
"version" : {
"number" : "7.2.0",
"build_flavor" : "default",
"build_type" : "docker",
"build_hash" : "508c38a",
"build_date" : "2019-06-20T15:54:18.811730Z",
"build_snapshot" : false,
"lucene_version" : "8.0.0",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
remoteName override via thezipkinServiceName jdbc url parameter, the current implementation only supports characters in the word character group ( [A-Za-z_]) defined in the TracingJdbcEventListener regex, in my projects I use kebab case and currently only captures the first word before the dash, my proposal is change the regex to make the capture group more generic, capturing everything until the next & (or the end of the string) or at least include - dash that I think is common naming convention, would you be happy to consider a PR with this change?
1 reply
Hey fellas. I’m using spring sleuth and I’m trying to enable the grpcPropagation format. As per documentation, you need to create a GrpcTracing class with grpcPropagationFormatEnabled(true). I tried doing the following
@Bean
public GrpcTracing getGrpcTracing(RpcTracing rpcTracing) {
return GrpcTracing.newBuilder(rpcTracing).grpcPropagationFormatEnabled(true).build();
}but the B3 propagation is used anyway. Any ideas?
30 replies
1 reply
Hi. I made a similar question a few weeks regarding support of grpc-trace-bin and X-Cloud-Trace-Context. Just for context my company currently uses a) an internal Java framework for services b) OpenCensus APIs directly and c) and some internal custom tracing wrappers while my team uses Spring Boot and Sleuth/Brave. I've opened a discussion inside my company to adopt more standard propagation headers like B3. In the meantime, my team needs to support grpc-trace-bin and X-Cloud-Trace-Context.
I've been looking through brave's code to understand what would be the most efficient way to support these propagation formats without re-writing the world. One option would be to write new gRPC interceptors and HTTP filters but this option misses no lots of code already provided by Brave. If I understand the framework correctly, I should write a Propagation similar to B3Propagation which would extract the headers. I should then provide my propagation in the form of a FactoryBuilder bean to replace the default B3 bean. This will eventually make it to TracingServerInterceptor via RpcServerHandler. Is my assumption correct? If yes, any pointers to avoid mistakes? Is there an easier way to use the aforementioned propagation headers?
25 replies
biggest release of the year and also why folks have been so busy. read all about it https://twitter.com/zipkinproject/status/1320676019951448064 https://github.com/openzipkin/zipkin/releases/tag/2.22.0
Congratulations on getting this one out of the door @adriancole !! :fireworks: :fireworks: :fireworks:
3 replies
