Expose method to get the Trace Id of an ongoing trace

[Jefftree]

There a probably a few cases where it would be useful to retrieve the trace id within an ongoing trace for logging/correlating/etc. The current way to do this is to call create_http_headers_for_new_span().get('X-B3-TraceId'). This does a bit of unnecessary work with creating new span ids, copying parent id, etc.

https://github.com/Yelp/py_zipkin/blob/master/py_zipkin/zipkin.py#L538

Would it be possible to expose a method (eg: get_trace_id()) that just retrieves the trace id and omits the extra work? Again, this is probably just another micro optimization, and I'd like to hear some thoughts. The motivation for this is that I'd like to remove the dynamic (and slow) request.set_property() in pyramid zipkin, and use this new function in methods which read from the request object without adding too much complication.

https://github.com/Yelp/pyramid_zipkin/blob/master/pyramid_zipkin/request_helper.py#L139

[codefromthecrypt]

For prior art, in brave, we have a utility CurrentTraceContext.get() which allows you to get an immutable view of the propagated data (this is also available as span.context()). The TraceContext includes the following: containing this span uses 128-bit trace identifiers. */ public abstract long traceIdHigh(); /** Unique 8-byte identifier for a trace, set on all spans within it. */ public abstract long traceId(); /** The parent's {@link #spanId} or null if this the root span in a trace. */ @nullable public abstract Long parentId(); /** * Should we sample this request or not? True means sample, false means don't, null means we defer * decision to someone further down in the stack. */ @nullable public abstract Boolean sampled(); /** * True is a request to store this span even if it overrides sampling policy. Defaults to false. */ public abstract boolean debug(); /** * Unique 8-byte identifier of this span within a trace. * * <p>A span is uniquely identified in storage by ({@linkplain #traceId}, {@linkplain #spanId}). */ public abstract long spanId(); /** * True if we are contributing to a span started by another tracer (ex on a different host). * Defaults to false. * * <p>When an RPC trace is client-originated, it will be sampled and the same span ID is used for * the server side. However, the server shouldn't set span.timestamp or duration since it didn't * start the span. */ public abstract boolean shared();

…

On Wed, Aug 23, 2017 at 2:47 AM, Jeffrey Ying ***@***.***> wrote: There a probably a few cases where it would be useful to retrieve the trace id within an ongoing trace for logging/correlating/etc. The current way to do this is to call create_http_headers_for_new_ span().get('X-B3-TraceId'). This does a bit of unnecessary work with creating new span ids, copying parent id, etc. https://github.com/Yelp/py_zipkin/blob/master/py_zipkin/zipkin.py#L538 Would it be possible to expose a method (eg: get_trace_id()) that just retrieves the trace id and omits the extra work? Again, this is probably just another micro optimization, and I'd like to hear some thoughts. The motivation for this is that I'd like to remove the dynamic (and slow) request.set_property() in pyramid zipkin, and use this new function in methods which read from the request object without adding too much complication. https://github.com/Yelp/pyramid_zipkin/blob/master/ pyramid_zipkin/request_helper.py#L139 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#60>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD610cuUFeEnwVUFD_FW4frIBHUrg3Iks5sayIngaJpZM4O_CCV> .

[Jefftree]

Thanks @adriancole. I think we can replicate that behaviour in py_zipkin.

There is already a get_zipkin_attrs() function here https://github.com/Yelp/py_zipkin/blob/master/py_zipkin/thread_local.py#L18

We could just expose this function in our main file: zipkin.py

[dbishop]

I found myself wanting access to the span context object after it was out of scope. A trivial example:

def foo():
    # I wish I could add an annotation or binary_annotation here!
    pass

def bar():
    with zipkin.zipkin_span(...):
        foo()

Our use-case is tracing OpenStack Swift, which is a WSGI app running in eventlet.

We monkey-patch all the get/set_default_tracer() functions with an eventlet greenthread-local-storage-aware version. This is obviously gross, so please let me know if you'd be interested in a PR to make the py_zipkin/storage.py infrastructure able to use eventlet thread-local storage.

Then, since the tracer is accessible from anywhere, we use a SpanSavingTracer subclass that provides a stack for span context objects. This works in concert with our ezipkin_span (e for "eventlet") subclass of zipkin_span which pushes and pops the span context object, as necessary.

We then created helper functions to add annotations and binary_annotations to the "current" span_context.

This is also pretty gross, and may even leak memory (not sure, just a general "spidey sense tingling" feeling).

Is there some better way to do this sort of thing?