如何排查Azure Portal中导致Python函数抛出500错误的依赖包？

这种情况我之前踩过坑！本地跑起来顺得不行，一部署到Azure就给我扔500无措错误，确实闹心。结合你的场景（Ubuntu-latest + Python3.9），给你几个接地气的排查步骤，帮你快速揪出搞事情的依赖包：

• 先把详细错误日志开起来，抓具体报错
  首先得打破“只有500错误码”的僵局，Azure函数默认不会把详细的Python错误抛出来。你可以去函数应用的配置里，新增两个应用设置：

  • PYTHON_ENABLE_WSGI_ERROR_LOGGING设为1
  • FUNCTIONS_WORKER_RUNTIME_VERBOSE_LOGGING设为1
    保存后重启函数应用，再触发一次500错误，然后去监测 > 日志里看具体的报错信息——大概率会看到某个包导入失败、版本不兼容或者缺少系统依赖的提示，这比瞎猜高效多了。另外也可以通过Kudu工具（函数应用菜单里找“高级工具”）进Bash终端，去/home/LogFiles/Application/Functions/Function/<你的函数名>目录下看最新的日志文件，里面会有更底层的错误记录。

• 逐步增量引入依赖，缩小排查范围
  既然你已经能让函数返回简单响应，那可以用分组引入的方式排查：

  • 先把所有依赖注释掉，只留azure-functions这个核心包，部署测试确认正常
  • 然后把你的依赖分成几组，比如：
    第一组：azure-common、azure-core、msrest
    第二组：azure-identity、azure-keyvault-secrets、msal
    第三组：cryptography、grpcio、protobuf（这类涉及底层编译的包）
    第四组：剩下的requests、pyjwt、python-dotenv等工具类包
  • 每次部署一组，测试函数是否正常，直到出现500错误，那问题就出在这一组里，再在组内逐个排查，很快就能定位到具体包。

• 确保本地和Azure的依赖版本完全一致
  很多坑就出在本地和线上的依赖版本不一样！你可以在本地环境跑pip freeze > requirements.txt，把所有依赖的精确版本号都锁死，然后用这个文件部署到Azure。比如cryptography不同版本对系统库的要求不一样，grpcio在Python3.9下也有特定的兼容版本，锁版本能排除大部分这类兼容性问题。

• 直接在Azure环境里测试依赖导入
  用Kudu工具进Bash终端，切换到你的函数目录，激活虚拟环境（如果用了的话），然后逐个测试依赖包能不能正常导入：

  • 比如执行python -c "import azure.identity"，如果报错，那这个包就是问题所在
  • 优先测试那些容易出问题的包：比如涉及底层编译的cryptography、grpcio，还有涉及认证的msal、requests-oauthlib，这些是500错误的高发区。

• 检查是否缺少系统级依赖
  有些Python包依赖Linux系统的底层库，比如cryptography需要libssl-dev和libffi-dev，grpcio需要gcc这类编译工具。虽然Azure的Ubuntu函数镜像自带大部分基础库，但偶尔也会有遗漏。你可以尝试在部署脚本里加一步安装系统依赖的命令：

  • 在requirements.txt同级目录新建post_deploy.sh脚本，内容是sudo apt-get update && sudo apt-get install -y libssl-dev libffi-dev gcc
  • 然后在函数应用的配置里设置POST_DEPLOYMENT_ACTION_RUNNER为bash post_deploy.sh，保存后重启函数应用。不过这一步要谨慎，避免破坏原有环境。

备注：内容来源于stack exchange，提问作者Dixy Barahona