Thanks, Sean. I hadn't seen this before. It seems very similar to Zipkin in most respects. It has the Zipkin-style separation between TraceId and SpanId, as well as 64-bit random IDs for both.
It seems like an odd choice to include duration as well as start time and end time. Can't duration be calculated from these other two? Did Zipkin do that too? I can't remember. Spans have a userId, which I assume is kind of similar to our TracerId. Trying to identify who did what. I'm surprised that there are no arbitrary key/value annotations permitted. They mention this as TBD. It looks like everything is global in Tracer.java so better be prepared for have traced libraries stomp on each other's configuration. Probably the most interesting choice is the decision to hard-code everything to go to the Java logging framework. I guess the idea is you can use "grep" or something to separate the trace JSON from the logfiles later, and then run your existing analytics stack on that data. Or maybe Nike has their java logging hooked up to something more sophisticated than a file-based sink (thinking about it more, this is probably the rationale.) Should HTrace implement a log4j trace sink? It would certainly be easy for us to implement, and maybe useful for people who want to experiment. We have our stable JSON API, so it's just a matter of outputting that information. cheers, Colin On Tue, Jul 26, 2016, at 13:55, Sean Busbey wrote: > did folks see that Nike has opensourced a distributed tracing system > based on Dapper? > > https://github.com/Nike-Inc/wingtips > > > -- > busbey
