Dela via

Felsök Python-fel i Azure Functions

  • Artikel

Den här artikeln innehåller information som hjälper dig att felsöka fel med dina Python-funktioner i Azure Functions. Den här artikeln stöder programmeringsmodellerna v1 och v2. Välj den modell som du vill använda från väljaren överst i artikeln.

Kommentar

Programmeringsmodellen Python v2 stöds endast i 4.x-funktionskörningen. Mer information finns i Översikt över Azure Functions-körningsversioner.

Här är felsökningsavsnitten för vanliga problem i Python-funktioner:

Mer specifikt med v2-modellen, här är några kända problem och deras lösningar:

Allmänna felsökningsguider för Python Functions är:

Felsökning: ModuleNotFoundError

Det här avsnittet hjälper dig att felsöka modulrelaterade fel i python-funktionsappen. Dessa fel resulterar vanligtvis i följande Azure Functions-felmeddelande:

Undantag: ModuleNotFoundError: Ingen modul med namnet "module_name".

Det här felet uppstår när en Python-funktionsapp inte kan läsa in en Python-modul. Rotorsaken till det här felet är ett av följande problem:

Visa projektfiler

För att identifiera den faktiska orsaken till problemet måste du hämta Python-projektfilerna som körs i funktionsappen. Om du inte har projektfilerna på den lokala datorn kan du hämta dem på något av följande sätt:

  • Om funktionsappen har en WEBSITE_RUN_FROM_PACKAGE appinställning och dess värde är en URL laddar du ned filen genom att kopiera och klistra in URL:en i webbläsaren.
  • Om funktionsappen har WEBSITE_RUN_FROM_PACKAGE angetts till 1går du till https://<app-name>.scm.azurewebsites.net/api/vfs/data/SitePackages och laddar ned filen från den senaste href URL:en.
  • Om funktionsappen inte har någon av de föregående appinställningarna går du till https://<app-name>.scm.azurewebsites.net/api/settings och hittar URL:en under SCM_RUN_FROM_PACKAGE. Ladda ned filen genom att kopiera och klistra in URL:en i webbläsaren.
  • Om förslag löser problemet går du till https://<app-name>.scm.azurewebsites.net/DebugConsole och visar innehållet under /home/site/wwwroot.

Resten av den här artikeln hjälper dig att felsöka potentiella orsaker till det här felet genom att granska funktionsappens innehåll, identifiera rotorsaken och lösa det specifika problemet.

Diagnostisera ModuleNotFoundError

Det här avsnittet beskriver potentiella rotorsaker till modulrelaterade fel. När du har listat ut vilken som är den troliga rotorsaken kan du gå till den relaterade begränsningen.

Det går inte att hitta paketet

Gå till .python_packages/lib/python3.6/site-packages/<package-name> eller .python_packages/lib/site-packages/<package-name>. Om filsökvägen inte finns är den här sökvägen förmodligen rotorsaken.

Att använda verktyg från tredje part eller inaktuella verktyg under distributionen kan orsaka det här problemet.

Information om hur du åtgärdar det här problemet finns i Aktivera fjärrversion eller Skapa inbyggda beroenden.

Paketet matchas inte med rätt Linux-hjul

Gå till .python_packages/lib/python3.6/site-packages/<package-name>-<version>-dist-info eller .python_packages/lib/site-packages/<package-name>-<version>-dist-info. Använd din favorittextredigerare för att öppna hjulfilen och kontrollera avsnittet Tagga: . Problemet kan bero på att taggvärdet inte innehåller linux.

Python-funktioner körs endast på Linux i Azure. Functions runtime v2.x körs på Debian Stretch och v3.x-körningen körs på Debian Buster. Artefakten förväntas innehålla rätt Linux-binärfiler. När du använder --build local flaggan i Core Tools, tredje part eller inaktuella verktyg kan det leda till att äldre binärfiler används.

Information om hur du åtgärdar problemet finns i Aktivera fjärrversion eller Skapa inbyggda beroenden.

Paketet är inte kompatibelt med Python-tolkversionen

Gå till .python_packages/lib/python3.6/site-packages/<package-name>-<version>-dist-info eller .python_packages/lib/site-packages/<package-name>-<version>-dist-info. Öppna METADATA-filen i textredigeraren och kontrollera avsnittet Klassificerare: . Om avsnittet inte innehåller Python :: 3, Python :: 3.6, Python :: 3.7, Python :: 3.8eller Python :: 3.9, är paketversionen antingen för gammal eller, mer sannolikt, det är redan slut på underhåll.

Du kan kontrollera Python-versionen av din funktionsapp från Azure-portalen. Gå till funktionsappens resurssida Översikt för att hitta körningsversionen. Körningsversionen stöder Python-versioner enligt beskrivningen i översikten över Azure Functions-körningsversioner.

Information om hur du åtgärdar problemet finns i Uppdatera paketet till den senaste versionen eller Ersätt paketet med motsvarande.

Paketet står i konflikt med andra paket

Om du har kontrollerat att paketet har lösts korrekt med rätt Linux-hjul kan det uppstå en konflikt med andra paket. I vissa paket kan PyPi-dokumentationen klargöra de inkompatibla modulerna. I hittar du till exempel följande instruktion:azure 4.0.0

Det här paketet är inte kompatibelt med azure-storage. Om du har installerat azure-storage, eller om du har installerat azure 1.x/2.x och inte avinstallerat azure-storage, måste du avinstallera azure-storage först.

Du hittar dokumentationen för din paketversion i https://pypi.org/project/<package-name>/<package-version>.

Information om hur du åtgärdar problemet finns i Uppdatera paketet till den senaste versionen eller Ersätt paketet med motsvarande.

Paketet stöder endast Windows- och macOS-plattformar

requirements.txt Öppna med en textredigerare och kontrollera paketet i https://pypi.org/project/<package-name>. Vissa paket körs endast på Windows- och macOS-plattformar. Till exempel körs pywin32 endast på Windows.

Felet Module Not Found kanske inte uppstår när du använder Windows eller macOS för lokal utveckling. Paketet kan dock inte importeras på Azure Functions, som använder Linux vid körning. Det här problemet orsakas troligen av att du använder pip freeze för att exportera den virtuella miljön till requirements.txt från din Windows- eller macOS-dator under projektinitieringen.

Information om hur du åtgärdar problemet finns i Ersätt paketet med motsvarande eller Handcraft-requirements.txt.

Minimera ModuleNotFoundError

Följande är potentiella åtgärder för modulrelaterade problem. Använd de tidigare nämnda diagnoserna för att avgöra vilka av dessa åtgärder som ska provas.

Aktivera fjärrbygge

Kontrollera att fjärrbygget är aktiverat. Hur du ser till att det beror på distributionsmetoden.

Kontrollera att den senaste versionen av Azure Functions-tillägget för Visual Studio Code är installerad. Kontrollera att filen .vscode/settings.json finns och att den innehåller inställningen "azureFunctions.scmDoBuildDuringDeployment": true. Om den inte gör det skapar du filen med inställningen azureFunctions.scmDoBuildDuringDeployment aktiverad och distribuerar sedan om projektet.

Skapa inbyggda beroenden

Kontrollera att de senaste versionerna av både Docker och Azure Functions Core Tools är installerade. Gå till projektmappen för den lokala funktionen och använd func azure functionapp publish <app-name> --build-native-deps för distribution.

Uppdatera paketet till den senaste versionen

I den senaste paketversionen av https://pypi.org/project/<package-name>kontrollerar du avsnittet Klassificerare: . Paketet ska vara OS Independent, eller kompatibelt med POSIX eller POSIX :: Linux i operativsystemet. Programmeringsspråket bör också innehålla: Python :: 3, Python :: 3.6, Python :: 3.7, Python :: 3.8eller Python :: 3.9.

Om dessa paketobjekt är korrekta kan du uppdatera paketet till den senaste versionen genom att ändra raden <package-name>~=<latest-version> i requirements.txt.

Handgjorda requirements.txt

Vissa utvecklare använder pip freeze > requirements.txt för att generera listan över Python-paket för sina utvecklingsmiljöer. Även om den här bekvämligheten bör fungera i de flesta fall kan det finnas problem i scenarier för plattformsoberoende distribution, till exempel utveckling av funktioner lokalt i Windows eller macOS, men publicering till en funktionsapp som körs på Linux. I det här scenariot pip freeze kan du introducera oväntade operativsystemspecifika beroenden eller beroenden för din lokala utvecklingsmiljö. Dessa beroenden kan bryta Python-funktionsappen när den körs på Linux.

Det bästa sättet är att kontrollera importinstruktionen från varje .py fil i projektets källkod och sedan bara checka in modulerna i requirements.txt-filen. Den här metoden garanterar att paketlösningen kan hanteras korrekt på olika operativsystem.

Ersätt paketet med ekvivalenter

Ta först en titt på den senaste versionen av paketet i https://pypi.org/project/<package-name>. Det här paketet har vanligtvis en egen GitHub-sida. Gå till avsnittet Problem på GitHub och sök för att se om problemet har åtgärdats. Om det har åtgärdats uppdaterar du paketet till den senaste versionen.

Ibland kan paketet ha integrerats i Python Standard Library (till exempel pathlib). I så fall, eftersom vi tillhandahåller en viss Python-distribution i Azure Functions (Python 3.6, Python 3.7, Python 3.8 och Python 3.9), bör paketet i din requirements.txt-fil tas bort.

Men om du upptäcker att problemet inte har åtgärdats och du har en tidsgräns rekommenderar vi att du gör lite efterforskningar för att hitta ett liknande paket för projektet. Vanligtvis ger Python-communityn dig en mängd olika liknande bibliotek som du kan använda.

Inaktivera flaggan för beroendeisolering

Ange programinställningen PYTHON_ISOLATE_WORKER_DEPENDENCIES till värdet 0.

Felsök: det går inte att importera "cygrpc"

Det här avsnittet hjälper dig att felsöka "cygrpc"-relaterade fel i python-funktionsappen. Dessa fel resulterar vanligtvis i följande Azure Functions-felmeddelande:

Det går inte att importera namnet "cygrpc" från "grpc._cython"

Det här felet uppstår när en Python-funktionsapp inte kan börja med en korrekt Python-tolk. Rotorsaken till det här felet är ett av följande problem:

Diagnostisera referensfelet "cygrpc"

Det finns flera möjliga orsaker till fel som refererar cygrpctill , som beskrivs i det här avsnittet.

Python-tolken matchar os-arkitekturen

Det här matchningsfelet beror troligen på att en 32-bitars Python-tolk installeras på 64-bitarsoperativsystemet.

Om du kör ett x64-operativsystem kontrollerar du att python-versionen 3.6, 3.7, 3.8 eller 3.9 också har en 64-bitarsversion.

Du kan kontrollera biten i Python-tolken genom att köra följande kommandon:

I Windows i PowerShell kör du py -c 'import platform; print(platform.architecture()[0])'.

På ett Unix-liknande gränssnitt kör du python3 -c 'import platform; print(platform.architecture()[0])'.

Om det finns ett matchningsfel mellan Python-tolkens bitighet och operativsystemarkitekturen laddar du ned en korrekt Python-tolk från Python Software Foundation.

Python-tolken stöds inte av Azure Functions Python Worker

Azure Functions Python Worker stöder endast specifika Python-versioner.

Kontrollera om Python-tolken matchar din förväntade version i py --version Windows eller python3 --version i Unix-liknande system. Kontrollera att returresultatet är en av de Python-versioner som stöds.

Om python-tolkversionen inte uppfyller kraven för Azure Functions laddar du i stället ned en Python-tolkversion som stöds av Functions från Python Software Foundation.

Felsökning: Python avslutades med kod 137

Kod 137-fel orsakas vanligtvis av minnesbrist i python-funktionsappen. Därför får du följande Azure Functions-felmeddelande:

Microsoft.Azure.WebJobs.Script.Workers.WorkerProcessExitException: python avslutades med kod 137

Det här felet uppstår när en Python-funktionsapp tvingas avslutas av operativsystemet med en SIGKILL signal. Den här signalen indikerar vanligtvis ett out-of-memory-fel i Python-processen. Azure Functions-plattformen har en tjänstbegränsning som avslutar alla funktionsappar som överskrider den här gränsen.

Information om hur du analyserar flaskhalsen i din funktionsapp finns i Profil python-funktionsapp i lokal utvecklingsmiljö.

Felsökning: Python avslutades med kod 139

Det här avsnittet hjälper dig att felsöka segmenteringsfel i python-funktionsappen. Dessa fel resulterar vanligtvis i följande Azure Functions-felmeddelande:

Microsoft.Azure.WebJobs.Script.Workers.WorkerProcessExitException: python avslutades med kod 139

Det här felet uppstår när en Python-funktionsapp tvingas avslutas av operativsystemet med en SIGSEGV signal. Den här signalen indikerar brott mot minnessegmenteringen, vilket kan bero på en oväntad läsning från eller skrivning till en begränsad minnesregion. I följande avsnitt tillhandahåller vi en lista över vanliga rotorsaker.

En regression från paket från tredje part

I funktionsappens requirements.txt-fil uppgraderas ett ej fäst paket till den senaste versionen under varje distribution till Azure. Paketuppdateringar kan potentiellt introducera regressioner som påverkar din app. Om du vill återställa från sådana problem kommenterar du ut importinstruktionerna, inaktiverar paketreferenserna eller fäster paketet i en tidigare version i requirements.txt.

Avpickling från en felaktigt formaterad .pkl-fil

Om din funktionsapp använder Python Pickle-biblioteket för att läsa in ett Python-objekt från en .pkl-fil är det möjligt att filen innehåller en felaktigt formaterad bytesträng eller en ogiltig adressreferens. Om du vill återställa från det här problemet kan du prova att kommentera ut pickle.load() funktionen.

Pyodbc-anslutningskollision

Om din funktionsapp använder den populära ODBC-databasdrivrutinen pyodbc är det möjligt att flera anslutningar är öppna i en enda funktionsapp. Undvik det här problemet genom att använda singleton-mönstret och se till att endast en pyodbc-anslutning används i funktionsappen.

Synkroniseringsutlösare misslyckades

Felet Sync triggers failed kan orsakas av flera problem. En möjlig orsak är en konflikt mellan kunddefinierade beroenden och inbyggda Python-moduler när dina funktioner körs i en App Service-plan. Mer information finns i Pakethantering.

Felsök: det gick inte att läsa in filer eller sammansättningar

Du kan se det här felet när du kör lokalt med hjälp av programmeringsmodellen v2. Det här felet orsakas av ett känt problem som ska lösas i en kommande version.

Det här är ett exempelmeddelande för det här felet:

DurableTask.Netherite.AzureFunctions: Det gick inte att läsa in filen eller sammansättningen "Microsoft.Azure.WebJobs.Extensions.DurableTask, Version=2.0.0.0, Culture=neutral, PublicKeyToken=014045d636e89289".
Det går inte att hitta den angivna filen.

Felet uppstår på grund av ett problem med hur tilläggspaketet cachelagrades. Om du vill felsöka problemet kör du det här kommandot med --verbose för att se mer information:

func host start --verbose

Det är troligt att du ser det här cachelagringsproblemet när du ser en tilläggsinläsningslogg som Loading startup extension <> inte följs av Loaded extension <>.

Lös problemet så här:

  1. .azure-functions-core-tools Hitta sökvägen genom att köra:

    func GetExtensionBundlePath

  2. .azure-functions-core-tools Ta bort katalogen.

    rm -r <insert path>/.azure-functions-core-tools

Cachekatalogen återskapas när du kör Core Tools igen.

Felsök: Det går inte att lösa Azure Storage-anslutningen

Du kan se det här felet i dina lokala utdata som följande meddelande:

Microsoft.Azure.WebJobs.Extensions.DurableTask: Det går inte att matcha Azure Storage-anslutningen med namnet "Storage".
Värdet kan inte vara null. (Parametern "provider")

Det här felet beror på hur tillägg läses in från paketet lokalt. Lös det här felet genom att utföra någon av följande åtgärder:

  • Använd en lagringsemulator, till exempel Azurite. Det här alternativet är bra när du inte planerar att använda ett lagringskonto i funktionsprogrammet.

  • Skapa ett lagringskonto och lägg till en niska veze till AzureWebJobsStorage miljövariabeln i localsettings.json-filen. Använd det här alternativet när du använder en lagringskontoutlösare eller bindning med ditt program, eller om du har ett befintligt lagringskonto. För att komma igång läser du Skapa ett lagringskonto.

Det går inte att hitta funktioner efter distributionen

Det finns flera vanliga byggproblem som kan leda till att Python-funktioner inte hittas av värden efter en till synes lyckad distribution:

  • Agentpoolen måste köras på Ubuntu för att garantera att paketen återställs korrekt från byggsteget. Kontrollera att distributionsmallen kräver en Ubuntu-miljö för att skapa och distribuera.

  • När funktionsappen inte finns i roten på källdatabasen kontrollerar du att pip install steget refererar till rätt plats där mappen ska skapas .python_packages . Tänk på att den här platsen är skiftlägeskänslig, till exempel i det här kommandoexemplet:

    pip install --target="./FunctionApp1/.python_packages/lib/site-packages" -r ./FunctionApp1/requirements.txt

  • Mallen måste generera ett distributionspaket som kan läsas in i /home/site/wwwroot. I Azure Pipelines utförs detta av uppgiften ArchiveFiles .

Utvecklingsproblem i Azure-portalen

När du använder Azure-portalen bör du ta hänsyn till dessa kända problem och deras lösningar:

  • Om du vill ta bort en funktion från en funktionsapp i portalen tar du bort funktionskoden från själva filen. Knappen Ta bort fungerar inte för att ta bort funktionen när du använder python v2-programmeringsmodellen.
  • När du skapar en funktion i portalen kan du bli förmanad att använda ett annat verktyg för utveckling. Det finns flera scenarier där du inte kan redigera koden i portalen, bland annat när ett syntaxfel har identifierats. I dessa scenarier använder du Visual Studio Code eller Azure Functions Core Tools för att utveckla och publicera din funktionskod.

Nästa steg

Om du inte kan lösa problemet kontaktar du Azure Functions-teamet:

Rapportera ett olöst problem