You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The long term solution is to have the middleware directly add all http metadata to the root segment generated by Lambda worker. The SDK currently doesn't have access to this segment right now and we don't have an ETA yet.
The workaround is to have middleware to only generate subsegments when running on Lambda. This causes a problem in the service graph. The color of the Lambda function node in the service graph is decided by status code in lambda segments. And this status code only indicates if the lambda function runs or not. It doesn't respect the actual status code returned by your web application running within that lambda function. If you have correct IAM role setup and no syntax error on your application code, most likely you will always see an all green service graph node despite a lot of 4xx returned by your web app.
This workaround makes it difficult to discover issues and we cannot call this workaround "support for serverless". But we are open to here any suggestions. If such workaround is acceptable we can make it an opt-in so that at least FacadeSegmentMutationException is avoided.
Reacted by Matthew Thompson, Семён Марьясин and Justinas
For others running into this issue, @Sniedes722's combination of patching and enabling x-ray in Zappa worked for me. I'm not sure why, but it didn't work until I added the sampling=False, context=Context() stuff.
@iandees I can also confirm that @haotianw465 is completely correct about getting green OK status codes in x-ray when the API is returning 400 statuses with this workaround
You can have your own implementation of the context() used in Lambda container which creates another type of facadesegment which can be modified freely and replicate everything it has to a child subsegment.
Please let me know if you need any help on implementing a customized context management that specifically fits your use case.
Feel free to leave any feedback on the new customer experience and we are happy to discuss a workaround based on those new feedback. We will also be working with Lambda team based on those new feedback to better improve the overall experience. Thank you for your patience.
Activity
haotianw465 commentedon Oct 26, 2017
Hi, which serverless framework are you using?
datar-ai commentedon Oct 28, 2017
I use zappa , and python flask framework.
haotianw465 commentedon Oct 31, 2017
The long term solution is to have the middleware directly add all http metadata to the root segment generated by Lambda worker. The SDK currently doesn't have access to this segment right now and we don't have an ETA yet.
The workaround is to have middleware to only generate subsegments when running on Lambda. This causes a problem in the service graph. The color of the Lambda function node in the service graph is decided by status code in lambda segments. And this status code only indicates if the lambda function runs or not. It doesn't respect the actual status code returned by your web application running within that lambda function. If you have correct IAM role setup and no syntax error on your application code, most likely you will always see an all green service graph node despite a lot of 4xx returned by your web app.
This workaround makes it difficult to discover issues and we cannot call this workaround "support for serverless". But we are open to here any suggestions. If such workaround is acceptable we can make it an opt-in so that at least FacadeSegmentMutationException is avoided.
[-]Python, Lambda and Flask: FacadeSegments cannot be mutated[/-][+]Serverless framework support[/+]Sniedes722 commentedon Jan 17, 2018
patching the libraries seemed to solve this issue for me, also using lambda, flask, & zappa.
and then this was how i wrapped it inside the flask application:
Sniedes722 commentedon Jan 17, 2018
also enabled in zappa config checkout: https://github.com/Miserlou/Zappa#aws-x-ray
iandees commentedon Jan 28, 2018
For others running into this issue, @Sniedes722's combination of patching and enabling x-ray in Zappa worked for me. I'm not sure why, but it didn't work until I added the
sampling=False, context=Context()stuff.Sniedes722 commentedon Jan 28, 2018
@iandees I can also confirm that @haotianw465 is completely correct about getting green OK status codes in x-ray when the API is returning 400 statuses with this workaround
xplorld commentedon Jun 8, 2018
@haotianw465 What are the consequences if we use our own
Context()instead of using SDK-provided Lambda context?haotianw465 commentedon Jun 13, 2018
@xplorld the recorder class intentionally exposes an API to allow users to configure their own context management https://github.com/aws/aws-xray-sdk-python/blob/master/aws_xray_sdk/core/recorder.py#L75.
You can have your own implementation of the
context()used in Lambda container which creates another type of facadesegment which can be modified freely and replicate everything it has to a child subsegment.Please let me know if you need any help on implementing a customized context management that specifically fits your use case.
haotianw465 commentedon Sep 6, 2018
Hi all, API Gateway with active X-Ray integration is launched. You can see more details here: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-xray.html.
Feel free to leave any feedback on the new customer experience and we are happy to discuss a workaround based on those new feedback. We will also be working with Lambda team based on those new feedback to better improve the overall experience. Thank you for your patience.
Add Serverless Framework Support (aws#2)
Add Serverless Framework Support (aws#2)
Add Serverless Framework Support (aws#2)
Add Serverless Framework Support (aws#2)
chanchiem commentedon Feb 26, 2019
Good news! Serverless support has been merged into the master branch!
#127
Merge pull request #2 from csteinle/master