Megosztás a következőn keresztül:

Online végpont üzembe helyezésének és pontozásának hibaelhárítása

  • Cikk

ÉRVÉNYES:Azure CLI ml-bővítmény v2 (aktuális)Python SDK azure-ai-ml v2 (aktuális)

Ez a cikk azt ismerteti, hogyan háríthatja el és oldhatja meg az Azure Machine Learning online végpont üzembe helyezésének és pontozásának gyakori problémáit.

A dokumentumstruktúra a hibaelhárítás megközelítésének módját tükrözi:

  1. Használjon helyi üzemelő példányt a modellek helyben való teszteléséhez és hibakereséséhez, mielőtt a felhőben üzembe helyezné őket.
  2. A problémák könnyebb elhárítása érdekében használja a tárolónaplókat.
  3. Megismerheti az esetleg előforduló gyakori üzembehelyezési hibákat és a kijavításuk módját.

A HTTP-állapotkódok szakasz azt ismerteti, hogy a meghívási és előrejelzési hibák hogyan képeznek le HTTP-állapotkódokat, amikor REST-kérésekkel pontozza a végpontokat.

Előfeltételek

Kérések nyomon követése

Két támogatott nyomkövetési fejléc létezik:

  • x-request-id a kiszolgáló nyomkövetéséhez van fenntartva. Az Azure Machine Learning felülbírálja ezt a fejlécet, hogy érvényes GUID-azonosító legyen. Ha támogatási jegyet hoz létre egy sikertelen kérelemhez, csatolja a sikertelen kérelem azonosítóját a vizsgálat felgyorsításához. Másik lehetőségként adja meg a régió nevét és a végpont nevét.

  • x-ms-client-request-id az ügyfél-nyomkövetési forgatókönyvekhez érhető el. Ez a fejléc csak alfanumerikus karaktereket, kötőjeleket és aláhúzásjeleket fogad el, és legfeljebb 40 karakterre csonkolja.

Helyi üzembe helyezés

A helyi üzembe helyezés azt jelenti, hogy egy modellt egy helyi Docker-környezetben helyeznek üzembe. A helyi üzembe helyezés támogatja a helyi végpont létrehozását, frissítését és törlését, és lehetővé teszi a naplók meghívását és lekérését a végpontról. A helyi üzembe helyezés a felhőbe való üzembe helyezés előtt történő teszteléshez és hibakereséshez hasznos.

Tipp.

Az Azure Machine Learning-következtetés HTTP-kiszolgálói Python-csomagjával helyileg is hibakeresést végezhet a pontozószkriptben. A következtetési kiszolgálóval végzett hibakeresés segít a pontozószkript hibakeresésében, mielőtt üzembe helyeznénk a helyi végpontokon, hogy az üzembehelyezési tároló konfigurációi ne befolyásolhassák a hibakeresést.

Helyileg üzembe helyezheti az Azure CLI-vel vagy a Python SDK-val. Az Azure Machine Learning Studio nem támogatja a helyi üzembe helyezést vagy a helyi végpontokat.

A helyi üzembe helyezés használatához adja hozzá --local a megfelelő parancsot.

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

A helyi üzembe helyezés során a következő lépések történnek:

  1. A Docker létrehoz egy új tárolórendszerképet, vagy lekér egy meglévő lemezképet a helyi Docker-gyorsítótárból. A Docker egy meglévő rendszerképet használ, ha az megfelel a specifikációs fájl környezeti részének.
  2. A Docker helyi összetevőkkel, például modell- és kódfájlokkal indítja el az új tárolót.

További információ: Helyi végpont használatával történő helyi üzembe helyezés és hibakeresés.

Tipp.

A Visual Studio Code használatával helyileg tesztelheti és hibakeresésre használhatja a végpontokat. További információ: Online végpontok helyi hibakeresése a Visual Studio Code-ban.

Tárolónaplók lekérése

Nem férhet hozzá közvetlen hozzáféréshez olyan virtuális géphez (virtuális géphez), ahol a modell üzembe helyezve van, de a virtuális gépen futó tárolók némelyikéből naplókat is lekérhet. A lekért információk mennyisége az üzembe helyezés kiépítési állapotától függ. Ha a megadott tároló működik, megjelenik a konzol kimenete. Ellenkező esetben megjelenik egy üzenet, amely később újrapróbálkozhat.

A naplókat a következő tárolótípusokból szerezheti be:

  • A következtetési kiszolgáló konzolnaplója a pontozószkript score.py kódból származó nyomtatási és naplózási függvények kimenetét tartalmazza.
  • A tároló inicializáló naplói információkat tartalmaznak arról, hogy a kód- és modelladatok sikeresen letöltődnek-e a tárolóba. A tároló a következtetési kiszolgáló tárolójának futtatása előtt fut.

Az online Kubernetes-végpontok esetében a rendszergazdák közvetlenül hozzáférhetnek ahhoz a fürthöz, ahol a modellt üzembe helyezi, és ellenőrizhetik a naplókat a Kubernetesben. Például:

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

Feljegyzés

Ha Python-naplózást használ, ügyeljen arra, hogy a megfelelő naplózási szintet használja, például INFOaz üzenetek naplókban való közzétételéhez.

Tárolók naplókimenetének megtekintése

A tároló naplókimenetének megtekintéséhez használja a következő parancsot:

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

Vagy

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

Alapértelmezés szerint a rendszer lekérte a naplókat a következtetési kiszolgálóról. A tároló inicializáló tárolójából naplókat kérhet le a továbbítással –-container storage-initializer.

Adja hozzá --resource-group és --workspace-name adja hozzá a parancsokat, ha még nem állította be ezeket a paramétereket.az configure A paraméterek beállításával, illetve az értékek beállításával kapcsolatos információk megtekintéséhez futtassa a következő parancsot:

az ml online-deployment get-logs -h

További információk megtekintéséhez adja hozzá --help vagy --debug adja hozzá a parancsokat.

Gyakori telepítési hibák

Az üzembe helyezési művelet állapota a következő gyakori üzembehelyezési hibákat jelentheti:

Ha Online Kubernetes-telepítést hoz létre vagy frissít, tekintse meg a Kubernetes üzemelő példányaival kapcsolatos gyakori hibákat is.

HIBA: ImageBuildFailure

Ez a hiba a Docker-rendszerkép-környezet létrehozásakor jelenik meg. A hibával kapcsolatos további információkért tekintse meg a buildnaplót. A buildnapló az Azure Machine Learning-munkaterület alapértelmezett tárolójában található.

A pontos hely például a hiba "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'"részeként adható vissza.

A következő szakaszok a rendszerképek buildelési hibáinak gyakori forgatókönyveit ismertetik:

Az Azure Container Registry engedélyezési hibája

Hibaüzenet jelenik "container registry authorization failure" meg, ha nem fér hozzá a tárolóregisztrációs adatbázishoz az aktuális hitelesítő adatokkal. A munkaterület erőforráskulcsainak deszinkronizálása okozhatja ezt a hibát, és időbe telik az automatikus szinkronizálás. Manuálisan azonban meghívhatja a kulcsszinkronizálást az ml-munkaterület szinkronizálási kulcsaival, ami megoldhatja az engedélyezési hibát.

A virtuális hálózat mögötti tárolóregisztrációs adatbázisok akkor is találkozhatnak ezzel a hibával, ha helytelenül vannak beállítva. Ellenőrizze, hogy a virtuális hálózat megfelelően van-e beállítva.

A rendszerkép-összeállítási számítás nincs beállítva virtuális hálózattal rendelkező privát munkaterületen

Ha a hibaüzenet megemlíti "failed to communicate with the workspace's container registry", és ön egy virtuális hálózatot használ, és a munkaterület tárolóregisztrációs adatbázisa privát, és privát végponttal van konfigurálva, engedélyeznie kell a Tárolóregisztrációs adatbázis számára, hogy lemezképeket hozzon létre a virtuális hálózaton.

A kép összeállításának időtúllépése

A képlétrehozási időtúllépések oka gyakran az, hogy a rendszerkép túl nagy ahhoz, hogy az üzembe helyezés létrehozási időkeretén belül befejezhesse az építést. Ellenőrizze a kép összeállítási naplóit a hiba által megadott helyen. A naplók akkor lesznek levágva, amikor a rendszerkép összeállítása időtúllépést eredményezett.

A probléma megoldásához külön hozza létre a lemezképet, hogy a rendszerképet csak az üzembe helyezés létrehozásakor kell lekéreni. Tekintse át az alapértelmezett mintavételi beállításokat is, ha ImageBuild időtúllépésekkel rendelkezik.

Általános rendszerkép-összeállítási hiba

A hibával kapcsolatos további információkért tekintse meg a buildnaplót. Ha nem található nyilvánvaló hiba a buildnaplóban, és az utolsó sor az Installing pip dependencies: ...working..., akkor előfordulhat, hogy függőség okozza a hibát. A conda-fájl verziófüggőségeinek rögzítése megoldhatja ezt a problémát.

A felhőben való üzembe helyezés előtt próbálja meg helyileg üzembe helyezni a modellek tesztelését és hibakeresését.

HIBA: OutOfQuota

Az Azure-szolgáltatások használatakor a következő erőforrások elfogyhatnak a kvótából:

Csak a Kubernetes online végpontjai esetében előfordulhat, hogy a Kubernetes-erőforrás is elfogy a kvótából.

CPU-kvóta

A modell üzembe helyezéséhez elegendő számítási kvótával kell rendelkeznie. A CPU-kvóta határozza meg, hogy előfizetésenként, munkaterületenként, termékváltozatonként és régiónként hány virtuális mag érhető el. Minden üzembe helyezés kivonja a rendelkezésre álló kvótát, és a termékváltozat típusától függően visszaveszi azt a törlés után.

Ellenőrizheti, hogy vannak-e nem használt üzemelő példányok, amelyeket törölhet, vagy elküldheti a kvótanövelésre vonatkozó kérelmet.

Fürtkvóta

A OutOfQuota hiba akkor fordul elő, ha nem rendelkezik elegendő Azure Machine Learning számítási fürtkvótával. A kvóta az előfizetésenkénti fürtök teljes számát határozza meg, amelyeket egyszerre használhat cpu- vagy GPU-csomópontok üzembe helyezéséhez az Azure-felhőben.

Lemezkvóta

A OutOfQuota hiba akkor fordul elő, ha a modell mérete nagyobb, mint a rendelkezésre álló lemezterület, és a modell nem tölthető le. Próbáljon meg több lemezterületet tartalmazó termékváltozatot használni, vagy csökkentse a lemezkép és a modell méretét.

Memóriakvóta

A OutOfQuota hiba akkor fordul elő, ha a modell memóriaigénye nagyobb, mint a rendelkezésre álló memória. Próbáljon ki több memóriával rendelkező termékváltozatot .

Szerepkör-hozzárendelési kvóta

Felügyelt online végpont létrehozásakor szerepkör-hozzárendelésre van szükség ahhoz, hogy a felügyelt identitás hozzáférjen a munkaterület erőforrásaihoz. Ha elérte a szerepkör-hozzárendelési korlátot, próbálja törölni az előfizetésben nem használt szerepkör-hozzárendeléseket. Az Összes szerepkör-hozzárendelés ellenőrzéséhez válassza az Azure-előfizetés hozzáférés-vezérlését az Azure Portalon.

Végpontkvóta

Próbáljon meg törölni néhány nem használt végpontot ebben az előfizetésben. Ha az összes végpont aktívan használatban van, próbálkozzon a végpontkorlát növelésének kérésével. A végpontkorláttal kapcsolatos további információkért tekintse meg az Azure Machine Learning online végpontjait és kötegelt végpontjait tartalmazó végpontkvótát.

Kubernetes-kvóta

A OutOfQuota hiba akkor fordul elő, ha a kért processzor vagy memória nem biztosítható, mert a csomópontok nem ütemezhetők az üzembe helyezéshez. Előfordulhat például, hogy a csomópontok kordonozottak vagy más módon nem érhetők el.

A hibaüzenet általában a fürt erőforrás-elégtelenségét jelzi, például OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Ez az üzenet azt jelenti, hogy túl sok pod található a fürtben, és nincs elegendő erőforrás az új modell üzembe helyezéséhez a kérés alapján.

Próbálja ki a következő megoldásokat a probléma megoldásához:

  • A Kubernetes-fürtöt karbantartó informatikai operátorok megpróbálhatnak további csomópontokat hozzáadni, vagy törölni néhány nem használt podot a fürtben, hogy egyes erőforrásokat felszabadítsa.

  • A modelleket üzembe helyező gépi tanulási mérnökök megpróbálhatják csökkenteni az üzembe helyezés erőforrás-kérését.

    • Ha közvetlenül az erőforrás-konfigurációban definiálja az erőforrás-kérelmet az erőforrásszakaszon keresztül, próbálja meg csökkenteni az erőforrás-kérelmet.
    • Ha erőforrást definiál instance_type a modell üzembe helyezéséhez, forduljon az informatikai operátorhoz a példánytípus erőforráskonfigurációjának módosításához. További információ: Példánytípusok létrehozása és kezelése.

Régiószintű virtuálisgép-kapacitás

A régióban az Azure Machine Learning-kapacitás hiánya miatt a szolgáltatás nem tudta kiépíteni a megadott virtuálisgép-méretet. Próbálkozzon újra később, vagy próbálkozzon az üzembe helyezéssel egy másik régióban.

Egyéb kvóta

Az üzembe helyezés részeként megadott score.py fájl futtatásához az Azure létrehoz egy tárolót, amely tartalmazza az score.py által igényelt összes erőforrást. Az Azure Machine Learning ezután futtatja a pontozási szkriptet a tárolón. Ha a tároló nem indul el, a pontozás nem történhet meg. Előfordulhat, hogy a tároló több erőforrást kér, mint amennyit a instance_type tároló támogat. Fontolja meg az instance_type online üzembe helyezés frissítését.

A hiba pontos okának lekéréséhez hajtsa végre az alábbi műveletet.

Futtassa az alábbi parancsot:

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

HIBA: BadArgument

Ez a hiba akkor jelenhet meg, ha felügyelt online végpontokat vagy Kubernetes online végpontokat használ az alábbi okokból:

Ez a hiba akkor is előfordulhat, ha csak a Kubernetes online végpontjait használja, az alábbi okokból:

Az előfizetés nem létezik

A hivatkozott Azure-előfizetésnek meglévőnek és aktívnak kell lennie. Ez a hiba akkor fordul elő, ha az Azure nem találja a megadott előfizetés-azonosítót. A hiba oka lehet egy elírás az előfizetés-azonosítóban. Ellenőrizze, hogy az előfizetés azonosítóját helyesen adta-e meg, és jelenleg aktív-e.

Engedélyezési hiba

Miután üzembe helyezéskor kiépítette a számítási erőforrást, az Azure lekéri a felhasználói tároló lemezképét a munkaterület tárolóregisztrációs adatbázisából, és csatlakoztatja a felhasználói modellt és a kódösszetevőket a felhasználói tárolóba a munkaterület tárfiókjából. Az Azure felügyelt identitásokkal fér hozzá a tárfiókhoz és a tárolóregisztrációs adatbázishoz.

Ha a társított végpontot felhasználó által hozzárendelt identitással hozza létre, a felhasználó felügyelt identitásának a munkaterület tárolóregisztrációs adatbázisában tárolási blobadat-olvasói engedéllyel és AcrPull-engedéllyel kell rendelkeznie. Győződjön meg arról, hogy a felhasználó által hozzárendelt identitás rendelkezik a megfelelő engedélyekkel.

Ha a társított végpontot rendszer által hozzárendelt identitással hozza létre, az Azure szerepköralapú hozzáférés-vezérlési (RBAC) engedélye automatikusan meg lesz adva, és nincs szükség további engedélyekre. További információ: Tárolóregisztrációs adatbázis engedélyezési hibája.

Érvénytelen sablonfüggvény-specifikáció

Ez a hiba akkor fordul elő, ha egy sablonfüggvény helytelenül lett megadva. Javítsa ki a szabályzatot, vagy távolítsa el a szabályzat-hozzárendelést a letiltás feloldásához. A hibaüzenet tartalmazhatja a szabályzat-hozzárendelés nevét és a szabályzatdefiníciót a hiba hibakereséséhez. A sablonhibák elkerüléséhez tekintse meg az Azure szabályzatdefiníciós struktúráját .

A felhasználói tárolórendszerkép letöltése nem sikerült

Előfordulhat, hogy a felhasználói tároló nem található. További részletekért tekintse meg a tárolónaplókat .

Győződjön meg arról, hogy a tárolólemezkép elérhető a munkaterület tárolóregisztrációs adatbázisában. Ha például a kép az testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, az alábbi paranccsal ellenőrizheti az adattárat:

az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table`

A felhasználói modell letöltése nem sikerült

Előfordulhat, hogy a felhasználói modell nem található. További részletekért tekintse meg a tárolónaplókat . Győződjön meg arról, hogy a modellt ugyanarra a munkaterületre regisztrálta, mint az üzembe helyezés.

A munkaterületen lévő modell részleteinek megjelenítéséhez hajtsa végre az alábbi műveletet. A modelladatok lekéréséhez meg kell adnia a verziót vagy a címkét.

Futtassa az alábbi parancsot:

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

Ellenőrizze azt is, hogy a blobok megtalálhatók-e a munkaterület tárfiókjában. Ha például a blob az https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl, a következő paranccsal ellenőrizheti, hogy létezik-e a blob:

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

Ha a blob jelen van, a következő paranccsal lekérheti a naplókat a tároló inicializálójából:

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

Az MLflow-modell formátuma magánhálózattal nem támogatott

Ha a felügyelt online végpontokhoz az örökölt hálózatelkülönítési módszert használja, nem használhatja a magánhálózati funkciót MLflow-modellformátummal. Ha kód nélküli üzembe helyezési megközelítéssel kell üzembe helyeznie egy MLflow-modellt, próbáljon meg egy munkaterület által felügyelt virtuális hálózatot használni.

Korlátoknál nagyobb erőforrás-kérelmek

Az erőforrásokra vonatkozó kérelmeknek a korlátoknál kisebbnek vagy egyenlőnek kell lenniük. Ha nem állít be korlátokat, az Azure Machine Learning beállítja az alapértelmezett értékeket, amikor a számítást egy munkaterülethez csatolja. A korlátozásokat az Azure Portalon vagy a az ml compute show parancs használatával ellenőrizheti.

Az Azureml-fe nem áll készen

Az előtérbeli azureml-fe összetevő, amely a bejövő következtetési kérelmeket az üzembe helyezett szolgáltatásokhoz irányítja, a k8s-bővítmény telepítésekor telepíti, és szükség szerint automatikusan skáláz. Ennek az összetevőnek legalább egy kifogástalan replikával kell rendelkeznie a fürtön.

Ez a hiba akkor jelenik meg, ha az összetevő nem érhető el a Kubernetes online végpontjának vagy üzembe helyezési vagy frissítési kérésének aktiválásakor. A probléma megoldásához ellenőrizze a pod állapotát és naplóit. A fürtre telepített k8s-bővítményt is megpróbálhatja frissíteni.

HIBA: ResourceNotReady

Az üzembe helyezés részeként megadott score.py fájl futtatásához az Azure létrehoz egy tárolót, amely tartalmazza az score.py által igényelt összes erőforrást, és a tárolón futtatja a pontozási szkriptet. Ebben a forgatókönyvben az a hiba, hogy ez a tároló futás közben összeomlik, ezért a pontozás nem történhet meg. Ez a hiba a következő feltételek valamelyike esetén fordulhat elő:

  • Hiba történt a score.py. Gyakori problémák diagnosztizálására használható get-logs , például:

    • Olyan csomag, amely score.py megpróbál importálni, amely nem szerepel a Conda-környezetben
    • Szintaxishiba
    • Hiba a init() metódusban

    Ha get-logs nem hoz létre naplókat, az általában azt jelenti, hogy a tároló nem indult el. A probléma hibakereséséhez próbálja meg helyileg üzembe helyezni.

  • A készültségi vagy az élőségi mintavételek nincsenek megfelelően beállítva.

  • A tároló inicializálása túl hosszú ideig tart, így a készültségi vagy az élettartam-mintavétel a hibaküszöbön túl meghiúsul. Ebben az esetben módosítsa a mintavételi beállításokat , hogy hosszabb ideig lehessen inicializálni a tárolót. Vagy próbálkozzon egy nagyobb támogatott virtuálisgép-termékváltozattal, amely felgyorsítja az inicializálást.

  • Hiba történt a tárolókörnyezet beállításában, például hiányzik a függőség.

    Ha a hiba jelentkezik TypeError: register() takes 3 positional arguments but 4 were given , ellenőrizze a Flask v2 és azureml-inference-server-httpa . További információ: HTTP-kiszolgálóval kapcsolatos problémák elhárítása.

HIBA: ResourceNotFound

Ez a hiba a felügyelt online végpont vagy a Kubernetes online végpontjának használatakor jelenhet meg a következő okok miatt:

A Resource Manager nem talál erőforrást

Ez a hiba akkor fordul elő, ha az Azure Resource Manager nem talál egy szükséges erőforrást. Ez a hiba például akkor jelenhet meg, ha egy tárfiók nem található a megadott elérési úton. Ellenőrizze az elérési utat vagy a névspecifikációkat a pontosság és a helyesírás érdekében. További információ: Az erőforrás nem található hibáinak elhárítása.

Tárolóregisztrációs adatbázis engedélyezési hibája

Ez a hiba akkor fordul elő, ha a rendszer egy privát vagy más módon elérhetetlen tárolóregisztrációs adatbázishoz tartozó lemezképet ad meg az üzembe helyezéshez. Az Azure Machine Learning API-k nem tudják elfogadni a privát beállításjegyzék hitelesítő adatait.

A hiba elhárításához győződjön meg arról, hogy a tárolóregisztrációs adatbázis nem privát, vagy hajtsa végre a következő lépéseket:

  1. Adja meg a magánregisztrációs adatbázis acrPull-szerepkörét az online végpont rendszeradentitásának.
  2. A környezetdefinícióban adja meg a privát rendszerkép címét, és adja meg az utasítást, hogy ne módosítsa vagy ne hozza létre a rendszerképet.

Ha ez a kockázatcsökkentés sikeres, a rendszerkép nem igényel összeállítást, és a végső képcím a megadott képcím. Az üzembe helyezéskor az online végpont rendszeridentitása lekéri a rendszerképet a privát beállításjegyzékből.

További diagnosztikai információkért tekintse meg a munkaterület-diagnosztika használatát ismertető témakört.

HIBA: WorkspaceManagedNetworkNotReady

Ez a hiba akkor fordul elő, ha olyan online üzembe helyezést próbál létrehozni, amely lehetővé teszi a munkaterület által felügyelt virtuális hálózatot, de a felügyelt virtuális hálózat még nincs kiépítve. A munkaterület által felügyelt virtuális hálózat kiépítése online üzembe helyezés előtt.

A munkaterület által felügyelt virtuális hálózat manuális kiépítéséhez kövesse a felügyelt virtuális hálózat manuális kiépítésére vonatkozó utasításokat. Ezután elkezdhet online üzembe helyezéseket létrehozni. További információ: Hálózatelkülönítés felügyelt online végponttal , valamint felügyelt online végpontok védelme hálózati elkülönítéssel.

HIBA: OperationCanceled

Ez a hiba a felügyelt online végpont vagy a Kubernetes online végpontjának használatakor jelenhet meg a következő okok miatt:

Egy másik magasabb prioritású művelet megszakította a műveletet

Az Azure-műveletek bizonyos prioritási szinttel rendelkeznek, és a legmagasabbtól a legalacsonyabbig hajtják végre. Ez a hiba akkor fordul elő, ha egy másik, magasabb prioritású művelet felülírja a műveletet. A művelet újrapróbálkozása lehetővé teheti a művelet megszakítás nélküli végrehajtását.

A művelet megszakítva a zárolás megerősítésére várva

Az Azure-műveleteknek a beküldés után rövid várakozási időszakuk van, amely során lekérnek egy zárolást, hogy ne ütközhessenek versenyfeltételekkel. Ez a hiba akkor fordul elő, ha a beküldött művelet megegyezik egy másik művelettel. A másik művelet jelenleg arra vár, hogy megerősítést kapjon arról, hogy megkapta a zárolást a folytatás előtt.

Előfordulhat, hogy a kezdeti kérés után túl hamar küldött el hasonló kérelmet. Ha akár egy perc várakozás után újrapróbálkozza a műveletet, az lemondás nélkül is végrehajthatja a műveletet.

HIBA: SecretsInjectionError

A titkos kódok lekérése és injektálása az online üzembe helyezés létrehozása során az online végponthoz társított identitás használatával kéri le a titkos kulcsokat a munkaterület-kapcsolatokból vagy kulcstartókból. Ez a hiba az alábbi okok valamelyike miatt fordul elő:

  • A végpontidentitás nem rendelkezik Azure RBAC-engedéllyel a munkaterület-kapcsolatokból vagy kulcstartókból származó titkos kódok beolvasásához, annak ellenére, hogy az üzembehelyezési definíció környezeti változókra mutató hivatkozásként adta meg a titkos kulcsokat. A szerepkör-hozzárendelés eltarthat egy ideig, mire a módosítások érvénybe lépnek.

  • A titkos kulcshivatkozások formátuma érvénytelen, vagy a megadott titkos kulcsok nem léteznek a munkaterület-kapcsolatokban vagy kulcstartókban.

További információ: Titkos kódinjektálás online végpontokban (előzetes verzió) és titkos kódok elérése az online üzembe helyezésből titkos kódinjektálás (előzetes verzió) használatával.

HIBA: InternalServerError

Ez a hiba azt jelenti, hogy hiba történt az Azure Machine Learning szolgáltatással kapcsolatban, amelyet ki kell javítani. Küldjön be egy ügyfélszolgálati jegyet a probléma megoldásához szükséges összes információval.

A Kubernetes üzemelő példányaival kapcsolatos gyakori hibák

Identitás- és hitelesítési hibák:

Crashloopbackoff-hibák:

Pontozási szkript hibái:

Egyéb hibák:

HIBA: ACRSecretError

A Kubernetes online telepítéseinek létrehozásakor vagy frissítésekor a következő okok valamelyike miatt jelenhet meg ez a hiba:

  • A szerepkör-hozzárendelés nem fejeződött be. Várjon néhány másodpercet, és próbálkozzon újra.

  • Az Azure Arc-kompatibilis Kubernetes-fürt vagy az AKS Azure Machine Learning-bővítmény nincs megfelelően telepítve vagy konfigurálva. Ellenőrizze az Azure Arc-kompatibilis Kubernetes vagy az Azure Machine Learning-bővítmény konfigurációját és állapotát.

  • A Kubernetes-fürt hálózati konfigurációja nem megfelelő. Ellenőrizze a proxyt, a hálózati házirendet vagy a tanúsítványt.

  • A privát AKS-fürt nem rendelkezik a megfelelő végpontokkal. Győződjön meg arról, hogy privát végpontokat állít be a Container Registryhez, a tárfiókhoz és a munkaterülethez az AKS virtuális hálózatban.

  • Az Azure Machine Learning-bővítmény verziója 1.1.25-ös vagy újabb. Győződjön meg arról, hogy a bővítmény verziója nagyobb, mint az 1.1.25-ös verzió.

HIBA: TokenRefreshFailed

Ez a hiba azért fordul elő, mert a Kubernetes-fürt identitása nincs megfelelően beállítva, így a bővítmény nem tud fő hitelesítő adatokat lekérni az Azure-ból. Telepítse újra az Azure Machine Learning bővítményt , és próbálkozzon újra.

HIBA: GetAADTokenFailed

Ez a hiba azért fordul elő, mert a Kubernetes-fürtkérelem Microsoft Entra ID-jogkivonata meghiúsult vagy időtúllépés történt. Ellenőrizze a hálózati hozzáférést, majd próbálkozzon újra.

  • Kövesse a Kubernetes-számítás használatával kapcsolatos utasításokat a kimenő proxy ellenőrzéséhez, és győződjön meg arról, hogy a fürt képes csatlakozni a munkaterülethez. A munkaterület végpontJÁNAK URL-címét a fürt egyéni erőforrás-definíciójában (CRD) találja.

  • Ellenőrizze, hogy a munkaterület engedélyezi-e a nyilvános hozzáférést. Függetlenül attól, hogy maga az AKS-fürt nyilvános vagy privát, ha egy privát munkaterület letiltja a nyilvános hálózati hozzáférést, a Kubernetes-fürt csak privát kapcsolaton keresztül tud kommunikálni a munkaterülettel. További információ: Mi a biztonságos AKS-következtetési környezet?

HIBA: ACRAuthenticationChallengeFailed

Ez a hiba azért fordul elő, mert a Kubernetes-fürt nem tudja elérni a munkaterület Container Registry szolgáltatását a hitelesítési feladat elvégzéséhez. Ellenőrizze a hálózatot, különösen a Container Registry nyilvános hálózati hozzáférését, majd próbálkozzon újra. A hálózat ellenőrzéséhez kövesse a GetAADTokenFailed hibaelhárítási lépéseit.

HIBA: ACRTokenExchangeFailed

Ez a hiba azért fordul elő, mert a Microsoft Entra ID-jogkivonat még nincs engedélyezve, ezért a Kubernetes-fürt exchange Container Registry-jogkivonata meghiúsul. A szerepkör-hozzárendelés eltarthat egy ideig, ezért várjon egy percet, majd próbálkozzon újra.

Ennek a hibának az is lehet az oka, hogy túl sok egyidejű kérés érkezett a Container Registry szolgáltatáshoz. Ennek a hibának átmenetinek kell lennie, és később újra próbálkozhat.

HIBA: KubernetesUnaccessible

A Kubernetes-modell üzembe helyezése során a következő hibaüzenet jelenhet meg:

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

A hiba elhárításához elforgathatja a fürt AKS-tanúsítványát. Az új tanúsítványt 5 óra elteltével frissíteni kell, így 5 órát várhat, és újra üzembe helyezheti. További információ: Tanúsítványváltás az Azure Kubernetes Service-ben (AKS).

HIBA: ImagePullLoopBackOff

Ez a hiba a Kubernetes online üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg, mert nem tudja letölteni a lemezképeket a tárolóregisztrációs adatbázisból, ami a rendszerképek lekérési hibáját eredményezi. Ellenőrizze a fürt hálózati szabályzatát és a munkaterület tárolóregisztrációs adatbázisát, hogy a fürt le tudja-e húzni a lemezképeket a tárolóregisztrációs adatbázisból.

HIBA: DeploymentCrashLoopBackOff

Ez a hiba a Kubernetes online üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg, mert a felhasználói tároló összeomlott az inicializáláskor. A hiba két lehetséges oka lehet:

  • A score.py felhasználói szkript szintaxishibával vagy importálási hibával rendelkezik, amely kivételeket okoz az inicializálás során.
  • Az üzembehelyezési podnak több memóriára van szüksége, mint a korlátja.

A hiba elhárításához először ellenőrizze az üzembehelyezési naplókat a felhasználói szkriptek kivételeinél. Ha a hiba továbbra is fennáll, próbálja meg meghosszabbítani az erőforrás-/példánytípus memóriakorlátját.

HIBA: KubernetesCrashLoopBackOff

Ez a hiba a Kubernetes online végpontjainak vagy üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg az alábbi okok valamelyike miatt:

  • Egy vagy több pod elakadt CrashLoopBackoff állapotban. Ellenőrizze, hogy létezik-e az üzembehelyezési napló, és vannak-e hibaüzenetek a naplóban.
  • Hiba történt a score.py, és a tároló összeomlott a pontszámkód inicializálásakor. Kövesse a HIBA: ResourceNotReady című témakör utasításait.
  • A pontozási folyamatnak több memóriára van szüksége, mint az üzembe helyezés konfigurációs korlátja. Megpróbálhatja frissíteni az üzembe helyezést nagyobb memóriakorláttal.

HIBA: NamespaceNotFound

Ez a hiba a Kubernetes online végpontok létrehozásakor vagy frissítésekor jelenhet meg, mert a Kubernetes-számítás által használt névtér nem érhető el a fürtben. Ellenőrizze a Kubernetes-számítást a munkaterület portálján, és ellenőrizze a névteret a Kubernetes-fürtben. Ha a névtér nem érhető el, válassza le az örökölt számítást, és hozzon létre újra egy újat, és adjon meg egy olyan névteret, amely már létezik a fürtben.

HIBA: UserScriptInitFailed

Ez a hiba a Kubernetes online üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg, mert a init feltöltött score.py fájlban lévő függvény kivételt okozott. Ellenőrizze az üzembehelyezési naplókat a kivételről szóló üzenet részletes megtekintéséhez és a kivétel kijavításához.

HIBA: UserScriptImportError

Ez a hiba a Kubernetes online üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg, mert a feltöltött score.py fájl nem érhető el. Ellenőrizze az üzembehelyezési naplókat a kivételről szóló üzenet részletes megtekintéséhez és a kivétel kijavításához.

HIBA: UserScriptFunctionNotFound

Ez a hiba a Kubernetes online üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg, mert a feltöltött score.py fájl nem rendelkezik elnevezett init() run()vagy . Ellenőrizze a kódot, és adja hozzá a függvényt.

HIBA: EndpointNotFound

Ez a hiba a Kubernetes online üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg, mert a rendszer nem találja a fürtben az üzembe helyezés végponterőforrását. Hozza létre az üzembe helyezést egy meglévő végponton, vagy hozza létre először a végpontot a fürtben.

HIBA: EndpointAlreadyExists

Ez a hiba akkor jelenhet meg, ha egy Kubernetes online végpontot hoz létre, mert a végpont már létezik a fürtben. A végpont nevének munkaterületenként és fürtönként egyedinek kell lennie, ezért hozzon létre egy másik nevű végpontot.

HIBA: ScoringFeUnhealthy

Ez a hiba a Kubernetes online végpontjának vagy üzembe helyezésének létrehozásakor vagy frissítésekor jelenhet meg, mert a fürtben futó azureml-fe rendszerszolgáltatás nem található vagy nem megfelelő. A probléma megoldásához telepítse újra vagy frissítse az Azure Machine Learning-bővítményt a fürtben.

HIBA: ValidateScoringFailed

Ez a hiba a Kubernetes online üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg, mert a pontozási kérelem URL-ének érvényesítése nem sikerült a modell feldolgozásakor. Ellenőrizze a végpont URL-címét, majd próbálja meg újból üzembe helyezni.

HIBA: InvalidDeploymentSpec

Ez a hiba a Kubernetes online üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg, mert az üzembehelyezési specifikáció érvénytelen. Ellenőrizze a hibaüzenetet, hogy érvényes-e instance count . Ha engedélyezte az automatikus skálázást, győződjön meg arról, hogy az minimum instance count maximum instance count és mindkettő érvényes.

HIBA: PodUnschedulable

Ez a hiba a Kubernetes online végpontjainak vagy üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg az alábbi okok valamelyike miatt:

  • A rendszer nem tudja ütemezni a podot csomópontokra, mert nincs elegendő erőforrás a fürtben.
  • Egyetlen csomópont sem felel meg a csomópont affinitási választójának.

A hiba elhárításához kövesse az alábbi lépéseket:

  1. Ellenőrizze a node selector használt definíciót instance_type és a node label fürtcsomópontok konfigurációját.
  2. Ellenőrizze az instance_type AKS-fürt vagy az Azure Arc-kompatibilis Kubernetes-fürt csomóponterőforrásának méretét és a csomópont termékváltozatának méretét.
  3. Ha a fürt erőforrása nem megfelelő, csökkentse a példánytípus erőforrásigényét, vagy használjon másik, kisebb erőforrásigényű példánytípust.
  4. Ha a fürt nem rendelkezik több erőforrással az üzembe helyezés követelményeinek teljesítéséhez, törölje az erőforrások kiadásához szükséges egyes üzembe helyezéseket.

HIBA: PodOutOfMemory

Ez a hiba akkor jelenhet meg, ha online üzembe helyezést hoz létre vagy frissít, mert az üzembe helyezéshez megadott memóriakorlát nem elegendő. A hiba elhárításához beállíthatja a memóriakorlátot egy nagyobb értékre, vagy használhat nagyobb példánytípust.

HIBA: InferencingClientCallFailed

Ez a hiba a Kubernetes online végpontjainak vagy üzemelő példányainak létrehozásakor vagy frissítésekor jelenhet meg, mert a Kubernetes-fürt k8s-bővítménye nem csatlakoztatható. Ebben az esetben leválaszthatja, majd újracsatlakoztathatja a számítást.

Ha újracsatlakoztatással szeretné elhárítani a hibákat, az egyéb hibák elkerülése érdekében győződjön meg arról, hogy a leválasztott számítással megegyező konfigurációval, például a számítási névvel és a névtérrel szeretne újracsatlakozni. Ha még mindig nem működik, kérje meg a fürtöt elérő rendszergazdát, hogy kubectl get po -n azureml ellenőrizze, hogy futnak-e a továbbítókiszolgáló podjai.

Modellhasználati problémák

A végpontművelet invoke állapotából eredő gyakori modellhasználati hibák közé tartoznak a sávszélességkorlátmal kapcsolatos problémák, a CORS-szabályzat és a különböző HTTP-állapotkódok.

Sávszélesség korlátozásával kapcsolatos problémák

A felügyelt online végpontok sávszélességkorlátokkal rendelkeznek az egyes végpontokhoz. A korlátkonfigurációt az online végpontok korlátai között találja. Ha a sávszélesség-használat meghaladja a korlátot, a kérés késik.

A sávszélesség késleltetésének figyeléséhez használja a metrika hálózati bájtokat az aktuális sávszélesség-használat megértéséhez. További információ: Felügyelt online végpontok figyelése.

A sávszélesség-korlát kényszerítése esetén a rendszer két válasz-pótkocsit ad vissza:

  • ms-azureml-bandwidth-request-delay-ms ezredmásodpercben megadott késleltetési idő, amely a kérelemfolyam átviteléhez szükséges.
  • ms-azureml-bandwidth-response-delay-msezredmásodpercben a válaszfolyam-átvitel késleltetési ideje.

CORS-szabályzat letiltva

A V2 online végpontjai natív módon nem támogatják a több forrásból származó erőforrás-megosztást (CORS). Ha a webalkalmazás a CORS-elővizsgálati kérések megfelelő kezelése nélkül próbálja meg meghívni a végpontot, a következő hibaüzenet jelenhet meg:

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.

Az Azure Functions, az Azure-alkalmazás Gateway vagy egy másik szolgáltatás köztes rétegként is használható a CORS elővizsgálati kéréseinek kezeléséhez.

HTTP-állapotkódok

Amikor REST-kérésekkel fér hozzá az online végpontokhoz, a visszaadott állapotkódok megfelelnek a HTTP-állapotkódok szabványainak. A következő szakaszok részletesen bemutatják, hogyan képezik le a végpontok hívási és előrejelzési hibái a HTTP-állapotkódokat.

Felügyelt online végpontok gyakori hibakódjai

Az alábbi táblázat gyakori hibakódokat tartalmaz, amikor a REST-kérelmek felügyelt online végpontokat használnak:

Állapotkód Ok Leírás
200 OK A modell sikeresen végrehajtotta a késési korlátokon belül.
401 Nem engedélyezett Nem rendelkezik engedéllyel a kért művelet végrehajtásához, például a pontszámhoz, vagy a jogkivonat lejárt, vagy nem megfelelő formátumú. További információ: Hitelesítés felügyelt online végpontokhoz és Ügyfelek hitelesítése online végpontokhoz.
404 Nem található A végpont nem rendelkezik érvényes, pozitív súlyú üzembe helyezéssel.
408 Kérés-időtúllépés A modell végrehajtása hosszabb ideig tartott, mint a modell üzembe helyezési konfigurációjában request_timeout_ms request_settings megadott időtúllépés.
424 Modellhiba Ha a modelltároló nem 200-ra ad vissza választ, az Azure egy 424-et ad vissza. Ellenőrizze a dimenziót Model Status Code a Requests Per Minute végpont Azure Monitor Metric Explorerében található metrika alatt. Vagy ellenőrizze a válaszfejléceket ms-azureml-model-error-statuscode és ms-azureml-model-error-reason további információkat. Ha a 424-hez az élettartam vagy a készültségi mintavétel meghiúsul, fontolja meg a ProbeSettings beállítását, hogy több idő legyen a tároló élettartamának vagy készültségének mintavételezésére.
429 Túl sok függőben lévő kérés A modell jelenleg több kérést kap, mint amennyit kezelni tud. A zökkenőmentes működés biztosítása érdekében az Azure Machine Learning egy adott időpontban legfeljebb 2 * max_concurrent_requests_per_instance * instance_count requests párhuzamos feldolgozást engedélyez. A maximális értéket meghaladó kérelmeket a rendszer elutasítja.

A beállítások ellenőrzéséhez és módosításához tekintse át a modell üzembehelyezési konfigurációját a request_settings szakaszokban és scale_settings a szakaszokban. Győződjön meg arról is, hogy a környezeti változó WORKER_COUNT megfelelően van átadva a RequestSettingsben leírtaknak megfelelően.

Ha ez a hiba automatikus skálázás használatakor jelenik meg, a modell gyorsabban kap kéréseket, mint amennyit a rendszer fel tud skálázni. Fontolja meg a kérelmek ismételt küldését exponenciális visszalépéssel, hogy a rendszer időt kapjon a beállításra. A példányok számát a példányok számának kiszámításához kód használatával is növelheti. Kombinálja ezeket a lépéseket az automatikus skálázás beállításával, hogy a modell készen álljon a kérelmek beáramlásának kezelésére.
429 Korlátozott sebesség A másodpercenkénti kérelmek száma elérte a felügyelt online végpontok korlátait.
500 Belső kiszolgálóhiba Az Azure Machine Learning által kiosztott infrastruktúra meghibásodik.

Kubernetes online végpontok gyakori hibakódjai

Az alábbi táblázat gyakori hibakódokat tartalmaz, amikor a REST-kérések Kubernetes online végpontokat használnak:

Állapotkód Hiba Leírás
409 Ütközési hiba Ha egy művelet már folyamatban van, ugyanazon az online végponton lévő új műveletek 409-beli ütközési hibával válaszolnak. Ha például egy online végpont létrehozása vagy frissítése folyamatban van, egy új törlési művelet aktiválása hibát jelez.
502 Kivétel vagy összeomlás a run() score.py fájl metódusában Ha hiba lép fel a score.py, például egy olyan importált csomag, amely nem létezik a conda környezetben, szintaxishiba vagy a metódus hibája init() , tekintse meg a HIBA: ResourceNotReady hiba a fájl hibakereséséhez.
503 Nagy csúcsértékek másodpercenkénti kérelmekben Az automatikus skálázási funkció a terhelés fokozatos változásainak kezelésére lett kialakítva. Ha másodpercenként nagy számú kérést kap, előfordulhat, hogy az ügyfelek 503-os HTTP-állapotkódot kapnak. Annak ellenére, hogy az automatikus skálázási eszköz gyorsan reagál, az AKS jelentős mennyiségű időt vesz igénybe, hogy több tárolót hozzon létre. Lásd : Az 503-ra vonatkozó állapotkódhibák megelőzése.
504 A kérés túllépi az időkorlátot Az 504-ben megadott állapotkód azt jelzi, hogy a kérés túllépte az időkorlátot. Az alapértelmezett időtúllépési beállítás 5 másodperc. Növelheti az időtúllépést, vagy megpróbálhatja felgyorsítani a végpontot úgy, hogy módosítja a score.py a szükségtelen hívások eltávolításához. Ha ezek a műveletek nem oldják meg a problémát, előfordulhat, hogy a kód nem válaszoló állapotban vagy végtelen ciklusban van. Kövesse az ALÁBBI HIBAÜZENETET: A ResourceNotReady hibakeresést hajt végre a score.py fájlban.
500 Belső kiszolgálóhiba Az Azure Machine Learning által kiosztott infrastruktúra meghibásodik.

503-ra vonatkozó állapotkódhibák megelőzése

A Kubernetes online üzembe helyezései támogatják az automatikus skálázást, amely lehetővé teszi a replikák hozzáadását a többletterhelés támogatásához. További információ: Azure Machine Learning következtetési útválasztó. A vertikális fel- vagy leskálázás a jelenlegi tárolóreplikák kihasználtságán alapul.

Két művelet segíthet megelőzni az 503-as állapotkódhibákat: módosíthatja az új replikák létrehozásának kihasználtsági szintjét, vagy módosíthatja a replikák minimális számát. Ezeket a megközelítéseket egyenként vagy kombinálva is használhatja.

  • Módosítsa azt a kihasználtsági célt, amelynél az automatikus skálázás új replikákat hoz létre az autoscale_target_utilization alacsonyabb értékre állítással. Ez a változás nem eredményezi a replikák gyorsabb létrehozását, hanem alacsonyabb kihasználtsági küszöbértéket. Ha például 30%-ra módosítja az értéket, a replikák akkor jönnek létre, amikor a 30%-os kihasználtság ahelyett, hogy a szolgáltatás 70%-os kihasználtságára vár.

  • Módosítsa a replikák minimális számát, hogy nagyobb készletet biztosítson, amely képes kezelni a bejövő kiugró értékeket.

Példányszám kiszámítása

A példányok számának növeléséhez az alábbiak szerint számíthatja ki a szükséges replikákat:

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)

Feljegyzés

Ha az új minimális replikáknál nagyobb kérelmeket kap, előfordulhat, hogy ismét 503-at kap. A végpont felé irányuló forgalom növekedésével például előfordulhat, hogy növelnie kell a minimális replikákat.

Ha a Kubernetes online végpontja már használja az aktuális maximális replikákat, és továbbra is 503 állapotkódot kap, növelje az autoscale_max_replicas értéket a replikák maximális számának növeléséhez.

Hálózatelkülönítési problémák

Ez a szakasz a hálózatelkülönítéssel kapcsolatos gyakori problémákról nyújt tájékoztatást.

Az online végpont létrehozása meghiúsul a következő üzenettel: V1LegacyMode == true

Konfigurálhatja az Azure Machine Learning-munkaterületet v1_legacy_mode, amely letiltja a v2 API-kat. A felügyelt online végpontok a v2 API platform egyik funkciója, és nem működnek, ha v1_legacy_mode engedélyezve vannak a munkaterületen.

A letiltásról v1_legacy_modelásd a hálózatelkülönítést a v2-vel.

Fontos

A letiltás v1_legacy_modeelőtt forduljon a hálózati biztonsági csapathoz, mert lehetséges, hogy valamilyen okból engedélyezték.

Az online végpont kulcsalapú hitelesítéssel való létrehozása meghiúsul

Az alábbi paranccsal listázhatja a munkaterület azure-kulcstartójának hálózati szabályait. Cserélje le <keyvault-name> a kulcstartó nevére:

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

A parancs válasza hasonló a következő JSON-kódhoz:

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

Ha az érték bypass nemAzureServices, a Key Vault hálózati beállításainak konfigurálásához használja az útmutatótAzureServices.

Az online üzemelő példányok egy rendszerkép letöltésével kapcsolatos hibaüzenettel meghiúsulnak

Feljegyzés

Ez a probléma akkor érvényes, ha a felügyelt online végpontokhoz az örökölt hálózatelkülönítési módszert használja, amelyben az Azure Machine Learning egy felügyelt virtuális hálózatot hoz létre minden egyes üzembe helyezéshez egy végpont alatt.

  1. Ellenőrizze, hogy a egress-public-network-access jelző az üzembe helyezéshez tartozik-e disabled . Ha ez a jelző engedélyezve van, és a tárolóregisztrációs adatbázis láthatósága privát, ez a hiba várható.

  2. A privát végpontkapcsolat állapotának ellenőrzéséhez használja az alábbi parancsot. Cserélje le <registry-name> a munkaterület azure-tárolóregisztrációs adatbázisának nevére:

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

    A válaszkódban ellenőrizze, hogy a status mező be van-e állítva Approved. Ha nem, a következő paranccsal hagyja jóvá. Cserélje le <private-endpoint-name> az előző parancsból visszaadott névre.

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

A pontozási végpont nem oldható fel

  1. Ellenőrizze, hogy a pontozási kérelmet kiállító ügyfél egy olyan virtuális hálózat-e, amely hozzáfér az Azure Machine Learning-munkaterülethez.

  2. nslookup A végpont állomásneve parancsával kérje le az IP-cím adatait, például:

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

    A válasz egy címet tartalmaz, amely a virtuális hálózat által megadott tartományban kell lennie.

    Feljegyzés

    • Kubernetes online végpont esetén a végpont gazdagépneve a Kubernetes-fürtben megadott CName (tartománynév).
    • Ha a végpont HTTP, az IP-cím a végpont URI-jában található, amelyet a studio felhasználói felületéről szerezhet be.
    • A végpont IP-címének lekérésére további módszereket is találhat a Biztonságos Kubernetes online végpontján.

  3. Ha a nslookup parancs nem oldja fel a gazdagép nevét, hajtsa végre a következő műveleteket:

Felügyelt online végpontok

  1. Az alábbi paranccsal ellenőrizheti, hogy létezik-e A rekord a virtuális hálózat privát tartománynév-kiszolgálójának (DNS) zónájában.

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

    Az eredményeknek a következőhöz hasonló bejegyzést kell tartalmazniuk *.<GUID>.inference.<region>.

  2. Ha nem ad vissza következtetési értéket, törölje a munkaterület privát végpontját, majd hozza létre újra. További információ: Privát végpont konfigurálása.

  3. Ha a privát végponttal rendelkező munkaterület egyéni DNS-kiszolgálót használ, futtassa az alábbi parancsot annak ellenőrzéséhez, hogy az egyéni DNS-ből származó feloldás megfelelően működik-e.

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

Online Kubernetes-végpontok

  1. Ellenőrizze a DNS-konfigurációt a Kubernetes-fürtben.

  2. Ellenőrizze azt is, hogy az azureml-fe a várt módon működik-e a következő paranccsal:

    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"

    HTTP esetén használja a következő parancsot:

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

  3. Ha a curl HTTP-k sikertelenek vagy időtúllépést jeleznek, de a HTTP működik, ellenőrizze, hogy a tanúsítvány érvényes-e.

  4. Ha az előző folyamat nem oldható fel az A rekordra, ellenőrizze, hogy a feloldás működik-e az Azure DNS-ből (168.63.129.16).

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

  5. Ha az előző parancs sikeres, az egyéni DNS-en található privát hivatkozás feltételes továbbítójának hibaelhárítása.

Az online üzemelő példányok nem pontozhatók

  1. Futtassa a következő parancsot annak megtekintéséhez, hogy az üzembe helyezés sikeres volt-e:

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

    Ha az üzembe helyezés sikeresen befejeződött, az érték state a következő Succeeded: .

  2. Ha az üzembe helyezés sikeres volt, az alábbi paranccsal ellenőrizze, hogy a forgalom hozzá van-e rendelve az üzemelő példányhoz. Cserélje le <endpointname> a végpont nevére.

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

    A parancs válaszának fel kell sorolnia az üzemelő példányokhoz rendelt forgalom százalékos arányát.

    Tipp.

    Ez a lépés nem szükséges, ha a azureml-model-deployment kérés fejlécét használja az üzemelő példány megcélzásához.

  3. Ha a forgalom-hozzárendelések vagy az üzembehelyezési fejléc helyesen van beállítva, az alábbi paranccsal kérje le a végpont naplóit. Cserélje le <endpointname> a végpont nevére és <deploymentname> az üzembe helyezésre.

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

  4. Tekintse át a naplókat, és ellenőrizze, hogy probléma van-e a pontozási kód futtatásával, amikor kérelmet küld az üzembe helyezéshez.

Következtetési kiszolgálóval kapcsolatos problémák

Ez a szakasz alapvető hibaelhárítási tippeket tartalmaz az Azure Machine Learning következtetési HTTP-kiszolgálójához.

Telepített csomagok ellenőrzése

A telepített csomagokkal kapcsolatos problémák megoldásához kövesse az alábbi lépéseket.

  1. Információkat gyűjthet a Python-környezet telepített csomagjairól és verzióiról.

  2. Ellenőrizze, hogy a azureml-inference-server-http környezeti fájlban megadott Python-csomag verziója megegyezik-e az indítási naplóban megjelenített Azure Machine Learning-következtetés HTTP-kiszolgáló verziójával.

    Bizonyos esetekben a pipfüggőség-feloldó nem várt csomagverziókat telepít. Előfordulhat, hogy futtatnia pip kell a telepített csomagok és verziók kijavításához.

  3. Ha megadja a Flaskot vagy annak függőségeit a környezetben, távolítsa el ezeket az elemeket.

    • A függő csomagok a következők: flask, jinja2, itsdangerous, werkzeug, markupsafeés click.
    • flask függőségként szerepel a kiszolgálócsomagban. A legjobb módszer, ha engedélyezi a következtetési kiszolgáló számára a flask csomag telepítését.
    • Ha a következtetési kiszolgáló úgy van konfigurálva, hogy támogassa a Flask új verzióit, a kiszolgáló automatikusan megkapja a csomagfrissítéseket, amint elérhetővé válnak.

Kiszolgáló verziójának ellenőrzése

A azureml-inference-server-http kiszolgálócsomag közzé van téve a PyPI-ban. A PyPI-oldal felsorolja a változásnaplót és az összes korábbi verziót.

Ha korábbi csomagverziót használ, frissítse a konfigurációt a legújabb verzióra. Az alábbi táblázat a stabil verziókat, a gyakori problémákat és a javasolt módosításokat foglalja össze:

Csomag verziója Leírás Probléma Feloldás
0.4.x Betanítási képekbe csomagolva, dátummal 20220601 vagy korábbi dátummal, valamint azureml-defaults csomagverziókkal.1.34.1.43 A legújabb stabil verzió a 0.4.13. A 0.4.11-nél korábbi kiszolgálóverziók esetében előfordulhat, hogy a Flask függőségi problémái merülnek fel, például"can't import name Markup from jinja2". Ha lehetséges, frissítsen a 0.4.13-es vagy a 0.8.x-es verzióra.
0.6.x Előre telepítette a dátummal és a korábbi dátummal megadott 20220516 képek következtetését. A legújabb stabil verzió a 0.6.1. N.A. N.A.
0.7.x Támogatja a Flask 2-t. A legújabb stabil verzió a 0.7.7. N.A. N.A.
0.8.x A naplóformátum megváltozott. A Python 3.6 támogatása véget ért. N.A. N.A.

Csomagfüggőségek ellenőrzése

A kiszolgálócsomag legfontosabb függő csomagjai a azureml-inference-server-http következők:

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

Ha a csomagot Python-környezetben azureml-defaults adta meg, a azureml-inference-server-http csomag függő csomag. A függőség telepítése automatikusan megtörténik.

Tipp.

Ha Python SDK v1-et használ, és nem adja meg explicit módon a csomagot a azureml-defaults Python-környezetben, előfordulhat, hogy az SDK automatikusan hozzáadja a csomagot. A csomagkezelő verziója azonban az SDK-verzióhoz képest zárolva van. Ha például az SDK verziója, 1.38.0akkor a rendszer hozzáadja a azureml-defaults==1.38.0 bejegyzést a környezet pipkövetelményeihez.

TypeError a kiszolgáló indításakor

A kiszolgáló indításakor az alábbiakat TypeError tapasztalhatja:

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

Ez a hiba akkor fordul elő, ha a Flask 2 telepítve van a Python-környezetben, de a azureml-inference-server-http csomag verziója nem támogatja a Flask 2-t. A Flask 2 támogatása a 0.7.0-s és újabb csomagban, valamint azureml-defaults az 1.44-es és újabb csomagban azureml-inference-server-http érhető el.

  • Ha nem használja a Flask 2 csomagot egy Azure Machine Learning Docker-rendszerképben, használja a azureml-inference-server-http csomag legújabb azureml-defaults verzióját.

  • Ha a Flask 2 csomagot egy Azure Machine Learning Docker-rendszerképben használja, győződjön meg arról, hogy a rendszerkép buildjének verziója 2022 . júliusi vagy újabb.

    A rendszerkép verziója a tárolónaplókban található. Példa:

    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 |

    A kép buildelési dátuma a Materialization Build jelölés után jelenik meg. Az előző példában a kép verziója 20220708 vagy 2022. július 8. A példában szereplő kép kompatibilis a Flask 2-vel.

    Ha nem lát hasonló üzenetet a tárolónaplóban, a rendszerkép elavult, ezért frissítenie kell. Ha számítási egyesített eszközarchitektúra (CUDA) rendszerképet használ, és nem talál újabb rendszerképet, ellenőrizze, hogy a rendszerkép elavult-e az AzureML-Tárolókban. Az elavult képekhez kijelölt helyettesítőket is megtalálhatja.

    Ha a kiszolgálót online végponttal használja, a naplókat az Azure Machine Learning Studio Végpontok lapján található Naplók lapon is megtalálhatja.

Ha az SDK 1-es verziójával telepít, és nem ad meg explicit módon lemezképet az üzembe helyezési konfigurációban, a kiszolgáló a openmpi4.1.0-ubuntu20.04 csomagot a helyi SDK-eszközkészletnek megfelelő verzióval alkalmazza. Előfordulhat azonban, hogy a telepített verzió nem a rendszerkép legújabb elérhető verziója.

Az SDK 1.43-es verziója esetén a kiszolgáló alapértelmezés szerint telepíti a openmpi4.1.0-ubuntu20.04:20220616 csomagverziót, de ez a csomagverzió nem kompatibilis az SDK 1.43-zal. Győződjön meg arról, hogy a legújabb SDK-t használja az üzembe helyezéshez.

Ha nem tudja frissíteni a képet, ideiglenesen elkerülheti a problémát a azureml-defaults==1.43 környezeti fájlban lévő bejegyzések vagy azureml-inference-server-http~=0.4.13 bejegyzések rögzítésével. Ezek a bejegyzések arra utasítják a kiszolgálót, hogy telepítse a régebbi verziót a következővel flask 1.0.x: .

ImportError vagy ModuleNotFoundError a kiszolgáló indításakor

Előfordulhat, hogy a kiszolgáló indításakor egy ImportError vagy ModuleNotFoundError több modullal találkozik, például opencensus, jinja2, markupsafevagy click. Az alábbi példa a hibaüzenetet mutatja be:

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

Az importálási és modulhibák akkor fordulnak elő, ha a kiszolgáló 0.4.10-es vagy korábbi verzióit használja, amelyek nem rögzítik a Flask-függőséget egy kompatibilis verzióra. A probléma elkerülése érdekében telepítse a kiszolgáló egy későbbi verzióját.

Egyéb gyakori problémák

Az online végpontokkal kapcsolatos egyéb gyakori problémák a Conda telepítésével és automatikus skálázásával kapcsolatosak.

A Conda telepítésével kapcsolatos problémák

Az MLflow telepítésével kapcsolatos problémák általában a conda.yml fájlban megadott felhasználói környezet telepítésével kapcsolatos problémákból erednek.

A Conda telepítési problémáinak hibakereséséhez próbálkozzon az alábbi lépésekkel:

  1. Ellenőrizze a conda telepítési naplóit. Ha a tároló összeomlott, vagy túl sokáig tartott az indítás, a Conda-környezet frissítése valószínűleg nem sikerült megfelelően feloldani.
  2. Telepítse az mlflow conda fájlt helyileg a paranccsal conda env create -n userenv -f <CONDA_ENV_FILENAME>.
  3. Ha helyi hibák merülnek fel, próbálja meg feloldani a conda környezetet, és hozzon létre egy működőt az újbóli üzembe helyezés előtt.
  4. Ha a tároló akkor is összeomlik, ha helyileg oldja fel a problémát, az üzembe helyezéshez használt termékváltozat mérete túl kicsi lehet.
    • A Conda-csomag telepítése futásidőben történik, így ha az termékváltozat mérete túl kicsi ahhoz, hogy az conda.yml környezeti fájlban lévő összes csomagot elférjen, a tároló összeomlhat.
    • A Standard_F4s_v2 virtuális gép jó kezdő termékváltozat-méret, de a conda-fájl által megadott függőségek függvényében nagyobb virtuális gépekre lehet szükség.
    • Kubernetes online végpontok esetén a Kubernetes-fürtnek legalább négy vCPU-maggal és 8 GB memóriával kell rendelkeznie.

Automatikus méretezési problémák

Ha problémái vannak az automatikus skálázással, tekintse meg az Azure Monitor automatikus skálázásának hibaelhárítását.

Az online Kubernetes-végpontok esetében az Azure Machine Learning következtetési útválasztó egy előtérbeli összetevő, amely a Kubernetes-fürt összes modelltelepítéséhez automatikus skálázást kezel. További információ: Automatikus skálázási Kubernetes-következtetési útválasztás.

Kapcsolódó tartalom