New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract transport agnostic zipkin code into finagle-zipkin-core #513
Conversation
@@ -0,0 +1,160 @@ | |||
package com.twitter.finagle.zipkin.core |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
weird this didn't get caught as a rename..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it did in my local git diff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, I fixed up the commits so this appears as a rename
added a couple notes, none of which are important :) carry on. looks like the right path |
import scala.collection.mutable.ArrayBuffer | ||
import scala.language.reflectiveCalls | ||
|
||
object ScribeRawZipkinTracer { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a META-INF change needed? or is the service loader unaffected by the rename
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it should be unaffected.
META-INF/services/com.twitter.finagle.tracing.Tracer
in finagle-zipkin points to com.twitter.finagle.zipkin.thrift.SamplingTracer
.
This diff is too large, I'm going to do some git foo to make it easier to review. |
Ok I force pushed a change that separates the moving of files from the actual code changes. The PR is now easier to review commit by commit. |
response | ||
class FakeRawZipkinTracer extends RawZipkinTracer(NullStatsReceiver) { | ||
var spans: Seq[Span] = Seq.empty | ||
override def sendSpans(xs: Seq[Span]): Future[Unit] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool basically the extender just needs to implement sendSpans
This looks good to me. @sveinnfannar could you add a note to CHANGES? @sveinnfannar what do you think about splitting this up into a few PRs? when we merge it internally, it's all going to be squashed, and I think it would be nice to have separate commits for each piece. ie, the first PR would be HEAD => First Milestone, second commit would be HEAD => First Milestone => Second Milestone, etc, and for the first patch I would grab HEAD => First Milestone, second patch I would grab First Milestone => Second Milestone, etc. I would say this first milestone is pretty close to being ready to ship. I would also suggest breaking out the Scribe stuff to a separate module at some point in time if possible, but it's much less necessary than the work you've outlined so far. |
Thanks for the review @mosesn. Ok, I'll rename this PR and put the finishes touches on it. Regarding breaking out the scribe stuff, do you mean something like having a module named package com.twitter.finagle.zipkin.thrift
@deprecated("Use com.twitter.finagle.zipkin.scribe.ScribeZipkinTracer instead", "6.36.0")
class ZipkinTracer(..) extends ScribeZipkinTracer(..) |
Hmm, I thought the service-loading bit was in finagle-zipkin, but if it's somewhere else then I see what you mean. Should actually be fine this way, imo. |
+1 merging the structural changes first makes it an easy merge, and paves
the way for multiple transports being reviewed or added independently (ex
http, kafka)
|
@mosesn I finished some minor tweaks and manual testing so this PR should be ready. The notes in CHANGES still need an RB_ID. Is that something you add internally? |
@sveinnfannar yeah we'll add the RB_ID, thanks. i'll try to take a look today as well. |
@@ -56,6 +56,17 @@ Breaking API Changes | |||
* finagle-memcached: `c.t.f.memcached.Client` now uses `c.t.bijection.Bijection` | |||
instead of `c.t.u.Bijection`. ``RB_ID=834383`` | |||
|
|||
<<<<<<< HEAD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fyi merge conflict?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:$
@sveinnfannar this is great. my comments are all superficial and should be easy to patch up. |
my pleasure. let me know when its ready for another look. |
@kevinoliver I addressed the comments, can you take another look? |
val transport = ClientBuilder() | ||
.name("zipkin-tracer") | ||
.hosts(new InetSocketAddress(scribeHost, scribePort)) | ||
.codec(ThriftClientFramedCodec()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kevinoliver @mosesn Should we move this to the stack equivalent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should, but its not appropriate for this commit.
@sveinnfannar ok looking good to me. mind fixing this round and pinging when its good? |
LGTM except for @kevinoliver's fixes |
Hi @kevinoliver, I addressed your comments. |
@adriancole, I'm putting the finishing touches on the kafka PR, stay tuned :) |
cool @sveinnfannar looks good now. i'll work on getting this merged in. thanks. |
hmm @sveinnfannar i'm running into some conflicts applying the commits locally. do you mind rebasing on |
Yes no problem |
Move most of finagle-zipkin to finagle-zipkin-core Pants build files for finagle-zipkin-core Add finagle-zipkin-core as a dependency of finagle-zipkin Separate scribe specific code Fix non-exhaustive case warning Move SamplingTracer to finagle-zipkin-core Generic tracer cache with flush on shutdown Remove scribe specific tests already in finagle-zipkin and add test for flushing tracers Fix import Weed out sbt and pants dependencies Make internal classes private Updated CHANGES, change still needs a RB_ID Improved scaladoc comments Annotate return types where needed Remove confusing SamplingTracer from finagle-zipkin Minor dependency fix Fixes after code review Fix some more IntelliJ formatting fuckups Fix after failed rebase
@kevinoliver done 👍 |
ok, this one has decent sized work on our end to get it integrated. i'll keep at it but it may take a few days. |
ok, just ping me on gitter if I can do anything to help |
@sveinnfannar i made good progress on this today and should get it merged in by the end of the week. |
alrighty! got this merged in locally and should show up on the thanks for contribution. |
Great to hear. Thanks for the help. |
Thanks! This was merged and landed: 989edc5 |
Problem
Address issue #465 (Add http and kafka transports to zipkin-tracer).
Zipkin can receive traces via Kafka, HTTP and Scribe. Some Finagle users (including Quizup) already using Kafka are reluctant to introduce Scribe into their stack as it is no longer maintained.
So the purpose of this PR is to support Kafka as a transport for Zipkin traces, as well as structuring the code such that it allows other transports to be added (like HTTP).
Solution
Extract most of finagle-zipkin into finagle-zipkin-core, leaving finagle-zipkin with only scribe specific stuff (with no api breaking changes to finagle-zipkin of course).
Then implement finagle-zipkin-kafka, which depends on finagle-zipkin-core. Kafka transport will be introduced in a separate PR.This structure was initially suggested by @kevinoliver in #465 (comment).
Todo
Implement finagle-zipkin-kafka (in progress)(separate PR)Questions
@mosesn can you check this out and provide some feedback?
@adriancole is this in line with what you had envisioned?