Flask auto-instrumentation doesn't configure itself properly about applicationinsights-python HOT 9 CLOSED

I'll log out some more details, but currently what I've shared is that the incoming request headers to Flask show the first traceparent (Which would be supplied by FastAPI), then when I log the incoming request headers to Django I see a different traceparent. I'll spin this example back up locally to see if I can add additional checks to ensure the requests being made by FastAPI/Flask have the expected traceparent header before sending them off, then I'll update here with the findings.

from applicationinsights-python.

Interesting, thanks @lzchen for digging into that on my behalf. I'll confirm this is the case on my project locally then close this issue if that's the case - since I'd see this more as a "me using it wrong" issue rather than a library one.

from applicationinsights-python.

Just for more context, is the only discrepancy for traceparent correlation that you are seeing is between the spans created from flask and django calls? Is the fastapi call correlating properly?

from applicationinsights-python.

Just for more context, is the only discrepancy for traceparent correlation that you are seeing is between the spans created from flask and django calls? Is the fastapi call correlating properly?

Correct yes - though admittedly I didn't try putting a service in front of FastAPI to guarantee this was the case.

My case goes: FastAPI -> Flask -> Django

So the traceparent is generated on the FastAPI service, and the header is present when the request reaches the Flask service, however on the subsequent request made by Flask -> Django the traceparent is lost (a new one is used instead).

If it would be beneficial I can extend the example to check the FastAPI instrumentation as well, but the case I'm referring to here is primarily focused on Flask

from applicationinsights-python.

That's interesting. Can you confirm that, in the buggy case, the traceparent is the same between fastapi and flask, and then the traceparent is different for Django than the other two? (it should be one traceparent being propagated along all three apps).

If the traceparent is different for django, it should be some issue in the django instrumentation's ability to detect the current trace context, but for some reason, the issue is resolved with a call to FlaskInstrumentor().instrument_app(app) ?

from applicationinsights-python.

Ok, this took me a bit longer than expected to get the information out of the origin. But I have a few more details to share. To reiterate the case is this:

1. Request Made in browser to fastapi:8002/posts -> 2. Child request made to flask:8001/posts_raw -> 3. Child request made to django:8000/api/posts

Breakdown of steps

1. When calling (1) the trace is not set up yet, FastAPI handles creating the trace
   a. When FastAPI calls flask:8001/posts_raw I can see the header of the request to posts_raw in wireshark: traceparent: 00-08ad7029752bfa75af09c23c1359cd37-093574528b3a14a5-01

2. Request from FastAPI enters Flask service, I log the traceparent header in the view function:
   Received: 00-08ad7029752bfa75af09c23c1359cd37-093574528b3a14a5-01 which matches expected traceparent from FastAPI
   a. Request is made from Flask -> Django, I log the traceparent of the request: Requested: 00-983572231e5fef05985ca219e009734f-25b159d8726c80a4-01

3. Request is received in Django, I log the traceparent as soon as it enters the view: Received: 00-983572231e5fef05985ca219e009734f-25b159d8726c80a4-01

To me it looks like the culprit is somewhere in the Flask auto instrumentation, as we're seemingly losing the trace between steps 2 and 2.a.

If I uncomment the FlaskInstrumentor().instrument_app(app) line in the Flask API this issue disappears and the traceparent originally provided by FastAPI properly "sticks" to the trace context across the services

from applicationinsights-python.

I see. This is a strange behavior observed from the Flask instrumentation. For some reason, if you import from flask import Flask the instrumentation does not patch the class properly. If you change your import in your flask app to import flask and instantiate your application like app = flask.Flask(__name__) then it should correlate properly.

from applicationinsights-python.

@thinkGeist

@tonybaloney has added a pr to update the docs to better outline the guidance for imports so future users won't fall into this pitfall. I hope this helps address your issue! :) #314

Are you still investigating or can we consider this matter resolved?

from applicationinsights-python.

@thinkGeist

@tonybaloney has added a pr to update the docs to better outline the guidance for imports so future users won't fall into this pitfall. I hope this helps address your issue! :) #314

Are you still investigating or can we consider this matter resolved?

I'd consider this resolved! Thanks for your time in determining the solution and making changes to prevent people from running into the issue in the future!

from applicationinsights-python.