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
We are using their Zipkin endpoint, and I don't believe they have a FinishedSpanHandler that talks to their "native" endpoint
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
Yeah the purpose of that is to add the API key (token)
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
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
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.
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
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
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
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
Got it. Thanks again and have a great rest of your day!
@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