Are you trying to build a better Falcon integration plugin for SkyWalking?
Yes. background information is: i want to write a plugin of skywalking for hug, and hug is base of falcon, so i need write a falcon plugin of skywalking, if i complete it, then All frameworks with Falcon as the underlying layer will support skywalking.
@rameshgmenon_twitter Thanks for your kind words!
I'm unaware of an exact 1:1 alternative, but maybe you could fork it, and add 2.0+ compatibility?
Falcon hasn't changed that much since 1.4.0. This might be one of the few showstoppers: https://bitbucket.org/garymonson/falcon-autocrud/issues/17/missing-the-req_succeeded-parameter-on
@ProbeYang_twitter I see. How are you thinking to hook into Falcon in your plugin? Would you monkey-patch falcon.App
(previously falcon.API
)?
I haven't used Hug much, but IIRC it doesn't allow interacting directly with the app object much (i.e. you cannot provide own Falcon middleware), but maybe that has changed.
You could also take a look at how others tackle the same problem.
I know Sentry's Falcon integration uses monkey-patching.
So does OTEL too (?): https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/instrumentation/opentelemetry-instrumentation-falcon/src/opentelemetry/instrumentation/falcon/__init__.py
process_request
. See also: Middleware.
process_request
would be close to the start of __call__
, except you have req
and resp
ready.
You can use your WSGI server of choice. I ran with gunicorn instrumentation:app
just to test it.
$ http http://localhost:8000/sleepy
HTTP/1.1 200 OK
Connection: close
Server: gunicorn
content-length: 18
content-type: application/json
0.3792928051696004
$ http http://localhost:8000/notfound
HTTP/1.1 404 Not Found
Connection: close
Server: gunicorn
content-length: 26
content-type: application/json
vary: Accept
{
"title": "404 Not Found"
}
$ http http://localhost:8000/hello
HTTP/1.1 200 OK
Connection: close
Server: gunicorn
content-length: 28
content-type: application/json
{
"message": "Hello, World!"
}
... meanwhile in Gunicorn's stdout
:
time taken for 9b8565d7-74d0-4003-beb9-952dd9a58473: 0.3800630569458008
9b8565d7-74d0-4003-beb9-952dd9a58473 succeeded: True
time taken for d949a511-bd24-4058-a82a-abe76fddf114: 0.00011134147644042969
d949a511-bd24-4058-a82a-abe76fddf114 succeeded: False
time taken for e9584f81-326a-4d68-af94-e6016c94943b: 1.4543533325195312e-05
e9584f81-326a-4d68-af94-e6016c94943b succeeded: True
Instrumentation frameworks use to wrap the whole WSGI (and nowadays ASGI too) application in generic WSGI middleware, see: Middleware: Components that Play Both Sides, so it depends how SkyWalking does this.
If you opt to wrap the whole WSGI app and inject custom keys into the WSGI environ, you can access these via req.env
.
App
/API
as middleware. It should be an object that implements the Falcon middleware interface.
@rameshgmenon_twitter Thanks for your kind words!
I'm unaware of an exact 1:1 alternative, but maybe you could fork it, and add 2.0+ compatibility?
Falcon hasn't changed that much since 1.4.0. This might be one of the few showstoppers: https://bitbucket.org/garymonson/falcon-autocrud/issues/17/missing-the-req_succeeded-parameter-on
Thanks @vytas7 ! Agreed that it should be portable. We'll dig a bit deeper and see if we can contribute that.