-
Notifications
You must be signed in to change notification settings - Fork 58
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
More complete example of Tornado instrumentation #43
Comments
let me try to pull some of our internal files. They will reference some internal libs, but hopefully it's clear what's going on. Adapting this into an open-source example would be awesome. Our internal repo has a example that also runs as unit test and checks interop between different python libs like Flask, Tornado, and TChannel. Ironically, the screenshot on https://zipkin.io/ is from that example.
It's possible some of the jaeger_xxx files above might be refactored and moved to open source. |
Thanks for the quick response @yurishkuro! Any chance you have an example where |
ah, right, it's used with this extension we have for tornado.web.App: https://pastebin.com/547sjA6f |
Ok, so I have put together a super simple tornado app to try and work through this in isolation of existing codebases (and with stock tornado rather than clay-tornado): It definitely does not handle threads correctly etc, but is mostly meant to be illustrative of the pattern we are looking at (wraps every handler that extends from BaseHandler, requires minimal code changes to existing app, etc). It creates a "correct" span record when just hitting locally: I am wondering how close to "out of the box" tornado this can be kept? Tornado provides |
The complication is that you need to propagate the current span using Tornado's native version of TLS (StackContext). I think it's possible to do via callbacks instead of a context manager. Another nice to have thing is to be able to access the route defined for each endpoint, so that instead of GET as the operation names you could capture something like |
Good point about the operations names. Any chance you could share what |
Awesome, this is super helpful. Just a heads up that |
I seem to have the test app working properly now. I basically just copy/pasted and rearranged the code you provided (removed some clay references, unwound circular dep, changed some naming etc): Basically if the folders So a couple questions:
Thanks again for your help here! |
The sample looks reasonable. Regarding packaging it, I am reluctant to create real modules and take the maintenance burden, since we have equivalent internal modules at Uber, and open sourcing those is also quite a bit of work that's hard to justify. I would be fine with just keeping them internal to the I do wonder if there's a simpler way than several wrapper/middleware classes.
you mean like chat? Don't think we have an active community interested specifically in this repo, but otherwise you can find us on https://gitter.im/jaegertracing/Lobby and https://gitter.im/opentracing/public. |
This seems to be working for me. Code inspired by many sources.
|
I have been trying to piece together how to properly instrument a tornado application based on the documentation/comments throughout this repository, such as:
https://github.com/uber-common/opentracing-python-instrumentation#usage
https://github.com/uber-common/opentracing-python-instrumentation/blob/master/opentracing_instrumentation/request_context.py#L231-L240
However, I cannot quite connect all the dots. I think what would be extremely useful is a more complete example of how to use the middleware with a Tornado RequestHandler.
Also, if you just want to make a quick note in this issue showing how it is to be used, I would be more than happy to commit PR the actual documentation once we have our instrumentation working. Thanks!
The text was updated successfully, but these errors were encountered: