Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 16 07:12
    QualoZe0t commented #202
  • Aug 15 15:11
    llinder assigned #3470
  • Aug 15 10:44
    jcchavezs commented #3470
  • Aug 15 04:27
    ringerc opened #3470
  • Aug 15 04:27
    ringerc labeled #3470
  • Aug 12 11:51
    ikaila opened #3469
  • Aug 12 08:14
    jcchavezs commented #202
  • Aug 12 07:34
    QualoZe0t commented #202
  • Aug 09 08:36
    osadchuk-roman edited #1340
  • Aug 09 08:35
    osadchuk-roman labeled #1340
  • Aug 09 08:35
    osadchuk-roman opened #1340
  • Aug 05 13:53
    DarthJonathan labeled #1339
  • Aug 05 13:53
    DarthJonathan opened #1339
  • Aug 05 13:49
    DarthJonathan commented #1165
  • Aug 05 06:54
    DarthJonathan commented #1165
  • Aug 05 01:33
    FocusProgram commented #3454
  • Aug 05 01:33
    FocusProgram commented #3454
  • Aug 03 14:32
    tahirghoori edited #3468
  • Aug 03 14:30
    tahirghoori labeled #3468
  • Aug 03 14:30
    tahirghoori opened #3468
Adrian Cole
@adriancole
yeah LS doesn't open source their brave integration AFAICT
but yeah it should be a fix in that
Csaba Kos
@csabakos
So the LightStep collectors provide a Zipkin-compatible ingress: https://docs.lightstep.com/docs/use-zipkin-with-lightstep
heh jinx!
so in there you see them talk about a FinishedSpanHandler
so the input to that is 2 args, trace context and a mutable span
the latter does nothing to interfere with case format
so instead of using their zipkin endpoint, use a FinishedSpanHandler that renders into their model
assuming they have it.. literally I have no idea
Csaba Kos
@csabakos
We are using their Zipkin endpoint, and I don't believe they have a FinishedSpanHandler that talks to their "native" endpoint
Adrian Cole
@adriancole
also ask them to open source that because it is easier to discuss when you can see the code heh
"If you’re using Brave, add a FinishedSpanHandler to the Tracing configuration."
so I guess this has a different purpose.. again there are no details
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