Adrian Cole

what @jcchavezs said makes sense. We cannot effectively instrument a listener model, *unless* there is shared state between the listeners. For example, if it is 100% the case that onX...

one thing to note about the state issue is we are talking about the state around scope. ex which scope to revert to.. ex tracer.setId is similar to java currenttracecontext.newScope...

hard for me to drive-by recommend anything. I mainly meant that `tracer.setId(req._trace_id)` type of thing is the only thing available in callback. scoped is not helpful there.

@cwoodworth not sure if you have seen this, yet https://github.com/openzipkin/zipkin-js/tree/master/packages/zipkin-instrumentation-fetch

The reason why this hasn't progressed is the easiest one to answer. This is a completely volunteer run project, so someone would need to offer help to implement this. If...

Maybe do a github search to see if anyone else is making custom tracing for mongo using zipkin-js? On 15 Apr 2017 12:03 am, "阳衡锋" wrote: > anyone can pr...

I looked around and found almost universally people are instrumenting mongodb with a shimmer of some sort.

keep open for now as I have another topic we need to resolve which is explicit use of contexts inside instrumentation (ex `tracer.record(id, annotation)`) which can help guarantee less loss...

#137 allows you to use zipkin v2 format via the following: ```javascript const { Tracer, BatchRecorder, jsonEncoder: {JSON_V2} } = require('zipkin'); const {HttpLogger} = require('zipkin-transport-http'); const recorder = new BatchRecorder({...

keeping this issue open as I'm not sure all the "v2" pieces you want. For example, kafka could be changed, as well, and also we could add a v2 api...