Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 05 21:02
    jcchavezs commented #3480
  • Oct 05 20:52

    llinder on master

    [maven-release-plugin] prepare … (compare)

  • Oct 05 20:52

    llinder on master

    [maven-release-plugin] prepare … (compare)

  • Oct 05 20:52

    llinder on 2.23.19

    (compare)

  • Oct 05 20:47

    llinder on release-2.23.19

    (compare)

  • Oct 05 20:47

    jcchavezs on release-2.23.19

    (compare)

  • Oct 05 17:29
    sirmspencer opened #3481
  • Oct 05 17:29
    sirmspencer labeled #3481
  • Oct 05 08:55
    alfredomagallon opened #3480
  • Oct 05 08:55
    alfredomagallon labeled #3480
  • Oct 04 11:30
    jonkerj commented #3434
  • Oct 03 14:31
    mrfelek commented #3434
  • Oct 03 11:51
    jonkerj commented #3434
  • Oct 03 11:07
    wim-de-groot labeled #3479
  • Oct 03 11:07
    wim-de-groot opened #3479
  • Oct 01 13:24
    jeqo commented #1346
  • Oct 01 13:14

    llinder on master

    [maven-release-plugin] prepare … (compare)

  • Oct 01 13:14

    llinder on 5.14.1

    (compare)

  • Oct 01 13:14

    llinder on master

    [maven-release-plugin] prepare … (compare)

  • Oct 01 13:11

    llinder on release-5.14.1

    (compare)

Csaba Kos
@csabakos
Yeah the purpose of that is to add the API key (token)
Adrian Cole
@adriancole
ok
yeah so from performance and everything else POV, I think FinishedSpanHandler is what you want to have implemented
they probably have a zipkin library to send data for example, it might be better than our async sender who knows..
also they may have a means to render stack traces native to their format
they have full access to the throwable in FinishedSpanHandler
TL;DR; I think this is the best solution to the problem
otherwise you can hack and I do mean hack :)
use bytebuddy and scrub out the .toLowerCase that happens in the zipkin2.Span class
or make your own copy of the default FinishedSpanHandler that writes plain json not using our codec
Csaba Kos
@csabakos
Is LightStep the only collector that would want this feature? I'm not super familiar with the tracing space, but it seems like there are a bunch of collectors that offer Zipkin protocol compatibility.
It would be nice to allow case preservation rather than asking every vendor to write a custom FinishedSpanHandler
Adrian Cole
@adriancole
from a vendor POV, there hasn't yet been a request like yours about case format
that doesn't mean they haven't done it.
Csaba Kos
@csabakos
I guess writing my own FinishedSpanHandler that does the same as the default one now but without the lowercasing is an option, but that also feels like a hack and it would be much nicer to just set a flag on the official client
Adrian Cole
@adriancole
the code that applies the downcasing is in the model type which is used by the server etc
putting a flag would require somehow propagating it everywhere
zipkin v2 format is flat and plainer than most if not all other types there are
there are no nested lists etc
we designed the format to be stupid easy
this allows edge cases to be resolved in other ways vs forcing the project to change code types due to one request :P
also literally lightstep have tons of staff
they are billing you and it is unfair for us to have to hold that burden vs even asking them to address this
for example, stackdriver are responsible and they care for their users by helping with things like this
Csaba Kos
@csabakos
From the GitHub issue it looked like other users were asking for this feature as well, which is why I suggested reopening and gauging the interest
But anyways, thanks for the comments, now at least I have some options to pick from!
I will also ask LightStep if they would be open to creating a custom FinishedSpanHandler that avoids this problem
Adrian Cole
@adriancole
yep my goal is met.. give you options.
especially literally this was made for things like datadog also who need to group by local root
Csaba Kos
@csabakos
Got it. Thanks again and have a great rest of your day!
Adrian Cole
@adriancole
good luck!
@csabakos ps specifically what you are asking for could be more precisely addressed in https://github.com/openzipkin/brave issues list as the code affected would be one place or the other. brave has no hard dependency on zipkin, nor the type that does the downcasing
ex in stackdriver, the zipkin-reporter is used, but it actually renders their proto format
this is a far less ask than changing the core type in zipkin, so if you wanted to rally success for only the upload part used by clients, this would be a clearer path.
adriancole @adriancole still thinks FSH is best for LS, but for the rallying for changing the json representation uploaded by brave.. probably brave repo can collect votes faster
Adrian Cole
@adriancole
ttfn
Adrian Cole
@adriancole
@csabakos openzipkin/brave#1077 for your voting and feedback pleasure. Next person who asks for this, I'll point here
jbaddam17
@jbaddam17
zipkin-dependencies jdk 11 issue. any update on openzipkin/zipkin-dependencies#119.
20/02/07 10:09:59 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
20/02/07 10:09:59 WARN Java7Support: Unable to load JDK7 types (annotations, java.nio.file.Path): no Java7 support added
eleven26tech
@eleven26tech
@adriancole Thanks Adrian. Will try it out
Csaba Kos
@csabakos
Thanks @adriancole for the follow up about the case issue. I looked into FinishedSpanHandler a little bit and it looks like that could work for the span name but at that point the local and remote service names are already lowercased because https://github.com/openzipkin/brave/blob/master/brave/src/main/java/brave/handler/MutableSpan.java#L151 lowercases them. Do you have a suggestion about how to overcome that?
Adrian Cole
@adriancole
remoteServiceName should be fine
the localServiceName as it is a constant, for a workaround, you can just overwrite it with the same config as what you use. meanwhile you can raise a PR to delete that line as I agree that doesn't need to happen here. that way next release you can delete the overwriting @csabakos make sense?
iotw I think MutableSpan allows you to change the localServiceName. you can change that in your FinishedSpanHandler with a TODO to remove it later
akhil6095
@akhil6095

Hi,

I'm trying to add distributed tracing to my flink jobs (non Spring java apps) using OpenTracing Brave API, I'm using kafka as source and sink for my jobs, can I somehow use Kafka interceptors to add/read track and span id to/from kafka message headers and log them accordingly?

vttuan
@vttuan
Hi guys,
I am quite new to Zipkin and distributed tracing. I'd like to integrate Zipkin into a server application in order to trace some operations executed by the server. Would it be possible to run Zipkin as a service of the server application instead of running it as a complete standalone service? If yes, would it be possible give me a pointer to start? Thanks!
Adrian Cole
@adriancole
@akhil6095 flink is using kafka? if so, try kafka's client instrumentation. it may be required to make something flink specific, similar to how we have for kafka streams https://github.com/openzipkin/brave/tree/master/instrumentation/kafka-clients https://github.com/openzipkin/brave/tree/master/instrumentation/kafka-streams in any case OpenTracing is unrelated.. that project is cancelled
@vttuan no we only support it as a daemon. you can run via docker or a java process, but not embedded in another java process. here's an example to get started https://github.com/openzipkin/sleuth-webmvc-example
sayeedc
@sayeedc
Hi, new to zipkin and distributed tracing. Is there a way for Zipkin to consume trace information (from message DTOs) from a Kafka topics without having developers make changes to microservices implement a new library? I was thinking of having a consumer app that reads each message for the trace information and sends them to the Zipkin server.