Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Probe Yang
    @ProbeYang_twitter
    and, Is it possible to return a list of response objects instead of a binary list at the end of the call call?
    image.png
    _full_dispatch_request=Api.call
    __call__
    Vytautas Liuolia
    @vytas7
    Hi @ProbeYang_twitter ! Could you provide more background information about what you're trying to achieve?
    Are you trying to build a better Falcon integration plugin for SkyWalking?
    Ramesh G. Menon
    @rameshgmenon_twitter
    Congratulations and thanks to the team for all the awesome new features in 3.0. We're working on migrating from 1.x but we're currently using falcon-autocrud (https://pypi.org/project/falcon-autocrud/) which doesn't appear to support anything beyond 1.x. Anyone aware of an alternative to falcon-autocrud for 3.0?
    Probe Yang
    @ProbeYang_twitter
    image.png

    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.

    @vytas7
    Vytautas Liuolia
    @vytas7

    @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

    Vytautas Liuolia
    @vytas7

    @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

    Probe Yang
    @ProbeYang_twitter
    @vytas7 thanks for reply. I will try monkey-path. i provide Falcon plugin for skywalking-python, not for Falcon, so it's ok. now i have two questions:1. I want to get the request object before calling call. How can I do that? 2. I want to get the response object after calling call, how to achieve it? thank
    the call is __call__
    Vytautas Liuolia
    @vytas7
    I understand that. Was trying to write __call__ in Gitter myself once :)
    Probe Yang
    @ProbeYang_twitter
    thanks, @vytas7
    Vytautas Liuolia
    @vytas7
    The framework is designed in a way that the request and response objects are normally instantiated in __call__. Changing this logic might need more intrusive monkey-patching, not sure if this is the way we'd like to suggest.
    Probe Yang
    @ProbeYang_twitter
    image.png
    Vytautas Liuolia
    @vytas7

    Maybe you could do something along the lines of the above mentioned integrations?

    Hook into the App so that you ensure that your middleware is added, and that is doing process_response last, after all others?

    You could also do any preparation work in process_request. See also: Middleware.
    Probe Yang
    @ProbeYang_twitter
    before calling __call__ , i want set an object of skywalking some attr from request object, after calling __call__, i want set an object of skywalking some attr from response object, too.
    Vytautas Liuolia
    @vytas7
    Does SkyWalking provide generic WSGI middleware? You could build upon that too, by injecting custom variables into the WSGI environ dict.
    (See above how OTEL does it.)
    As said, alternatively you can make sure your middleware is patched to be first in the list. Then process_request would be close to the start of __call__, except you have req and resp ready.
    Probe Yang
    @ProbeYang_twitter
    Up to now, the python plugin support provided by skywalking includes: https://github.com/apache/skywalking-python/tree/master/skywalking/plugins
    Vytautas Liuolia
    @vytas7
    (Then in process_request, you can set req.context.skywalking to your object.)
    Probe Yang
    @ProbeYang_twitter
    Do you mean: hook process_request? :)
    Vytautas Liuolia
    @vytas7
    Let me create a simple prototype to illustrate what I mean.
    Probe Yang
    @ProbeYang_twitter
    glad to see it :)
    The principle is that the python agent of skywalking does not invade the business code, let alone the framework code, we only make hook functions in the outer layer for decorator decoration
    Vytautas Liuolia
    @vytas7
    @ProbeYang_twitter https://gist.github.com/vytas7/e0197eff2e87705a3df33d63123f3d26

    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
    Vytautas Liuolia
    @vytas7

    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.

    Probe Yang
    @ProbeYang_twitter
    @vytas7 Thank you so much for writing this demo program for me. I saw that it should be ok. I’ll try it first.
    Kurt Griffiths
    @kgriffs
    @vytas7 should we make this an official recipe?
    2 replies
    and/or figure out a way to make this use case easier?
    Vytautas Liuolia
    @vytas7
    @kgriffs Yeah, it feels this is an area we've been neglecting a bit. I created falconry/falcon#1828 for 3.1, and there's an older umbrella issue falconry/falcon#10 (the oldest open issue we have :slight_smile: ).
    Vytautas Liuolia
    @vytas7
    If OpenTelemetry (or other similar project) gains traction, another course of action could be focusing on creating a high quality collector plugin for that system.
    @ProbeYang_twitter it seems that SkyWalking supports OpenTelemetry: https://skywalking.apache.org/blog/2021-02-07-infrastructure-monitoring/. Maybe it's possible to use OTEL's Falcon plugin out of the box with SkyWalking+Hug?
    Probe Yang
    @ProbeYang_twitter
    @vytas7 Yes, OpenTelemetry will instead of OpenTracing. but it's not popular， now
    Probe Yang
    @ProbeYang_twitter
    image.png
    image.png
    this is Falcon files in site-packages
    python version: python3.8.2
    Vytautas Liuolia
    @vytas7
    @ProbeYang_twitter Yeah; API was renamed to App in Falcon 3.0. Hug probably pins falcon==2.0.0.
    Probe Yang
    @ProbeYang_twitter
    yes, i get it. and the plugin, how to fix it in your case?
    Vytautas Liuolia
    @vytas7
    What do you mean?
    Probe Yang
    @ProbeYang_twitter
    in my plugin image, it does not work. it cannot hook Falcon.API
    Vytautas Liuolia
    @vytas7
    You cannot insert a Falcon App/API as middleware. It should be an object that implements the Falcon middleware interface.
    Ramesh G. Menon
    @rameshgmenon_twitter

    @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.