Felsöka distribution och bedömning av onlineslutpunkter

  • Artikel

GÄLLER FÖR:Azure CLI ml extension v2 (current)Python SDK azure-ai-ml v2 (aktuell)

Lär dig hur du löser vanliga problem med distribution och bedömning av Azure Machine Learning-slutpunkter online.

Det här dokumentet är strukturerat på det sätt som du bör använda för felsökning:

  1. Använd en lokal distribution till att testa och felsöka dina modeller lokalt innan du distribuerar dem i molnet.
  2. Använd containerloggarna för att felsöka problem.
  3. Förstå vanliga distributionsfel som kan uppstå och hur du åtgärdar dem.

Avsnittet HTTP-statuskoder förklarar hur anrops- och förutsägelsefel mappas till HTTP-statuskoder vid bedömning av slutpunkter med REST-begäranden.

Förutsättningar

Distribuera lokalt

Vid lokal distribution distribuerar du modellen i en lokal Docker-miljö. Lokal distribution är användbar för testning och felsökning före distribution till molnet.

Dricks

Du kan också använda Azure Machine Learning-inferens-PAKETET HTTP-server Python för att felsöka ditt bedömningsskript lokalt. Felsökning med slutsatsdragningsservern hjälper dig att felsöka bedömningsskriptet innan du distribuerar till lokala slutpunkter så att du kan felsöka utan att påverkas av konfigurationerna av distributionscontainer.

När du använder en lokal distribution kan du skapa, uppdatera och ta bort en lokal slutpunkt. Du kan även anropa och hämta loggar från slutpunkten.

Om du vill använda lokal distribution lägger du till --local i lämpligt CLI-kommando:

az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local

Som en del av den lokala distributionen utförs följande steg:

  • Docker skapar antingen en ny containeravbildning eller hämtar en befintlig avbildning från den lokala Docker-cachen. En befintlig avbildning används om det finns en som matchar miljödelen i specifikationsfilen.
  • Docker startar en ny container med monterade lokala artefakter som modell- och kodfiler.

Mer information finns i Distribuera lokalt i Distribuera och poängsätta en maskininlärningsmodell.

Dricks

Använd Visual Studio Code till att testa och felsöka dina slutpunkter lokalt. Mer information finns i felsöka onlineslutpunkter lokalt i Visual Studio Code.

Conda-installation

I allmänhet beror problem med MLflow-distribution på problem med installationen av användarmiljön som anges i conda.yaml filen.

Prova följande steg för att felsöka problem med conda-installationen:

  1. Kontrollera loggarna för conda-installation. Om containern kraschade eller tog för lång tid att starta är det troligt att conda-miljöuppdateringen inte kunde matchas korrekt.

  2. Installera mlflow conda-filen lokalt med kommandot conda env create -n userenv -f <CONDA_ENV_FILENAME>.

  3. Om det finns fel lokalt kan du försöka lösa conda-miljön och skapa en funktionell miljö innan du distribuerar om.

  4. Om containern kraschar även om den matchar lokalt kan den SKU-storlek som används för distribution vara för liten.

    1. Conda-paketinstallationen sker vid körning, så om SKU-storleken är för liten för att rymma alla paket som beskrivs i conda.yaml miljöfilen kan containern krascha.
    2. En Standard_F4s_v2 virtuell dator är en bra start-SKU-storlek, men större kan behövas beroende på vilka beroenden som anges i conda-filen.
    3. För Kubernetes onlineslutpunkt måste Kubernetes-klustret ha minst 4 vCPU-kärnor och 8 GB minne.

Hämta containerloggar

Du kan inte få direkt åtkomst till den virtuella dator där modellen distribueras. Du kan dock hämta loggar från vissa av containrarna som körs på den virtuella datorn. Hur mycket information du får beror på distributionens etableringsstatus. Om den angivna containern är igång visas dess konsolutdata. annars får du ett meddelande om att försöka igen senare.

Det finns två typer av containrar som du kan hämta loggarna från:

  • Slutsatsdragningsserver: Loggar inkluderar konsolloggen (från slutsatsdragningsservern) som innehåller utdata från utskrifts-/loggningsfunktioner från bedömningsskriptet (score.py kod).
  • Lagringsinitierare: Loggar innehåller information om huruvida kod- och modelldata har laddats ned till containern. Containern körs innan inferensservercontainern börjar köras.

Om du vill se loggutdata från en container använder du följande CLI-kommando:

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

eller

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100

Lägg till --resource-group och --workspace-name till dessa kommandon om du inte redan har angett dessa parametrar via az configure.

Om du vill se information om hur du anger dessa parametrar och om du för närvarande har angett värden kör du:

az ml online-deployment get-logs -h

Som standard hämtas loggarna från slutsatsdragningsservern.

Kommentar

Om du använder Python-loggning kontrollerar du att du använder rätt ordning på loggningsnivå för att meddelandena ska publiceras i loggar. Till exempel INFO.

Du kan också hämta loggar från containern för lagringsinitieraren genom att skicka –-container storage-initializer.

Lägg till --help och/eller --debug i kommandon för att se mer information.

För Kubernetes onlineslutpunkt kan administratörerna direkt komma åt klustret där du distribuerar modellen, vilket är mer flexibelt för dem att kontrollera loggen i Kubernetes. Till exempel:

kubectl -n <compute-namespace> logs <container-name>

Spårning av begäranden

Det finns två spårningshuvuden som stöds:

  • x-request-id är reserverad för serverspårning. Vi åsidosätter det här huvudet för att säkerställa att det är ett giltigt GUID.

    Kommentar

    När du skapar ett supportärende för en misslyckad begäran bifogar du det misslyckade begärande-ID:t för att påskynda undersökningen.

  • x-ms-client-request-id är tillgängligt för klientspårningsscenarier. Det här huvudet är sanerat för att endast acceptera alfanumeriska tecken, bindestreck och understreck och trunkeras till högst 40 tecken.

Vanliga distributionsfel

Följande lista är vanliga distributionsfel som rapporteras som en del av distributionsåtgärdens status:

Om du skapar eller uppdaterar en Kubernetes-onlinedistribution kan du se vanliga fel som är specifika för Kubernetes-distributioner.

FEL: ImageBuildFailure

Det här felet returneras när miljön (docker-avbildningen) skapas. Du kan kontrollera byggloggen för mer information om felen. Byggloggen finns i standardlagringen för din Azure Machine Learning-arbetsyta. Den exakta platsen kan returneras som en del av felet. Exempel: "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'"

Följande lista innehåller vanliga scenarier med avbildningsfel:

Vi rekommenderar också att du granskar standardinställningarna för avsökning om du har Timeout-tidsgränser för ImageBuild.

Auktoriseringsfel för containerregister

Om felmeddelandet anger "container registry authorization failure" att du inte kan komma åt containerregistret med de aktuella autentiseringsuppgifterna. Avsynkroniseringen av en arbetsyteresurss nycklar kan orsaka det här felet och det tar lite tid att synkronisera automatiskt. Du kan dock manuellt anropa för en synkronisering av nycklar, vilket kan lösa auktoriseringsfelet.

Containerregister som finns bakom ett virtuellt nätverk kan också stöta på det här felet om de har konfigurerats felaktigt. Du måste kontrollera att det virtuella nätverket har konfigurerats korrekt.

Avbildningsgenereringsberäkning har inte angetts i en privat arbetsyta med VNet

Om felmeddelandet "failed to communicate with the workspace's container registry" nämns och du använder virtuella nätverk och arbetsytans Azure Container Registry är privat och konfigurerat med en privat slutpunkt måste du aktivera Azure Container Registry för att kunna skapa avbildningar i det virtuella nätverket.

Fel vid generiska avbildningsversioner

Som tidigare nämnts kan du kontrollera byggloggen för mer information om felet. Om inget uppenbart fel hittas i byggloggen och den sista raden är Installing pip dependencies: ...working...kan ett beroende orsaka felet. Det här problemet kan åtgärdas genom att fästa versionsberoenden i conda-filen.

Vi rekommenderar också att du distribuerar lokalt för att testa och felsöka dina modeller lokalt innan du distribuerar till molnet.

FEL: OutOfQuota

Följande lista är över vanliga resurser som kan få slut på kvoter när du använder Azure-tjänster:

Dessutom är följande lista över vanliga resurser som kan få slut på kvot endast för Kubernetes onlineslutpunkt:

CPU-kvot

Innan du distribuerar en modell måste du ha tillräckligt med beräkningskvot. Den här kvoten definierar hur mycket virtuella kärnor som är tillgängliga per prenumeration, per arbetsyta, per SKU och per region. Varje distribution subtraherar från tillgänglig kvot och lägger till den igen efter borttagningen, baserat på typen av SKU.

En möjlig åtgärd är att kontrollera om det finns oanvända distributioner som du kan ta bort. Eller så kan du skicka en begäran om en kvotökning.

Klusterkvot

Det här problemet uppstår när du inte har tillräckligt med Azure Machine Learning Compute-klusterkvot. Den här kvoten definierar det totala antalet kluster som kan användas samtidigt per prenumeration för att distribuera CPU- eller GPU-noder i Azure Cloud.

En möjlig åtgärd är att kontrollera om det finns oanvända distributioner som du kan ta bort. Eller så kan du skicka en begäran om en kvotökning. Se till att välja Machine Learning Service: Cluster Quota som kvottyp för den här begäran om kvotökning.

Diskkvot

Det här problemet uppstår när modellens storlek är större än det tillgängliga diskutrymmet och modellen inte kan laddas ned. Prova en SKU med mer diskutrymme eller minska storleken på avbildningen och modellen.

Minneskvot

Det här problemet inträffar när modellens minnesfotavtryck är större än det tillgängliga minnet. Prova en SKU med mer minne.

Rolltilldelningskvot

När du skapar en hanterad onlineslutpunkt krävs rolltilldelning för att den hanterade identiteten ska få åtkomst till arbetsyteresurser. Om gränsen för rolltilldelning har nåtts kan du försöka ta bort några oanvända rolltilldelningar i den här prenumerationen. Du kan kontrollera alla rolltilldelningar i Azure-portalen genom att gå till menyn Åtkomstkontroll.

Slutpunktskvot

Försök att ta bort några oanvända slutpunkter i den här prenumerationen. Om alla dina slutpunkter används aktivt kan du försöka begära en ökning av slutpunktsgränsen. Mer information om slutpunktsgränsen finns i Slutpunktskvot med Azure Machine Learning-slutpunkter online och batchslutpunkter.

Kubernetes-kvot

Det här problemet uppstår när den begärda processorn eller minnet inte kan tillhandahållas på grund av att noderna är oplanerade för den här distributionen. Noder kan till exempel vara avspärrade eller på annat sätt otillgängliga.

Felmeddelandet anger vanligtvis att resursen är otillräcklig i klustret, OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods...till exempel , vilket innebär att det finns för många poddar i klustret och inte tillräckligt med resurser för att distribuera den nya modellen baserat på din begäran.

Du kan prova följande åtgärd för att åtgärda det här problemet:

  • För IT-hanterare som underhåller Kubernetes-klustret kan du försöka lägga till fler noder eller rensa några oanvända poddar i klustret för att frigöra vissa resurser.
  • För maskininlärningstekniker som distribuerar modeller kan du försöka minska resursbegäran för distributionen:
    • Om du direkt definierar resursbegäran i distributionskonfigurationen via resursavsnittet kan du försöka minska resursbegäran.
    • Om du använder instance type för att definiera resurs för modelldistribution kan du kontakta IT-avdelningen för att justera resurskonfigurationen av instanstyp. Mer information finns i Hantera Kubernetes-instanstyp.

Kapacitet för hela den virtuella datorn i hela regionen

På grund av brist på Azure Machine Learning-kapacitet i regionen kunde tjänsten inte etablera den angivna VM-storleken. Försök igen senare eller försök att distribuera till en annan region.

Annan kvot

För att köra den tillhandahållna score.py som en del av distributionen skapar Azure en container som innehåller alla resurser som score.py behövs och kör bedömningsskriptet på containern.

Om containern inte kunde starta innebär det att det inte gick att göra någon bedömning. Det kan vara så att containern begär mer resurser än vad som instance_type kan stödjas. I så fall bör du överväga att uppdatera instance_type onlinedistributionen.

Kör för att få den exakta orsaken till ett fel:

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

FEL: BadArgument

Följande lista är av orsaker till att du kan stöta på det här felet när du använder antingen hanterad onlineslutpunkt eller Kubernetes onlineslutpunkt:

Följande lista är av orsaker till att du bara kan stöta på det här felet när du använder Kubernetes onlineslutpunkt:

Prenumerationen finns inte

Den Angivna Azure-prenumerationen måste vara befintlig. Det här felet uppstår när vi inte kan hitta den Azure-prenumeration som refererades. Det här felet beror troligen på ett skrivfel i prenumerations-ID:t. Dubbelkolla att prenumerations-ID:t har skrivits korrekt och att det för närvarande är aktivt.

Mer information om Azure-prenumerationer finns i avsnittet förutsättningar.

Auktoriseringsfel

När du har etablerat beräkningsresursen (när du skapar en distribution) försöker Azure hämta användarcontaineravbildningen från arbetsytan Azure Container Registry (ACR). Den försöker montera användarmodellen och kodar artefakter i användarcontainern från arbetsytans lagringskonto.

För att utföra dessa åtgärder använder Azure hanterade identiteter för att komma åt lagringskontot och containerregistret.

  • Om du har skapat den associerade slutpunkten med systemtilldelad identitet beviljas behörigheten Azure rollbaserad åtkomstkontroll (RBAC) automatiskt och inga ytterligare behörigheter behövs.

  • Om du har skapat den associerade slutpunkten med användartilldelad identitet måste användarens hanterade identitet ha behörighet för Storage Blob Data Reader på lagringskontot för arbetsytan och AcrPull-behörighet i Azure Container Registry (ACR) för arbetsytan. Kontrollera att din användartilldelade identitet har rätt behörighet.

Mer information finns i Auktoriseringsfel för containerregister.

Ogiltig funktionsspecifikation för mallar

Det här felet uppstår när en mallfunktion angavs felaktigt. Åtgärda principen eller ta bort principtilldelningen för att avblockera. Felmeddelandet kan innehålla namnet på principtilldelningen och principdefinitionen som hjälper dig att felsöka det här felet, samt artikeln om azure-principdefinitionsstrukturen, där tips beskrivs för att undvika mallfel.

Det går inte att ladda ner användarcontaineravbildningen

Det är möjligt att det inte gick att hitta användarcontainern. Kontrollera containerloggarna för att få mer information.

Kontrollera att containeravbildningen är tillgänglig i arbetsytans ACR.

Om avbildningen till exempel kontrolleras testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest på lagringsplatsen med az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table.

Det gick inte att ladda ner användarmodellen

Det är möjligt att användarens modell inte kan hittas. Kontrollera containerloggarna för att få mer information.

Kontrollera om du har registrerat modellen på samma arbetsyta som distributionen. Så här visar du information om en modell på en arbetsyta:

az ml model show --name <model-name> --version <version>

Varning

Du måste ange antingen version eller etikett för att hämta modellens information.

Du kan också kontrollera om blobarna finns i arbetsytans lagringskonto.

  • Om bloben till exempel är https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pklkan du använda det här kommandot för att kontrollera om den finns:

    az storage blob exists --account-name foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`

  • Om bloben finns kan du använda det här kommandot för att hämta loggarna från lagringsinitieraren:

    az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`

MLFlow-modellformat med privat nätverk stöds inte

Det här felet inträffar när du försöker distribuera en MLflow-modell med en distributionsmetod utan kod tillsammans med den äldre metoden för nätverksisolering för hanterade onlineslutpunkter. Den här privata nätverksfunktionen kan inte användas tillsammans med ett MLFlow-modellformat om du använder den äldre metoden för nätverksisolering. Om du behöver distribuera en MLflow-modell med distributionsmetoden utan kod kan du prova att använda arbetsytans hanterade virtuella nätverk.

Resursbegäranden som är större än gränserna

Begäranden om resurser måste vara mindre än eller lika med gränser. Om du inte anger gränser anger vi standardvärden när du kopplar din beräkning till en Azure Machine Learning-arbetsyta. Du kan kontrollera gränserna i Azure-portalen eller med hjälp az ml compute show av kommandot .

azureml-fe inte redo

Klientdelskomponenten (azureml-fe) som dirigerar inkommande slutsatsdragningsbegäranden till distribuerade tjänster skalar automatiskt efter behov. Den installeras under installationen av k8s-tillägget.

Den här komponenten bör vara felfri i klustret, minst en felfri replik. Du får det här felmeddelandet om det inte är tillgängligt när du utlöser kubernetes onlineslutpunkt och begäran om att skapa/uppdatera distribution.

Kontrollera poddstatusen och loggarna för att åtgärda det här problemet. Du kan också försöka uppdatera k8s-tillägget som är installerat i klustret.

FEL: ResourceNotReady

För att köra den tillhandahållna score.py som en del av distributionen skapar Azure en container som innehåller alla resurser som score.py behövs och kör bedömningsskriptet på containern. Felet i det här scenariot är att containern kraschar när den körs, vilket innebär att poängsättning inte kan inträffa. Det här felet inträffar när:

  • Det finns ett fel i score.py. Använd get-logs för att diagnostisera vanliga problem:
    • Ett paket som score.py försöker importera ingår inte i conda-miljön.
    • Ett syntaxfel.
    • Ett fel i init() metoden.
  • Om get-logs inga loggar skapas innebär det vanligtvis att containern inte har startats. Om du vill felsöka det här problemet kan du prova att distribuera lokalt i stället.
  • Beredskaps- eller livenessavsökningar har inte konfigurerats korrekt.
  • Containerinitiering tar för lång tid så att beredskaps- eller livenessavsökningen misslyckas utöver tröskelvärdet för fel. I det här fallet justerar du avsökningsinställningarna så att det går längre tid att initiera containern. Eller prova en större VM SKU bland vm-SKU:er som stöds, vilket påskyndar initieringen.
  • Det finns ett fel i miljökonfigurationen av containern, till exempel ett beroende som saknas.
  • När du får TypeError: register() takes 3 positional arguments but 4 were given felet kontrollerar du beroendet mellan flask v2 och azureml-inference-server-http. Mer information finns i Vanliga frågor och svar om slutsatsdragning av HTTP-server.

FEL: ResourceNotFound

Följande lista är av orsaker till att du bara kan stöta på det här felet när du använder antingen hanterad onlineslutpunkt eller Kubernetes onlineslutpunkt:

Resource Manager kan inte hitta en resurs

Det här felet uppstår när Azure Resource Manager inte kan hitta en nödvändig resurs. Du kan till exempel få det här felet om ett lagringskonto har hänvisats till men inte kan hittas på den sökväg där det angavs. Se till att dubbelkolla resurser som kan ha angetts av den exakta sökvägen eller stavningen av deras namn.

Mer information finns i Lösa fel som inte hittades i resursen.

Auktoriseringsfel för containerregister

Det här felet uppstår när en avbildning som tillhör ett privat eller på annat sätt otillgängligt containerregister har angetts för distribution. För närvarande kan våra API:er inte acceptera autentiseringsuppgifter för privata register.

För att åtgärda det här felet kontrollerar du antingen att containerregistret inte är privat eller följer följande steg:

  1. Ge ditt privata register acrPull rollen till systemidentiteten för din onlineslutpunkt.
  2. I miljödefinitionen anger du adressen till den privata avbildningen och instruktionen att inte ändra (skapa) avbildningen.

Om åtgärden lyckas behöver inte avbildningen byggas och den slutliga avbildningsadressen är den angivna avbildningsadressen. Vid distributionen hämtar onlineslutpunktens systemidentitet avbildningen från det privata registret.

Mer diagnostikinformation finns i Använda API:et för arbetsytediagnostik.

FEL: OperationCanceled

Följande lista är av orsaker till att du kan stöta på det här felet när du använder antingen hanterad onlineslutpunkt eller Kubernetes onlineslutpunkt:

Åtgärden avbröts av en annan åtgärd med högre prioritet

Azure-åtgärder har en viss prioritetsnivå och körs från högsta till lägsta. Det här felet inträffar när åtgärden åsidosätts av en annan åtgärd som har högre prioritet.

Om du försöker utföra åtgärden igen kan den utföras utan annullering.

Åtgärden avbröts i väntan på låsbekräftelse

Azure-åtgärder har en kort väntetid efter att ha skickats in under vilken de hämtar ett lås för att säkerställa att vi inte stöter på konkurrensförhållanden. Det här felet inträffar när åtgärden du skickade är densamma som en annan åtgärd. Den andra åtgärden väntar för närvarande på att bekräfta att låset har tagits emot för att fortsätta. Det kan tyda på att du har skickat en liknande begäran för tidigt efter den första begäran.

Om du försöker utföra åtgärden igen efter att ha väntat i flera sekunder upp till en minut kan den utföras utan annullering.

FEL: SecretsInjectionError

Hemlig hämtning och inmatning när onlinedistributionen skapas använder identiteten som är associerad med onlineslutpunkten för att hämta hemligheter från arbetsyteanslutningarna och/eller nyckelvalv. Det här felet inträffar när:

  • Slutpunktsidentiteten har inte Azure RBAC-behörighet att läsa hemligheterna från arbetsytans anslutningar och/eller nyckelvalv, även om hemligheterna angavs av distributionsdefinitionen som referenser (mappade till miljövariabler). Kom ihåg att rolltilldelningen kan ta tid innan ändringarna börjar gälla.
  • Formatet för de hemliga referenserna är ogiltigt eller så finns inte de angivna hemligheterna i arbetsytans anslutningar och/eller nyckelvalv.

Mer information finns i Hemlig inmatning i onlineslutpunkter (förhandsversion) och Åtkomst till hemligheter från onlinedistribution med hjälp av hemlig inmatning (förhandsversion).

FEL: InternalServerError

Även om vi gör vårt bästa för att tillhandahålla en stabil och tillförlitlig tjänst, går det ibland inte enligt plan. Om du får det här felet innebär det att något inte är rätt på vår sida, och vi måste åtgärda det. Skicka ett kundsupportärende med all relaterad information så kan vi åtgärda problemet.

Vanliga fel som är specifika för Kubernetes-distributioner

Fel som rör identitet och autentisering:

Fel som gäller crashloopbackoff:

Fel som rör bedömningsskript:

Övrigt:

FEL: ACRSecretError

Följande lista är av orsaker till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlinedistributioner:

  • Rolltilldelningen har inte slutförts. I det här fallet väntar du några sekunder och försöker igen senare.
  • Azure ARC (för Azure Arc Kubernetes-klustret) eller Azure Machine Learning-tillägget (för AKS) är inte korrekt installerat eller konfigurerat. Försök att kontrollera konfigurationen och statusen för Azure ARC- eller Azure Machine Learning-tillägget.
  • Kubernetes-klustret har felaktig nätverkskonfiguration, kontrollera proxyn, nätverksprincipen eller certifikatet.
    • Om du använder ett privat AKS-kluster är det nödvändigt att konfigurera privata slutpunkter för ACR, lagringskonto och arbetsyta i det virtuella AKS-nätverket.
  • Kontrollera att azure Machine Learning-tilläggsversionen är större än v1.1.25.

FEL: TokenRefreshFailed

Det här felet beror på att tillägget inte kan hämta huvudautentiseringsuppgifter från Azure eftersom Kubernetes-klusteridentiteten inte har angetts korrekt. Installera om Azure Machine Learning-tillägget och försök igen.

FEL: GetAADTokenFailed

Det här felet beror på att Kubernetes-klusterbegärans Azure AD-token misslyckades eller tidsgränsen översågs. Kontrollera nätverkstillgängligheten och försök sedan igen.

  • Du kan följa konfigurera nödvändig nätverkstrafik för att kontrollera den utgående proxyn och kontrollera att klustret kan ansluta till arbetsytan.
  • Url:en för arbetsytans slutpunkt finns i onlineslutpunktens CRD i klustret.

Om din arbetsyta är en privat arbetsyta, som inaktiverade åtkomsten till det offentliga nätverket, bör Kubernetes-klustret endast kommunicera med den privata arbetsytan via den privata länken.

  • Du kan kontrollera om åtkomsten till arbetsytan tillåter offentlig åtkomst, oavsett om ett AKS-kluster självt är offentligt eller privat, kan det inte komma åt den privata arbetsytan.
  • Mer information finns i Säker Azure Kubernetes Service-inferensmiljö

FEL: ACRAuthenticationChallengeFailed

Det här felet beror på att Kubernetes-klustret inte kan nå ACR-tjänsten på arbetsytan för att utföra autentiseringsutmaningen. Kontrollera nätverket, särskilt åtkomsten till det offentliga ACR-nätverket, och försök sedan igen.

Du kan följa felsökningsstegen i GetAADTokenFailed för att kontrollera nätverket.

FEL: ACRTokenExchangeFailed

Det här felet beror på att Kubernetes-klusterutbytets ACR-token misslyckades eftersom Azure AD-token ännu inte har auktoriserats. Eftersom rolltilldelningen tar lite tid kan du vänta en stund och sedan försöka igen.

Det här felet kan också bero på för många begäranden till ACR-tjänsten vid den tidpunkten, det bör vara ett tillfälligt fel, du kan försöka igen senare.

FEL: KubernetesUnaccessible

Du kan få följande fel under Kubernetes-modelldistributionerna:

{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}

Du kan åtgärda det här felet genom att:

FEL: ImagePullLoopBackOff

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlinedistributioner är att du inte kan ladda ned avbildningarna från containerregistret, vilket resulterar i hämtningsfelet för avbildningar.

I det här fallet kan du kontrollera klusternätverksprincipen och arbetsytans containerregister om klustret kan hämta avbildningen från containerregistret.

FEL: DeploymentCrashLoopBackOff

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlinedistributioner är att användarcontainern kraschade initieringen. Det finns två möjliga orsaker till det här felet:

  • Användarskriptet score.py har syntaxfel eller importfel och skapar sedan undantag vid initiering.
  • Eller så behöver distributionspodden mer minne än gränsen.

För att åtgärda det här felet kan du först kontrollera om det finns några undantag i användarskripten i distributionsloggarna. Om felet kvarstår kan du försöka utöka minnesgränsen för resurser/instanstyp.

FEL: KubernetesCrashLoopBackOff

Följande lista är av orsaker till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlineslutpunkter/distributioner:

  • En eller flera poddar har fastnat i CrashLoopBackoff-status. Du kan kontrollera om distributionsloggen finns och kontrollera om det finns felmeddelanden i loggen.
  • Det finns ett fel i score.py och containern kraschade när du angav din poängkod, du kan följa FEL: ResourceNotReady-delen .
  • Din bedömningsprocess behöver mer minne än din distributionskonfigurationsgräns är otillräcklig. Du kan försöka uppdatera distributionen med en större minnesgräns.

FEL: NamespaceNotFound

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlineslutpunkter är att den namnrymd som kubernetes-beräkningen använde inte är tillgänglig i klustret.

Du kan kontrollera Kubernetes-beräkningen i arbetsyteportalen och kontrollera namnområdet i Kubernetes-klustret. Om namnområdet inte är tillgängligt kan du koppla från den äldre beräkningen och koppla från den igen för att skapa en ny, och ange ett namnområde som redan finns i klustret.

FEL: UserScriptInitFailed

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlinedistributioner är att init-funktionen i den uppladdade score.py filen genererade undantaget.

Du kan kontrollera distributionsloggarna för att se undantagsmeddelandet i detalj och åtgärda undantaget.

FEL: UserScriptImportError

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlinedistributioner är att score.py filen som du laddade upp har importerat otillgängliga paket.

Du kan kontrollera distributionsloggarna för att se undantagsmeddelandet i detalj och åtgärda undantaget.

FEL: UserScriptFunctionNotFound

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlinedistributioner är att score.py filen som du laddade upp inte har någon funktion med namnet init() eller run(). Du kan kontrollera koden och lägga till funktionen.

FEL: EndpointNotFound

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlinedistributioner är att systemet inte kan hitta slutpunktsresursen för distributionen i klustret. Du bör skapa distributionen i en befintlig slutpunkt eller skapa den här slutpunkten först i klustret.

FEL: EndpointAlreadyExists

Anledningen till att du kan stöta på det här felet när du skapar en Kubernetes online-slutpunkt är att den skapande slutpunkten redan finns i klustret.

Slutpunktsnamnet ska vara unikt per arbetsyta och kluster, så i det här fallet bör du skapa en slutpunkt med ett annat namn.

FEL: ScoringFeUnhealthy

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar en Kubernetes online-slutpunkt/distribution är att Den Azureml-fe som är systemtjänsten som körs i klustret inte hittas eller är felfri.

Om du vill felsöka det här problemet kan du installera om eller uppdatera Azure Machine Learning-tillägget i klustret.

FEL: ValidateScoringFailed

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlinedistributioner är att valideringen av bedömningsbegärande-URL:en misslyckades när modellen distribueras.

I det här fallet kan du först kontrollera slutpunkts-URL:en och sedan försöka distribuera om distributionen.

FEL: InvalidDeploymentSpec

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlinedistributioner är att distributionsspecifikationen är ogiltig.

I det här fallet kan du kontrollera felmeddelandet.

  • Kontrollera att är instance count giltig.
  • Om du har aktiverat automatisk skalning kontrollerar du att minimum instance count båda maximum instance count är giltiga.

FEL: PodUnschedulable

Följande lista är av orsaker till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlineslutpunkter/distributioner:

  • Det går inte att schemalägga podden till noder på grund av otillräckliga resurser i klustret.
  • Ingen nod matchar nodtillhörighet/väljare.

Du kan åtgärda det här felet genom att följa dessa steg:

  • node selector Kontrollera definitionen av du instance type använde och node label konfigurationen av dina klusternoder.
  • Kontrollera instance type och nod-SKU-storleken för AKS-klustret eller nodresursen för Arc-Kubernetes-klustret.
    • Om klustret är underbebyggt kan du minska resurskravet för instanstypen eller använda en annan instanstyp med mindre resurs som krävs.
  • Om klustret inte har någon mer resurs för att uppfylla kraven för distributionen tar du bort en del distribution för att frigöra resurser.

FEL: PodOutOfMemory

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar onlinedistributionen är den minnesgräns som du ger för distributionen är otillräcklig. Du kan ange minnesgränsen till ett större värde eller använda en större instanstyp för att åtgärda det här felet.

FEL: SlutsatsdragningClientCallFailed

Anledningen till att du kan stöta på det här felet när du skapar/uppdaterar Kubernetes onlineslutpunkter/distributioner är att k8s-tillägget för Kubernetes-klustret inte kan anslutas.

I det här fallet kan du koppla från och sedan koppla om beräkningen.

Kommentar

Om du vill felsöka fel genom att ansluta igen kan du garantera att återansluta med exakt samma konfiguration som tidigare frånkopplad beräkning, till exempel samma beräkningsnamn och namnområde, annars kan det uppstå andra fel.

Om det fortfarande inte fungerar kan du be administratören som har åtkomst till klustret att använda kubectl get po -n azureml för att kontrollera om reläserverpoddarna körs.

Problem med automatisk skalning

Om du har problem med automatisk skalning kan du läsa Felsöka autoskalning i Azure.

För Kubernetes onlineslutpunkt finns en Azure Machine Learning-slutsatsdragningsrouter som är en klientdelskomponent för att hantera autoskalning för alla modelldistributioner i Kubernetes-klustret. Mer information finns i Autoskalning av Kubernetes-slutsatsdragningsroutning

Vanliga fel vid modellförbrukning

Följande lista är av vanliga modellförbrukningsfel som beror på slutpunktsåtgärdens invoke status.

Problem med bandbreddsbegränsning

Hanterade onlineslutpunkter har bandbreddsgränser för varje slutpunkt. Du hittar gränskonfigurationen i gränser för onlineslutpunkter. Om bandbreddsanvändningen överskrider gränsen fördröjs din begäran. Så här övervakar du bandbreddsfördröjningen:

  • Använd måttet "Nätverksbyte" för att förstå den aktuella bandbreddsanvändningen. Mer information finns i Övervaka hanterade onlineslutpunkter.
  • Det finns två svarstrailer som returneras om bandbreddsgränsen tillämpas:
    • ms-azureml-bandwidth-request-delay-ms: fördröjningstid i millisekunder som det tog för överföringen av begärandeströmmen.
    • ms-azureml-bandwidth-response-delay-ms: fördröjningstid i millisekunder som det tog för överföringen av svarsströmmen.

HTTP-statuskoder

När du kommer åt onlineslutpunkter med REST-begäranden följer de returnerade statuskoderna standarderna för HTTP-statuskoder. Det här är information om hur slutpunktsanrop och förutsägelsefel mappas till HTTP-statuskoder.

Vanliga felkoder för hanterade onlineslutpunkter

Följande tabell innehåller vanliga felkoder när hanterade onlineslutpunkter används med REST-begäranden:

Statuskod Orsaksfras Varför den här koden kan returneras
200 OK Din modell har körts inom din svarstidsgräns.
401 Behörighet saknas Du har inte behörighet att utföra den begärda åtgärden, till exempel poäng, eller så har din token upphört att gälla eller i fel format. Mer information finns i begreppet slutpunktsautentisering och hur du autentiserar för slutpunkten.
404 Hittades inte Slutpunkten har ingen giltig distribution med positiv vikt.
408 Timeout för begäran Modellkörningen tog längre tid än den tidsgräns som angavs i request_timeout_msrequest_settings konfigurationen för modelldistributionen.
424 Modellfel Om din modellcontainer returnerar ett svar som inte är 200 returnerar Azure 424. Kontrollera dimensionen Model Status Code under måttet Requests Per Minute i slutpunktens Azure Monitor Metric Explorer. Eller kontrollera svarshuvuden ms-azureml-model-error-statuscode och ms-azureml-model-error-reason mer information. Om 424 levereras med att liveness- eller beredskapsavsökningen misslyckas kan du överväga att justera avsökningsinställningarna så att det tar längre tid att avsöka containerns livslängd eller beredskap.
429 För många väntande begäranden Din modell får för närvarande fler begäranden än den kan hantera. Azure Machine Learning har implementerat ett system som tillåter att maximalt 2 * max_concurrent_requests_per_instance * instance_count requests bearbetas parallellt vid varje given tidpunkt för att garantera smidig drift. Andra begäranden som överskrider det här maxvärdet avvisas. Du kan granska konfigurationen av modelldistributionen under avsnitten request_settings och scale_settings för att verifiera och justera dessa inställningar. Dessutom, som beskrivs i YAML-definitionen för Begäran Inställningar, är det viktigt att se till att miljövariabeln WORKER_COUNT skickas korrekt.

Om du använder automatisk skalning och får det här felet innebär det att din modell får förfrågningar snabbare än systemet kan skala upp. I den här situationen bör du överväga att skicka begäranden igen med en exponentiell backoff för att ge systemet den tid det behöver justeras. Du kan också öka antalet instanser med hjälp av kod för att beräkna antalet instanser. Dessa steg, i kombination med inställning av autoskalning, hjälper till att säkerställa att din modell är redo att hantera tillströmningen av begäranden.
429 Hastighetsbegränsad Antalet begäranden per sekund nådde gränserna för hanterade onlineslutpunkter.
500 Internt serverfel. Azure Machine Learning-etablerad infrastruktur misslyckas.

Vanliga felkoder för kubernetes onlineslutpunkter

Följande tabell innehåller vanliga felkoder när kubernetes onlineslutpunkter används med REST-begäranden:

Statuskod Orsaksfras Varför den här koden kan returneras
409 Konfliktfel När en åtgärd redan pågår svarar alla nya åtgärder på samma onlineslutpunkt med 409-konfliktfel. Om du till exempel skapar eller uppdaterar onlineslutpunktsåtgärden pågår och om du utlöser en ny borttagningsåtgärd utlöser den ett fel.
502 Har genererat ett undantag eller kraschat i run() metoden för score.py-filen När det finns ett fel i score.pyfinns till exempel inte ett importerat paket i conda-miljön, ett syntaxfel eller ett fel i init() metoden. Du kan följa här för att felsöka filen.
503 Ta emot stora toppar i begäranden per sekund Autoskalningen är utformad för att hantera gradvisa belastningsändringar. Om du får stora toppar i begäranden per sekund kan klienterna få http-statuskoden 503. Även om autoskalningen reagerar snabbt tar det lång tid för AKS att skapa fler containrar. Du kan följa här för att förhindra 503-statuskoder.
504 Tidsgränsen för begäran har överskrids En 504-statuskod anger att begäran har överskriden tidsgräns. Standardinställningen för timeout är 5 sekunder. Du kan öka tidsgränsen eller försöka påskynda slutpunkten genom att ändra score.py för att ta bort onödiga anrop. Om dessa åtgärder inte åtgärdar problemet kan du följa här för att felsöka score.py-filen. Koden kan vara i ett icke-svarstillstånd eller en oändlig loop.
500 Internt serverfel. Azure Machine Learning-etablerad infrastruktur misslyckas.

Så här förhindrar du 503-statuskoder

Kubernetes onlinedistributioner stöder automatisk skalning, vilket gör att repliker kan läggas till för extra belastning. Mer information finns i Azure Machine Learning-slutsatsdragningsrouter. Beslut om att skala upp/ned baseras på användningen av de aktuella containerreplikerna.

Det finns två saker som kan hjälpa dig att förhindra 503-statuskoder:

Dricks

Dessa två metoder kan användas individuellt eller i kombination.

  • Ändra användningsnivån där autoskalning skapar nya repliker. Du kan justera användningsmålet genom att ange autoscale_target_utilization ett lägre värde.

    Viktigt!

    Den här ändringen gör inte att repliker skapas snabbare. I stället skapas de med ett lägre användningströskelvärde. I stället för att vänta tills tjänsten används till 70 % skapas repliker när 30 % användning sker när värdet ändras till 30 %.

    Om Kubernetes onlineslutpunkt redan använder de aktuella maxreplikerna och du fortfarande ser 503 statuskoder ökar autoscale_max_replicas du värdet för att öka det maximala antalet repliker.

  • Ändra det minsta antalet repliker. Om du ökar minimireplikerna får du en större pool för att hantera inkommande toppar.

    Om du vill öka antalet instanser kan du beräkna de repliker som krävs enligt dessa koder.

    from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

    Kommentar

    Om du får toppar för begäranden som är större än de nya minsta replikerna kan hantera kan du få 503 igen. När trafiken till slutpunkten till exempel ökar kan du behöva öka de minsta replikerna.

Så här beräknar du antal instanser

Om du vill öka antalet instanser kan du beräkna de repliker som krävs med hjälp av följande kod:

from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

Blockerad av CORS-princip

Onlineslutpunkter (v2) stöder för närvarande inte CORS (Cross-Origin Resource Sharing ) internt. Om ditt webbprogram försöker anropa slutpunkten utan korrekt hantering av CORS-begäranden kan du se följande felmeddelande:

Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.

Vi rekommenderar att du använder Azure Functions, Azure Application Gateway eller någon tjänst som ett mellanliggande lager för att hantera CORS-förhandsbegäranden.

Vanliga problem med nätverksisolering

Det går inte att skapa en onlineslutpunkt med meddelandet V1LegacyMode == true

Azure Machine Learning-arbetsytan kan konfigureras för v1_legacy_mode, vilket inaktiverar v2-API:er. Hanterade onlineslutpunkter är en funktion i v2 API-plattformen och fungerar inte om v1_legacy_mode är aktiverat för arbetsytan.

Viktigt!

Kontakta nätverkssäkerhetsteamet innan du inaktiverar v1_legacy_mode. Det kan ha aktiverats av nätverkssäkerhetsteamet av en anledning.

Information om hur du inaktiverar finns v1_legacy_modei Nätverksisolering med v2.

Det går inte att skapa en onlineslutpunkt med nyckelbaserad autentisering

Använd följande kommando för att visa nätverksreglerna för Azure Key Vault för din arbetsyta. Ersätt <keyvault-name> med namnet på ditt nyckelvalv:

az keyvault network-rule list -n <keyvault-name>

Svaret för det här kommandot liknar följande JSON-dokument:

{
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [],
    "virtualNetworkRules": []
}

Om värdet för inte AzureServicesär använder du vägledningen i Konfigurera nätverksinställningar för nyckelvalvet för att ange det till AzureServices.bypass

Onlinedistributioner misslyckas med ett nedladdningsfel för avbildningen

Kommentar

Det här problemet gäller när du använder den äldre metoden för nätverksisolering för hanterade onlineslutpunkter, där Azure Machine Learning skapar ett hanterat virtuellt nätverk för varje distribution under en slutpunkt.

  1. Kontrollera om egress-public-network-access flaggan är inaktiverad för distributionen. Om den här flaggan är aktiverad och synligheten för containerregistret är privat förväntas det här felet.

  2. Använd följande kommando för att kontrollera statusen för den privata slutpunktsanslutningen. Ersätt <registry-name> med namnet på Azure Container Registry för din arbetsyta:

    az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{Name:name, status:privateLinkServiceConnectionState.status}"

    I svarsdokumentet kontrollerar du att fältet är inställt på statusApproved. Om den inte är godkänd använder du följande kommando för att godkänna det. Ersätt <private-endpoint-name> med namnet som returnerades från föregående kommando:

    az network private-endpoint-connection approve -n <private-endpoint-name>

Det går inte att matcha poängslutpunkten

  1. Kontrollera att klienten som utfärdar bedömningsbegäran är ett virtuellt nätverk som har åtkomst till Azure Machine Learning-arbetsytan.

  2. nslookup Använd kommandot på slutpunktens värdnamn för att hämta IP-adressinformationen:

    nslookup endpointname.westcentralus.inference.ml.azure.com

    Svaret innehåller en adress. Den här adressen ska ligga i intervallet som tillhandahålls av det virtuella nätverket

    Kommentar

    För Kubernetes onlineslutpunkt ska slutpunktens värdnamn vara det CName (domännamn) som har angetts i kubernetes-klustret. Om det är en HTTP-slutpunkt finns IP-adressen i slutpunkts-URI:n som du kan hämta direkt i Studio-användargränssnittet. Fler sätt att hämta IP-adressen för slutpunkten finns i Säker Kubernetes onlineslutpunkt.

  3. Om värdnamnet inte matchas av nslookup kommandot:

    För Hanterad onlineslutpunkt,

    1. Kontrollera om det finns en A-post i den privata DNS-zonen för det virtuella nätverket.

      Om du vill kontrollera posterna använder du följande kommando:

      az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name

      Resultatet ska innehålla en post som liknar *.<GUID>.inference.<region>.

    2. Om inget slutsatsvärde returneras tar du bort den privata slutpunkten för arbetsytan och återskapar den. Mer information finns i Konfigurera en privat slutpunkt.

    3. Om arbetsytan med en privat slutpunkt konfigureras med en anpassad DNS Så här använder du din arbetsyta med en anpassad DNS-server, använd följande kommando för att kontrollera om matchningen fungerar korrekt från anpassad DNS.

      dig endpointname.westcentralus.inference.ml.azure.com

    För Kubernetes onlineslutpunkt,

    1. Kontrollera DNS-konfigurationen i Kubernetes-klustret.

    2. Dessutom kan du kontrollera om azureml-fe fungerar som förväntat med följande kommando:

      kubectl exec -it deploy/azureml-fe -- /bin/bash
(Run in azureml-fe pod)

curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

      För HTTP använder du

      curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

    Om curl HTTPs misslyckas (t.ex. tidsgräns) men HTTP fungerar kontrollerar du att certifikatet är giltigt.

    Om det inte går att matcha A-posten kontrollerar du om lösningen fungerar från Azure DNS(168.63.129.16).

    dig @168.63.129.16 endpointname.westcentralus.inference.ml.azure.com

    Om detta lyckas kan du felsöka villkorsstyrd vidarebefordrare för privat länk i anpassad DNS.

Det går inte att poängsätta onlinedistributioner

  1. Använd följande kommando för att se om distributionen har distribuerats:

    az ml online-deployment show -e <endpointname> -n <deploymentname> --query '{name:name,state:provisioning_state}'

    Om distributionen har slutförts blir Succeededvärdet state för .

  2. Om distributionen lyckades använder du följande kommando för att kontrollera att trafiken har tilldelats till distributionen. Ersätt <endpointname> med namnet på slutpunkten:

    az ml online-endpoint show -n <endpointname>  --query traffic

    Dricks

    Det här steget behövs inte om du använder azureml-model-deployment huvudet i din begäran för att rikta in dig på den här distributionen.

    Svaret från det här kommandot bör visa en lista över procentandelen trafik som tilldelats distributioner.

  3. Om trafiktilldelningarna (eller distributionshuvudet) har angetts korrekt använder du följande kommando för att hämta loggarna för slutpunkten. Ersätt <endpointname> med namnet på slutpunkten och <deploymentname> med distributionen:

    az ml online-deployment get-logs  -e <endpointname> -n <deploymentname>

    Titta igenom loggarna för att se om det är problem med att köra poängkoden när du skickar en begäran till distributionen.

Felsöka slutsatsdragningsserver

I det här avsnittet tillhandahåller vi grundläggande felsökningstips för HTTP-server för Azure Machine Learning-slutsatsdragning.

Grundläggande steg

De grundläggande stegen för felsökning är:

  1. Samla in versionsinformation för din Python-miljö.
  2. Kontrollera att python-paketversionen azureml-inference-server-http som anges i miljöfilen matchar den AzureML-slutsatsdragning av HTTP-serverversionen som visas i startloggen. Ibland leder PIP:s beroendelösare till oväntade versioner av installerade paket.
  3. Om du anger Flask (och eller dess beroenden) i din miljö tar du bort dem. Beroendena omfattar Flask, Jinja2, itsdangerous, Werkzeug, MarkupSafeoch click. Flask visas som ett beroende i serverpaketet och det är bäst att låta servern installera det. På så sätt får du dem automatiskt när servern stöder nya versioner av Flask.

Serverversion

Serverpaketet azureml-inference-server-http publiceras till PyPI. Du hittar vår ändringslogg och alla tidigare versioner på vår PyPI-sida. Uppdatera till den senaste versionen om du använder en tidigare version.

  • 0.4.x: Den version som paketeras i träningsbilder ≤ 20220601 och i azureml-defaults>=1.34,<=1.43. 0.4.13 är den senaste stabila versionen. Om du använder servern före versionen 0.4.11kan flaskberoendeproblem som inte kan importera namn Markup från jinja2visas. Du rekommenderas att uppgradera till 0.4.13 eller 0.8.x (den senaste versionen) om möjligt.
  • 0.6.x: Den version som är förinstallerad i slutsatsdragningsbilder ≤ 20220516. Den senaste stabila versionen är 0.6.1.
  • 0.7.x: Den första versionen som stöder Flask 2. Den senaste stabila versionen är 0.7.7.
  • 0.8.x: Loggformatet har ändrats och Python 3.6-stödet har tagits bort.

Paketberoenden

De mest relevanta paketen för servern azureml-inference-server-http är följande paket:

  • Kolven
  • opencensus-ext-azure
  • inference-schema

Om du har angett azureml-defaults i Python-miljön azureml-inference-server-http är paketet beroende av och installeras automatiskt.

Dricks

Om du använder Python SDK v1 och inte uttryckligen anger azureml-defaults i Python-miljön kan SDK:t lägga till paketet åt dig. Den låser dock den till den version som SDK:et är på. Om SDK-versionen till exempel är 1.38.0lägger den till azureml-defaults==1.38.0 i miljöns pip-krav.

Vanliga frågor och svar

1. Jag stötte på följande fel under serverstarten:


TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

Du har Flask 2 installerat i python-miljön men kör en version av azureml-inference-server-http som inte stöder Flask 2. Stöd för Flask 2 läggs till i azureml-inference-server-http>=0.7.0, som också finns i azureml-defaults>=1.44.

  • Om du inte använder det här paketet i en AzureML docker-avbildning använder du den senaste versionen av azureml-inference-server-http eller azureml-defaults.

  • Om du använder det här paketet med en AzureML docker-avbildning kontrollerar du att du använder en avbildning som är inbyggd i eller efter juli 2022. Avbildningsversionen är tillgänglig i containerloggarna. Du bör kunna hitta en logg som liknar följande:

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materializaton Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    Byggdatumet för avbildningen visas efter "Materialiseringsversion", som i exemplet ovan är 20220708, eller 8 juli 2022. Den här bilden är kompatibel med Flask 2. Om du inte ser en banderoll som den här i containerloggen är avbildningen inaktuell och bör uppdateras. Om du använder en CUDA-avbildning och inte kan hitta en nyare avbildning kontrollerar du om avbildningen är inaktuell i AzureML-Containers. Om det är det bör du kunna hitta ersättningar.

  • Om du använder servern med en onlineslutpunkt kan du även hitta loggarna under "Distributionsloggar" på onlineslutpunktssidan i Azure Machine Learning-studio. Om du distribuerar med SDK v1 och inte uttryckligen anger en avbildning i distributionskonfigurationen kommer den som standard att använda en version av openmpi4.1.0-ubuntu20.04 som matchar din lokala SDK-verktygsuppsättning, som kanske inte är den senaste versionen av avbildningen. SDK 1.43 använder till openmpi4.1.0-ubuntu20.04:20220616exempel som standard , vilket är inkompatibelt. Se till att du använder den senaste SDK:t för distributionen.

  • Om du av någon anledning inte kan uppdatera avbildningen kan du tillfälligt undvika problemet genom att fästa azureml-defaults==1.43 eller azureml-inference-server-http~=0.4.13, som installerar den äldre versionsservern med Flask 1.0.x.

2. Jag stötte på en ImportError eller ModuleNotFoundError på moduler opencensus, jinja2, MarkupSafe, eller click under start som följande meddelande:

ImportError: cannot import name 'Markup' from 'jinja2'

Äldre versioner (<= 0.4.10) av servern fäster inte Flasks beroende på kompatibla versioner. Det här problemet har åtgärdats i den senaste versionen av servern.

Nästa steg