"errorMessage": "Unable to import module 'otel_wrapper': No module named 'utils'"

[itaybaror]

Discussed in https://github.com/open-telemetry/opentelemetry-lambda/discussions/253

^{Originally posted by itaybaror June 22, 2022} I have been trying to auto instrument my python lambda function using the following link.

https://aws-otel.github.io/docs/getting-started/lambda/lambda-python

However i get the following error:

After a lot of playing around, this only happens when i have the AWS_LAMBDA_EXEC_WRAPPER env variable set. Without it, the lambnda function tests with no problems.

I ran a smaller sample project i found in a blog article and everything worked. So, what in my project (which has another layer), could be causing this error?

Please help i have been stuck on this for a while.

[UniqueScreenName]

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.

[bryan-aguilar]

Can you please try to use the latest python arns to see if the error persists?

[UniqueScreenName]

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.

[TheNomet]

Hi @UniqueScreenName, I think your problem is to be found in how you package your other layer. I would suggest

1. use sam cli for deploying the entire infrastructure, and let sam package the layer for you
2. if you want to create the layer yourself, install your utils 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.

[myles2007]

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

[myles2007]

For anyone who may come across this issue and find themselves in the scenario I outlined above, the issue I created is #1465.

[jkclark]

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

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

[sebas1017]

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

[myles2007]

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

[brett-bim]

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.

[tylerbenson]

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