Dela via

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)

Den här artikeln beskriver hur du felsöker och löser vanliga problem med distribution och bedömning av slutpunkter i Azure Machine Learning online.

Dokumentstrukturen visar hur du bör hantera 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.

I avsnittet HTTP-statuskoder beskrivs hur anrops- och förutsägelsefel mappas till HTTP-statuskoder när du poängsätta slutpunkter med REST-begäranden.

Förutsättningar

Spårning av begäranden

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

  • x-request-id är reserverad för serverspårning. Azure Machine Learning åsidosätter det här huvudet för att säkerställa att det är ett giltigt GUID. 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. Alternativt kan du ange namnet på regionen och slutpunktsnamnet.

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

Distribuera lokalt

Lokal distribution innebär att distribuera en modell till en lokal Docker-miljö. Lokal distribution stöder skapande, uppdatering och borttagning av en lokal slutpunkt och gör att du kan anropa och hämta loggar från slutpunkten. 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-inferensen HTTP Server Python-paketet 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.

Du kan distribuera lokalt med Azure CLI eller Python SDK. Azure Machine Learning-studio stöder inte lokal distribution eller lokala slutpunkter.

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

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

Följande steg utförs under den lokala distributionen:

  1. Docker skapar antingen en ny containeravbildning eller hämtar en befintlig avbildning från den lokala Docker-cachen. Docker använder en befintlig avbildning om den matchar miljödelen av specifikationsfilen.
  2. Docker startar den nya containern med monterade lokala artefakter som modell- och kodfiler.

Mer information finns i Distribuera och felsöka lokalt med hjälp av en lokal slutpunkt.

Dricks

Du kan använda Visual Studio Code för att testa och felsöka dina slutpunkter lokalt. Mer information finns i Felsöka onlineslutpunkter lokalt i Visual Studio Code.

Hämta containerloggar

Du kan inte få direkt åtkomst till en virtuell dator (VM) där en modell distribueras, men du kan hämta loggar från några 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.

Du kan hämta loggar från följande typer av containrar:

  • Inferensserverkonsolloggen innehåller utdata från utskrifts- och loggningsfunktioner från ditt bedömningsskript score.py kod.
  • Loggar för lagringsinitierare innehåller information om huruvida kod- och modelldata har laddats ned till containern. Containern körs innan inferensservercontainern börjar köras.

För Kubernetes onlineslutpunkter kan administratörer direkt komma åt klustret där du distribuerar modellen och kontrollera loggarna i Kubernetes. Till exempel:

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

Kommentar

Om du använder Python-loggning ser du till att använda rätt loggningsnivå, till exempel INFO, för att meddelandena ska publiceras i loggar.

Se loggutdata från containrar

Om du vill se loggutdata från en container använder du följande 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

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

Lägg till --resource-group och --workspace-name till kommandona om du inte redan har angett dessa parametrar via az configure. Om du vill se information om hur du anger dessa parametrar, eller om du för närvarande har angett värden, kör du följande kommando:

az ml online-deployment get-logs -h

Om du vill se mer information lägger du till --help eller --debug i kommandon.

Vanliga distributionsfel

Distributionsåtgärdens status kan rapportera följande vanliga distributionsfel:

Om du skapar eller uppdaterar en Kubernetes-onlinedistribution kan du även läsa Vanliga fel som är specifika för Kubernetes-distributioner.

FEL: ImageBuildFailure

Det här felet returneras när Docker-avbildningsmiljön skapas. Du kan kontrollera byggloggen för mer information om felet. Byggloggen finns i standardlagringen för din Azure Machine Learning-arbetsyta.

Den exakta platsen kan returneras som en del av felet, till exempel "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

I följande avsnitt beskrivs vanliga scenarier med avbildningsfel:

Azure Container Registry-auktoriseringsfel

Ett felmeddelande anger "container registry authorization failure" när du inte kan komma åt containerregistret med aktuella autentiseringsuppgifter. Avsynkroniseringen av arbetsytans resursnycklar kan orsaka det här felet och det tar lite tid att synkronisera automatiskt. Du kan dock manuellt anropa för nyckelsynkronisering med az ml workspace sync-keys, vilket kan lösa auktoriseringsfelet.

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

Avbildningsgenereringsberäkning har inte angetts i en privat arbetsyta med virtuellt nätverk

Om felmeddelandet nämner "failed to communicate with the workspace's container registry", och du använder ett virtuellt nätverk och arbetsytans containerregister är privat och konfigurerat med en privat slutpunkt, måste du tillåta att Container Registry skapar avbildningar i det virtuella nätverket.

Tidsgräns för bildbygge

Tidsgränser för bildskapande beror ofta på att en avbildning är för stor för att kunna slutföra skapandet inom tidsramen för att skapa distributionen. Kontrollera dina avbildningsversionsloggar på den plats som felet anger. Loggarna är avskurna vid den tidpunkt då tidsgränsen för avbildningsversionen överskrids.

Lös problemet genom att skapa avbildningen separat så att avbildningen bara behöver hämtas när distributionen skapas. Granska även standardinställningarna för avsökning om du har ImageBuild-timeouter.

Fel vid generiska avbildningsversioner

Mer information om felet finns i byggloggen. 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.

Prova att distribuera lokalt för att testa och felsöka dina modeller innan du distribuerar till molnet.

FEL: OutOfQuota

Följande resurser kan få slut på kvot när du använder Azure-tjänster:

Endast för Kubernetes onlineslutpunkter kan Kubernetes-resursen också få slut på kvot.

CPU-kvot

Du måste ha tillräckligt med beräkningskvot för att distribuera en modell. CPU-kvoten definierar hur många 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.

Du kan 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

Felet OutOfQuota uppstår när du inte har tillräckligt med kvot för Azure Machine Learning-beräkningskluster. Kvoten definierar det totala antalet kluster per prenumeration som du kan använda samtidigt för att distribuera CPU- eller GPU-noder i Azure-molnet.

Diskkvot

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

Minneskvot

Felet OutOfQuota uppstår 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 du når gränsen för rolltilldelning kan du försöka ta bort några oanvända rolltilldelningar i den här prenumerationen. Du kan kontrollera alla rolltilldelningar genom att välja Åtkomstkontroll för din Azure-prenumeration i Azure Portal.

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

Felet OutOfQuota uppstår när den begärda processorn eller minnet inte kan anges 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 resursens otillräcklighet i klustret, till exempel OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Det här meddelandet 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.

Prova följande åtgärder för att åtgärda problemet:

  • IT-operatörer som underhåller Kubernetes-klustret kan försöka lägga till fler noder eller rensa vissa oanvända poddar i klustret för att frigöra vissa resurser.

  • Maskininlärningstekniker som distribuerar modeller kan 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 resursen för modelldistribution kontaktar du IT-operatorn för att justera resurskonfigurationen av instanstyp. Mer information finns i Skapa och hantera instanstyper.

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 score.py fil som du anger som en del av distributionen skapar Azure en container som innehåller alla resurser som score.py behöver. Azure Machine Learning kör sedan bedömningsskriptet i containern. Om containern inte kan starta kan poängsättning inte ske. Containern kan begära fler resurser än vad som kan stödjas instance_type . Överväg att instance_type uppdatera onlinedistributionen.

Utför följande åtgärd för att få den exakta orsaken till felet.

Kör följande kommando:

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

FEL: BadArgument

Du kan få det här felet när du använder antingen hanterade onlineslutpunkter eller Kubernetes onlineslutpunkter av följande skäl:

Du kan också få det här felet när du endast använder Kubernetes onlineslutpunkter av följande skäl:

Prenumerationen finns inte

Den refererade Azure-prenumerationen måste vara befintlig och aktiv. Det här felet uppstår när Azure inte hittar det prenumerations-ID som du angav. Felet kan bero på ett skrivfel i prenumerations-ID:t. Dubbelkolla att prenumerations-ID:t har angetts korrekt och är aktivt.

Auktoriseringsfel

När du har etablerat beräkningsresursen när du skapar en distribution hämtar Azure användarcontaineravbildningen från arbetsytans containerregister och monterar användarmodellen och kodartefakter i användarcontainern från arbetsytans lagringskonto. Azure använder hanterade identiteter för att komma åt lagringskontot och containerregistret.

Om du skapar den associerade slutpunkten med användartilldelad identitet måste användarens hanterade identitet ha behörighet att läsa lagringsblobdata för arbetsytans lagringskonto och AcrPull-behörighet i arbetsytans containerregister. Kontrollera att din användartilldelade identitet har rätt behörigheter.

Om du skapar den associerade slutpunkten med systemtilldelad identitet beviljas behörigheten Azure rollbaserad åtkomstkontroll (RBAC) automatiskt och inga ytterligare behörigheter behövs. 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. Se Definitionsstrukturen för Azure-principer för tips för att undvika mallfel.

Det går inte att ladda ner användarcontaineravbildningen

Det går kanske inte att hitta användarcontainern. Kontrollera containerloggarna för att få mer information.

Kontrollera att containeravbildningen är tillgänglig i arbetsytans containerregister. Om avbildningen till exempel är testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latestkan du använda följande kommando för att kontrollera lagringsplatsen:

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 går kanske inte att hitta användarmodellen. Kontrollera containerloggarna för att få mer information. Kontrollera att du har registrerat modellen på samma arbetsyta som distributionen.

Om du vill visa information om en modell på en arbetsyta vidtar du följande åtgärd. Du måste ange antingen version eller etikett för att hämta modellinformationen.

Kör följande kommando:

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

Kontrollera också 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 följande kommando för att kontrollera om bloben finns:

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

Om bloben finns kan du använda följande kommando 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

Du kan inte använda funktionen för privat nätverk med ett MLflow-modellformat om du använder den äldre metoden för nätverksisolering för hanterade onlineslutpunkter. Om du behöver distribuera en MLflow-modell med distributionsmetoden utan kod kan du prova att använda ett hanterat virtuellt nätverk på arbetsytan.

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 Azure Machine Learning standardvärden när du kopplar din beräkning till en arbetsyta. Du kan kontrollera gränserna i Azure Portal 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 installeras under installationen av k8s-tillägget och skalar automatiskt efter behov. Den här komponenten bör ha minst en felfri replik i klustret.

Du får det här felet om komponenten inte är tillgänglig när du utlöser en Kubernetes-slutpunkt online eller distributionsskapande eller uppdateringsbegäran. Kontrollera poddstatusen och loggarna för att åtgärda problemet. Du kan också försöka uppdatera k8s-tillägget som är installerat i klustret.

FEL: ResourceNotReady

För att köra den score.py fil som du anger som en del av distributionen skapar Azure en container som innehåller alla resurser som score.py behöver och kör bedömningsskriptet på containern. Felet i det här scenariot är att den här containern kraschar när den körs, så det går inte att göra någon bedömning. Det här felet kan inträffa under något av följande villkor:

  • Det finns ett fel i score.py. Använd get-logs för att diagnostisera vanliga problem, till exempel:

    • Ett paket som score.py försöker importera som inte ingår i conda-miljön
    • Ett syntaxfel
    • Ett fel i init() metoden

    Om get-logs inte skapar några loggar innebär det vanligtvis att containern inte kunde startas. Om du vill felsöka det här problemet kan du prova att distribuera lokalt.

  • Beredskaps- eller livenessavsökningar har inte konfigurerats korrekt.

  • Containerinitiering tar för lång tid, så beredskaps- eller liveness-avsökningen misslyckas utöver tröskelvärdet för fel. I det här fallet justerar du avsökningsinställningarna så att det kan ta längre tid att initiera containern. Eller prova en större vm-SKU som stöds, vilket påskyndar initieringen.

  • Det finns ett fel i konfigurationen av containermiljön, till exempel ett beroende som saknas.

    Om du får felet TypeError: register() takes 3 positional arguments but 4 were given kontrollerar du beroendet mellan flask v2 och azureml-inference-server-http. Mer information finns i Felsöka HTTP-serverproblem.

FEL: ResourceNotFound

Du kan få det här felet när du använder antingen hanterad onlineslutpunkt eller Kubernetes onlineslutpunkt av följande skäl:

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 inte kan hittas på den angivna sökvägen. Dubbelkolla sökvägs- eller namnspecifikationer för noggrannhet och stavning. Mer information finns i Lösa fel för Resurs hittades inte.

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 tillhandahålls för distribution. Azure Machine Learning-API:er kan 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 utför följande steg:

  1. Bevilja det privata registrets acrPull-roll till systemidentiteten för din onlineslutpunkt.
  2. I miljödefinitionen anger du adressen till den privata avbildningen och ger instruktionen att inte ändra eller skapa avbildningen.

Om den här å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 Så här använder du arbetsytediagnostik.

FEL: WorkspaceManagedNetworkNotReady

Det här felet uppstår om du försöker skapa en onlinedistribution som aktiverar ett hanterat virtuellt nätverk på arbetsytan, men det hanterade virtuella nätverket inte har etablerats ännu. Etablera det hanterade virtuella nätverket för arbetsytan innan du skapar en onlinedistribution.

Om du vill etablera arbetsytans hanterade virtuella nätverk manuellt följer du anvisningarna i Etablera ett hanterat virtuellt nätverk manuellt. Du kan sedan börja skapa onlinedistributioner. Mer information finns i Nätverksisolering med hanterad onlineslutpunkt och Skydda dina hanterade onlineslutpunkter med nätverksisolering.

FEL: OperationCanceled

Du kan få det här felet när du använder antingen hanterad onlineslutpunkt eller Kubernetes onlineslutpunkt av följande skäl:

Å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 en annan åtgärd med högre prioritet åsidosätter åtgärden. 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, under vilken de hämtar ett lås för att säkerställa att de 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å en bekräftelse på att låset har tagits emot innan det fortsätter.

Du kan ha 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 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 arbetsyteanslutningar eller nyckelvalv. Det här felet inträffar av någon av följande orsaker:

  • Slutpunktsidentiteten har inte Azure RBAC-behörighet att läsa hemligheterna från arbetsytans anslutningar eller nyckelvalv, även om distributionsdefinitionen angav hemligheterna som referenser som mappats till miljövariabler. Rolltilldelning 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 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

Det här felet innebär att det är något fel med Azure Machine Learning-tjänsten som måste åtgärdas. Skicka ett kundsupportärende med all information som behövs för att åtgärda problemet.

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

Identitets- och autentiseringsfel:

Kraschloopbackoff-fel:

Bedömningsskriptfel:

Övriga fel:

FEL: ACRSecretError

När du skapar eller uppdaterar Kubernetes onlinedistributioner kan du få det här felet av någon av följande orsaker:

  • Rolltilldelningen har inte slutförts. Vänta några sekunder och försök igen.

  • Det Azure Arc-aktiverade Kubernetes-klustret eller AKS Azure Machine Learning-tillägget är inte korrekt installerat eller konfigurerat. Kontrollera konfigurationen och statusen för Azure Arc-aktiverade Kubernetes- eller Azure Machine Learning-tillägg.

  • Kubernetes-klustret har felaktig nätverkskonfiguration. Kontrollera proxyn, nätverksprincipen eller certifikatet.

  • Ditt privata AKS-kluster har inte rätt slutpunkter. Se till att konfigurera privata slutpunkter för Container Registry, lagringskontot och arbetsytan i det virtuella AKS-nätverket.

  • Azure Machine Learning-tilläggsversionen är v1.1.25 eller lägre. Kontrollera att tilläggsversionen är större än v1.1.25.

FEL: TokenRefreshFailed

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

FEL: GetAADTokenFailed

Det här felet beror på att Kubernetes-klusterbegärandet microsoft entra-ID-token misslyckades eller tidsgränsen översågs. Kontrollera nätverksåtkomsten och försök igen.

  • Följ anvisningarna i Använda Kubernetes-beräkning för att kontrollera den utgående proxyn och kontrollera att klustret kan ansluta till arbetsytan. Du hittar arbetsytans slutpunkts-URL i den anpassade resursdefinitionen (CRD) för onlineslutpunkten i klustret.

  • Kontrollera om arbetsytan tillåter offentlig åtkomst. Oavsett om SJÄLVA AKS-klustret är offentligt eller privat kan Kubernetes-klustret endast kommunicera med den arbetsytan via en privat länk om en privat arbetsyta inaktiverar åtkomst till det offentliga nätverket. Mer information finns i Vad är en säker AKS-slutsatsdragningsmiljö.

FEL: ACRAuthenticationChallengeFailed

Det här felet beror på att Kubernetes-klustret inte kan nå arbetsytans containerregistertjänst för att utföra en autentiseringsuppgift. Kontrollera nätverket, särskilt åtkomsten till det offentliga nätverket i Container Registry, 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 Microsoft Entra-ID-token ännu inte har auktoriserats, så Kubernetes-klusterutbytets Container Registry-token misslyckas. Rolltilldelningen tar lite tid, så vänta en minut och försök sedan igen.

Det här felet kan också bero på för många samtidiga begäranden till Container Registry-tjänsten. Det här felet bör vara tillfälligt och du kan försöka igen senare.

FEL: KubernetesUnaccessible

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

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

För att åtgärda det här felet kan du rotera AKS-certifikatet för klustret. Det nya certifikatet bör uppdateras efter 5 timmar, så att du kan vänta i 5 timmar och distribuera om det. Mer information finns i Certifikatrotation i Azure Kubernetes Service (AKS).

FEL: ImagePullLoopBackOff

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlinedistributioner eftersom du inte kan ladda ned avbildningarna från containerregistret, vilket resulterar i hämtningsfelet för avbildningar. Kontrollera klusternätverksprincipen och arbetsytans containerregister för att se om klustret kan hämta avbildningar från containerregistret.

FEL: DeploymentCrashLoopBackOff

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlinedistributioner eftersom användarcontainern kraschade när den initierades. Det finns två möjliga orsaker till det här felet:

  • Användarskriptet score.py har ett syntaxfel eller importfel som genererar undantag vid initiering.
  • Distributionspodden behöver mer minne än gränsen.

Du kan åtgärda det här felet genom att 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 resurs-/instanstyp.

FEL: KubernetesCrashLoopBackOff

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlineslutpunkter eller distributioner av någon av följande orsaker:

  • En eller flera poddar har fastnat i CrashLoopBackoff-status. Kontrollera om distributionsloggen finns och det finns felmeddelanden i loggen.
  • Det finns ett fel i score.py och containern kraschade när poängkoden initierades. Följ anvisningarna under FEL: ResourceNotReady.
  • Din bedömningsprocess behöver mer minne än distributionskonfigurationsgränsen. Du kan försöka uppdatera distributionen med en större minnesgräns.

FEL: NamespaceNotFound

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlineslutpunkter eftersom namnområdet som din Kubernetes-beräkning använde inte är tillgängligt i klustret. Kontrollera Kubernetes-beräkningen i arbetsyteportalen och kontrollera namnområdet i Kubernetes-klustret. Om namnområdet inte är tillgängligt kopplar du från den äldre beräkningen och kopplar från den för att skapa en ny, och anger ett namnområde som redan finns i klustret.

FEL: UserScriptInitFailed

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlinedistributioner eftersom init funktionen i den uppladdade score.py filen utlöste ett undantag. Kontrollera distributionsloggarna för att se undantagsmeddelandet i detalj och åtgärda undantaget.

FEL: UserScriptImportError

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlinedistributioner eftersom den score.py fil som du laddade upp importerar otillgängliga paket. Kontrollera distributionsloggarna för att se undantagsmeddelandet i detalj och åtgärda undantaget.

FEL: UserScriptFunctionNotFound

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlinedistributioner eftersom den score.py fil som du laddade upp inte har någon funktion med namnet init() eller run(). Kontrollera koden och lägg till funktionen.

FEL: EndpointNotFound

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlinedistributioner eftersom systemet inte kan hitta slutpunktsresursen för distributionen i klustret. Skapa distributionen i en befintlig slutpunkt eller skapa slutpunkten först i klustret.

FEL: EndpointAlreadyExists

Du kan få det här felet när du skapar en Kubernetes online-slutpunkt eftersom slutpunkten redan finns i klustret. Slutpunktsnamnet ska vara unikt per arbetsyta och kluster, så skapa en slutpunkt med ett annat namn.

FEL: ScoringFeUnhealthy

Du kan få det här felet när du skapar eller uppdaterar en Kubernetes online-slutpunkt eller distribution eftersom azureml-fe-systemtjänsten som körs i klustret inte hittas eller inte är felfri. Du kan åtgärda problemet genom att installera om eller uppdatera Azure Machine Learning-tillägget i klustret.

FEL: ValidateScoringFailed

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlinedistributioner eftersom valideringen av bedömningsbegärande-URL:en misslyckades när modellen bearbetas. Kontrollera slutpunkts-URL:en och försök sedan distribuera om.

FEL: InvalidDeploymentSpec

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlinedistributioner eftersom distributionsspecifikationen är ogiltig. Kontrollera felmeddelandet för att kontrollera att är instance count giltigt. Om du har aktiverat automatisk skalning kontrollerar du att minimum instance count båda är maximum instance count giltiga.

FEL: PodUnschedulable

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlineslutpunkter eller distributioner av någon av följande orsaker:

  • Systemet kan inte schemalägga podden till noder på grund av otillräckliga resurser i klustret.
  • Ingen nod matchar väljaren för nodtillhörighet.

Följ dessa steg för att åtgärda det här felet:

  1. node selector Kontrollera definitionen av du instance_type använde och konfigurationen node label av dina klusternoder.
  2. instance_type Kontrollera SKU-storleken och noden för AKS-klustret eller nodresursen för Det Azure Arc-aktiverade Kubernetes-klustret.
  3. Om klustret är underbebyggt minskar du resurskravet för instanstypen eller använder en annan instanstyp med mindre resurskrav.
  4. Om klustret inte har fler resurser för att uppfylla kraven för distributionen tar du bort vissa distributioner för att frigöra resurser.

FEL: PodOutOfMemory

Du kan få det här felet när du skapar eller uppdaterar en onlinedistribution eftersom den minnesgräns som du gav för distributionen är otillräcklig. Du kan åtgärda det här felet genom att ange minnesgränsen till ett större värde eller använda en större instanstyp.

FEL: SlutsatsdragningClientCallFailed

Du kan få det här felet när du skapar eller uppdaterar Kubernetes onlineslutpunkter eller distributioner eftersom k8s-tillägget för Kubernetes-klustret inte kan anslutas. I det här fallet kopplar du från och kopplar sedan tillbaka beräkningen.

Om du vill felsöka fel genom att ansluta igen måste du återansluta med samma konfiguration som den fristående beräkningen, till exempel beräkningsnamn och namnområde, för att undvika andra fel. Om det fortfarande inte fungerar ber du en administratör som kan komma åt klustret att använda kubectl get po -n azureml för att kontrollera om reläserverpoddarna körs.

Problem med modellförbrukning

Vanliga modellförbrukningsfel som uppstår till följd av slutpunktsåtgärdens invoke status är bland annat problem med bandbreddsbegränsning, CORS-princip och olika HTTP-statuskoder.

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.

Om du vill övervaka bandbreddsfördröjningen använder du måttet Nätverksbyte för att förstå den aktuella bandbreddsanvändningen. Mer information finns i Övervaka hanterade onlineslutpunkter.

Två svarstrailer returneras om bandbreddsgränsen tillämpas:

  • ms-azureml-bandwidth-request-delay-ms är fördröjningstiden i millisekunder som det tog för överföringen av begärandeströmmen.
  • ms-azureml-bandwidth-response-delay-msär fördröjningstiden i millisekunder som det tog för överföringen av svarsströmmen.

Blockerad av CORS-princip

V2-onlineslutpunkter stöder inte resursdelning mellan ursprung (CORS) internt. Om ditt webbprogram försöker anropa slutpunkten utan att hantera CORS-begäranden korrekt kan du få 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.

Du kan använda Azure Functions, Azure Application Gateway eller en annan tjänst som ett interimslager för att hantera CORS-förhandsbegäranden.

HTTP-statuskoder

När du kommer åt onlineslutpunkter med REST-begäranden följer de returnerade statuskoderna standarderna för HTTP-statuskoder. Följande avsnitt innehåller 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 REST-begäranden använder hanterade onlineslutpunkter:

Statuskod Anledning beskrivning
200 OK Din modell har körts inom dina 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 Autentisering för hanterade onlineslutpunkter och Autentisera klienter för onlineslutpunkter.
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_ms request_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 kommer med liveness eller beredskap avsökning misslyckas, överväg att justera ProbeSettings så att mer tid att avsöka containern livskraft 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. För att garantera en smidig drift tillåter Azure Machine Learning maximalt 2 * max_concurrent_requests_per_instance * instance_count requests att bearbeta parallellt vid en viss tidpunkt. 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 de här inställningarna. Kontrollera också att miljövariabeln WORKER_COUNT skickas korrekt, enligt beskrivningen i RequestSettings.

Om du får det här felet när du använder automatisk skalning får din modell förfrågningar snabbare än systemet kan skala upp. Överväg att skicka begäranden igen med en exponentiell backoff för att ge systemet tid att justera. Du kan också öka antalet instanser med hjälp av kod för att beräkna antalet instanser. Kombinera de här stegen med att ställa in autoskalning för 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änsen 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 REST-begäranden använder Kubernetes onlineslutpunkter:

Statuskod Fel beskrivning
409 Konfliktfel När en åtgärd redan pågår svarar alla nya åtgärder på samma onlineslutpunkt med ett 409-konfliktfel. Om till exempel en onlineslutpunktsåtgärd för att skapa eller uppdatera pågår utlöser en ny borttagningsåtgärd ett fel.
502 Undantag eller krasch i run() metoden för score.py-filen När det finns ett fel i score.py, till exempel ett importerat paket som inte finns i conda-miljön, ett syntaxfel eller ett fel i init() metoden, se FEL: ResourceNotReady för att felsöka filen.
503 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 klienter få HTTP-statuskod 503. Även om autoskalningen reagerar snabbt tar det lång tid för AKS att skapa fler containrar. Se Så här förhindrar du 503-statuskodsfel.
504 Förfrågan uppnår tidsgränsen En 504-statuskod anger att tidsgränsen för begäran har överskrids. 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 koden vara i ett icke-svarstillstånd eller en oändlig loop. Följ FEL: ResourceNotReady för att felsöka score.py-filen.
500 Internt serverfel. Azure Machine Learning-etablerad infrastruktur misslyckas.

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

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. Beslutet att skala upp eller ned baseras på användningen av de aktuella containerreplikerna.

Två åtgärder kan hjälpa till att förhindra 503-statuskodfel: Ändra användningsnivån för att skapa nya repliker eller ändra det minsta antalet repliker. Du kan använda dessa metoder individuellt eller i kombination.

  • Ändra användningsmålet där autoskalning skapar nya repliker genom att ange autoscale_target_utilization ett lägre värde. Den här ändringen gör inte att repliker skapas snabbare, utan vid ett lägre användningströskelvärde. Om du till exempel ändrar värdet till 30 % skapas repliker när 30 % användning sker i stället för att vänta tills tjänsten används till 70 %.

  • Ändra det minsta antalet repliker för att tillhandahålla en större pool som kan hantera inkommande toppar.

Så här beräknar du antal instanser

Om du vill öka antalet instanser kan du beräkna de repliker som krävs på följande sätt:

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.

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

Problem med nätverksisolering

Det här avsnittet innehåller information om vanliga problem med nätverksisolering.

Det går inte att skapa en onlineslutpunkt med ett V1LegacyMode == sant meddelande

Du kan konfigurera Azure Machine Learning-arbetsytan för v1_legacy_mode, som 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.

Om du vill inaktivera läser v1_legacy_modedu Nätverksisolering med v2.

Viktigt!

Kontakta nätverkssäkerhetsteamet innan du inaktiverar v1_legacy_mode, eftersom de kan ha aktiverat det av en anledning.

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-nyckelvalvet 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-kod:

{
    "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 disabled 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-containerregistret 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 svarskoden kontrollerar du att fältet är inställt på status Approved. Annars 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, till exempel:

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

    Svaret innehåller en adress som ska finnas 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 anges i kubernetes-klustret.
    • Om slutpunkten är HTTP finns IP-adressen i slutpunkts-URI:n, som du kan hämta från studiogränssnittet.
    • Du hittar fler sätt att hämta IP-adressen för slutpunkten i Säker Kubernetes onlineslutpunkt.

  3. nslookup Om kommandot inte löser värdnamnet vidtar du följande åtgärder:

Hanterade onlineslutpunkter

  1. Använd följande kommando för att kontrollera om det finns en A-post i den privata DNS-zonen (Domain Name Server) för det virtuella nätverket.

    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 använder en anpassad DNS-server kör du följande kommando för att kontrollera att matchningen från anpassad DNS fungerar korrekt.

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

Kubernetes-onlineslutpunkter

  1. Kontrollera DNS-konfigurationen i Kubernetes-klustret.

  2. Kontrollera också om azureml-fe fungerar som förväntat med hjälp av 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"

    Använd följande kommando för HTTP:

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

  3. Om curl HTTPs misslyckas eller överskrider tidsgränsen men HTTP fungerar kontrollerar du om certifikatet är giltigt.

  4. Om föregående process inte matchar 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

  5. Om föregående kommando lyckas felsöker du den villkorsstyrda vidarebefordraren för privat länk i anpassad DNS.

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

  1. Kör följande kommando för att se om distributionen lyckades:

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

    Om distributionen har slutförts är 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

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

    Dricks

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

  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>

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

Problem med slutsatsdragningsservern

Det här avsnittet innehåller grundläggande felsökningstips för HTTP-servern för Azure Machine Learning-slutsatsdragning.

Kontrollera installerade paket

Följ de här stegen för att åtgärda problem med installerade paket.

  1. Samla in information om installerade paket och versioner för din Python-miljö.

  2. Bekräfta att Python-paketversionen azureml-inference-server-http som anges i miljöfilen matchar DEN HTTP-serverversion för Azure Machine Learning-slutsatsdragning som visas i startloggen.

    I vissa fall installerar pip-beroendelösaren oväntade paketversioner. Du kan behöva köra pip för att korrigera installerade paket och versioner.

  3. Om du anger Flask eller dess beroenden i din miljö tar du bort dessa objekt.

    • Beroende paket inkluderar flask, jinja2, itsdangerous, werkzeug, markupsafeoch click.
    • flask anges som ett beroende i serverpaketet. Det bästa sättet är att låta slutsatsdragningsservern installera flask paketet.
    • När slutsatsdragningsservern har konfigurerats för att stödja nya versioner av Flask tar servern automatiskt emot paketuppdateringarna när de blir tillgängliga.

Kontrollera serverversionen

Serverpaketet azureml-inference-server-http publiceras till PyPI. På Sidan PyPI visas ändringsloggen och alla tidigare versioner.

Om du använder en tidigare paketversion uppdaterar du konfigurationen till den senaste versionen. I följande tabell sammanfattas stabila versioner, vanliga problem och rekommenderade justeringar:

Paketversion beskrivning Problem Åtgärd
0.4.x Paketerade i träningsbilder daterade 20220601 eller tidigare och azureml-defaults paketversioner .1.34 via 1.43. Den senaste stabila versionen är 0.4.13. För serverversioner som är tidigare än 0.4.11 kan du stöta på Flask-beroendeproblem, till exempel "can't import name Markup from jinja2". Uppgradera till version 0.4.13 eller 0.8.x, den senaste versionen, om möjligt.
0.6.x Förinstallerad i slutsatsdragning av avbildningar daterade 20220516 och tidigare. Den senaste stabila versionen är 0.6.1. Saknas Saknas
0.7.x Stöder Flask 2. Den senaste stabila versionen är 0.7.7. Saknas Saknas
0.8.x Loggformatet har ändrats. Python 3.6-supporten har upphört. Saknas Saknas

Kontrollera paketberoenden

De mest relevanta beroende paketen azureml-inference-server-http för serverpaketet är:

  • flask
  • opencensus-ext-azure
  • inference-schema

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

Dricks

Om du använder Python SDK v1 och inte uttryckligen azureml-defaults anger paketet i Python-miljön kan SDK:t automatiskt lägga till paketet. Paketeringsversionen är dock låst i förhållande till SDK-versionen. Om SDK-versionen till exempel är 1.38.0azureml-defaults==1.38.0 läggs posten till i miljöns pip-krav.

TypeError under serverstart

Du kan stöta på följande TypeError 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

Det här felet uppstår när du har Flask 2 installerat i Python-miljön, men paketversionen azureml-inference-server-http stöder inte Flask 2. Stöd för Flask 2 finns i azureml-inference-server-http paketversion 0.7.0 och senare samt azureml-defaults paketversion 1.44 och senare.

  • Om du inte använder Flask 2-paketet i en Azure Machine Learning Docker-avbildning använder du den senaste versionen av azureml-inference-server-http paketet eller azureml-defaults .

  • Om du använder Flask 2-paketet i en Azure Machine Learning Docker-avbildning kontrollerar du att avbildningsversionen är juli 2022 eller senare.

    Du hittar avbildningsversionen i containerloggarna. Till exempel:

    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, Materialization Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    Kompileringsdatumet för avbildningen visas efter notationen Materialization Build . I föregående exempel är 20220708 avbildningsversionen eller 8 juli 2022. Bilden i det här exemplet är kompatibel med Flask 2.

    Om du inte ser något liknande meddelande i containerloggen är avbildningen inaktuell och bör uppdateras. Om du använder en CUDA-avbildning (Compute Unified Device Architecture) och du inte hittar en nyare avbildning kontrollerar du om avbildningen är inaktuell i AzureML-Containers. Du hittar avsedda ersättningar för inaktuella bilder.

    Om du använder servern med en onlineslutpunkt kan du även hitta loggarna på sidan Loggar på sidan Slutpunkter i Azure Machine Learning-studio.

Om du distribuerar med SDK v1 och inte uttryckligen anger en avbildning i distributionskonfigurationen openmpi4.1.0-ubuntu20.04 tillämpar servern paketet med en version som matchar din lokala SDK-verktygsuppsättning. Den installerade versionen kanske dock inte är den senaste tillgängliga versionen av avbildningen.

För SDK version 1.43 installerar openmpi4.1.0-ubuntu20.04:20220616 servern paketversionen som standard, men den här paketversionen är inte kompatibel med SDK 1.43. Se till att du använder den senaste SDK:t för distributionen.

Om du inte kan uppdatera avbildningen kan du tillfälligt undvika problemet genom att fästa posterna azureml-defaults==1.43 eller azureml-inference-server-http~=0.4.13 i miljöfilen. Dessa poster instruerar servern att installera den äldre versionen med flask 1.0.x.

ImportError eller ModuleNotFoundError under serverstart

Du kan stöta på en ImportError eller ModuleNotFoundError flera specifika moduler, till exempel opencensus, jinja2, markupsafeeller click, under serverstarten. I följande exempel visas felmeddelandet:

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

Import- och modulfelen uppstår när du använder version 0.4.10 eller tidigare versioner av servern som inte fäster Flask-beroendet på en kompatibel version. Du kan förhindra problemet genom att installera en senare version av servern.

Andra vanliga problem

Andra vanliga problem med onlineslutpunkter är relaterade till conda-installation och autoskalning.

Problem med Conda-installation

Problem med MLflow-distribution beror vanligtvis på problem med installationen av användarmiljön som anges i conda.yml-filen .

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

  1. Kontrollera conda-installationsloggarna. Om containern kraschade eller tog för lång tid att starta kunde conda-miljöuppdateringen förmodligen inte 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.
    • Conda-paketinstallationen sker vid körning, så om SKU-storleken är för liten för att rymma alla paket i conda.yml miljöfilen kan containern krascha.
    • En Standard_F4s_v2 virtuell dator är en bra start-SKU-storlek, men du kan behöva större virtuella datorer beroende på de beroenden som conda-filen anger.
    • För Kubernetes onlineslutpunkter måste Kubernetes-klustret ha minst fyra vCPU-kärnor och 8 GB minne.

Problem med automatisk skalning

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

För Kubernetes onlineslutpunkter är Azure Machine Learning-slutsatsdragningsroutern en klientdelskomponent som hanterar automatisk skalning för alla modelldistributioner i Kubernetes-klustret. Mer information finns i Autoskala Kubernetes-slutsatsdragningsroutning.

Relaterat innehåll