Open itaybaror opened 2 years ago
I am seeing the same problem: { "errorMessage": "Unable to import module 'otel_wrapper': No module named 'fss_request_xml_mapper'", "errorType": "Runtime.ImportModuleError", "stackTrace ": [] }
In this case, the "fss_request_xml_mapper" module is found in another layer used by the function. I have followed the steps outlined in https://aws-otel.github.io/docs/getting-started/lambda/lambda-python as well. The WARNING seen in the reporters log is also in mine as well.
Can you please try to use the latest python arns to see if the error persists?
No, that didn't seem to make any difference using the latest arn from https://aws-otel.github.io/docs/getting-started/lambda/lambda-python
Same error.
Hi @UniqueScreenName, I think your problem is to be found in how you package your other layer. I would suggest
sam cli
for deploying the entire infrastructure, and let sam package the layer for youutils
library in my_library/python
and then `cd my_library && zip -r ../utils.zip *. You can now try to upload your layer and see what happens.I recently experienced the same error message while converting an existing project to use OpenTelemtry.
After introducing the layer, I started receiving an error message like:
[ERROR] Runtime.ImportModuleError: Unable to import module 'otel_wrapper': No module named 'package1/package2/module.hander'
My issue turned out to be a difference in how the standard Lambda runtime and the otel_wrapper.py
script—specifically the Lambda auto instrumentation—import handlers. In short, slash-based paths result in an error above during instrumentation. The wrapper itself and the standard runtime handle this format (package1/package2/module.handler
), but the Lambda instrumentation does not.
This specific issue can be easily worked around by converting the handler target to use only dots:
package1.package2.module.handler
I created https://github.com/myles2007/OpenTelemIssue-PythonLambdaLayer-v1.14.0 to further explain and demonstrate the problem. I intend to create a specific Issue tomorrow (and hopefully a fix soon after).
For anyone who may come across this issue and find themselves in the scenario I outlined above, the issue I created is #1465.
My issue turned out to be a difference in how the standard Lambda runtime and the
otel_wrapper.py
script—specifically the Lambda auto instrumentation—import handlers. In short, slash-based paths result in an error above during instrumentation. The wrapper itself and the standard runtime handle this format (package1/package2/module.handler
), but the Lambda instrumentation does not.This specific issue can be easily worked around by converting the handler target to use only dots:
package1.package2.module.handler
I would never ever have solved this problem without your comment, which I'm pretty sure is the only such comment in existence. Thank you so much @myles2007
@jkclark You're welcome! I'm glad to hear it helped you out. :)
For a little added context in case it helps you or anyone else out, I encountered this issue while using SST. Previously this detail was just happenstance—it was quite possible to fix by using the dot-based notation I previously described—so I omitted it.
Unfortunately, as of SST 2.x, the OpenTelemetry layer auto instrumentation and SST are now at odds with each other. SST requires slash-based path notation and the OpenTelemetry layer still requires the dot-based notation. Short of modifying SST or the the layer, I was unable to resolve this issue.
Long story short, the root of this issue is that SST now infers your source path (i.e., the directory to package up):
(source)
For Python, it does this based on a search up your path to the nearest requirements file (one of a few types). An assumption is made that the path looks like a file system path (source) for the purposes of traversal.
While this could be resolved in SST, a framework's choice of how the handler path is specified is up to that framework (in my opinion). Ultimately, I still believe this is something that should be addressed in the OpenTelemetry layer as it is intended to be something you can introduce seamlessly into your Lambda, but it's not compatible with the options Lambda provides for handler specification in a Python runtime.
Thank you very much, I had the same error and your solution was the only salvation. @myles2007
To solve it, reducing side effects, modify the otel_wrapper.py file of the otel-lambda layer, and... as you see on line 480, modify self.wrapped_module_name and apply a replace to eliminate / and leave it alone., also add a try except to this instrument function since at least it could have a trace of errors in cloudwatch :) and it worked perfectly
You're welcome, @sebas1017! I'm happy to hear my comments were helpful to you. :)
Hopefully https://github.com/open-telemetry/opentelemetry-python-contrib/issues/1465 can get some traction one of these days. I suppose I should consider just submitting a fix myself, but I've been a little hesitant of spending the time given the lack of even a reply on my issue. 😞
Has there ever been any movement on this? Currently getting this while trying to integrate the otel layer into an existing lambda with a custom built layer. We do not use / based function handlers so i don't think it's the same problem as @myles2007.
Runtime.ImportModuleError: Unable to import module 'otel_wrapper': No module named 'paramiko'
We have a layer called paramiko
that this lambda uses. I sense that the otel_wrapper
is trying to interact with it in some way but not sure how.
@myles2007 regarding your comment:
I suppose I should consider just submitting a fix myself, but I've been a little hesitant of spending the time given the lack of even a reply on my issue. 😞
I apologize for the lack of response in this repo. The FAAS SIG has had a lot of staffing changes over the past year. We aren't really staffed for a lot of troubleshooting right now. (If folks want to be more involved, we'd love to have you.)
If you would like to submit a PR to fix this, I'd be happy to get folks to review. (If in the contrib repo, I can reach out to the maintainer to encourage reviews.)
Discussed in https://github.com/open-telemetry/opentelemetry-lambda/discussions/253