Online végpontok ü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)

Megtudhatja, hogyan oldhatja meg az Azure Machine Tanulás online végpontok üzembe helyezésével és pontozásával kapcsolatos gyakori problémákat.

Ez a dokumentum a hibaelhárításhoz szükséges módon van felépítve:

  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 a VÉGPONTOK REST-kérésekkel való pontozásakor.

Előfeltételek

Helyi üzembe helyezés

A helyi üzemelő példány azt jelenti, hogy egy helyi Docker-környezetben helyezi üzembe a modelleket. 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 Tanulás következtetési HTTP-kiszolgáló 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.

A helyi üzembe helyezés támogatja a helyi végpontok létrehozását, frissítését és törlését. Azt is lehetővé teszi, hogy naplókat hívjon meg és kérjen le a végpontról.

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

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

A helyi üzembe helyezés részeként a következő lépések történnek:

  • 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 rendszer egy meglévő lemezképet használ, ha van olyan, amely megfelel a specifikációs fájl környezeti részének.
  • A Docker egy új tárolót indít el csatlakoztatott helyi összetevőkkel, például modell- és kódfájlokkal.

További információ: Helyi üzembe helyezés az üzembe helyezésben és gépi tanulási modell pontozása.

Tipp.

A végpontok helyi teszteléséhez és hibakereséséhez használja a Visual Studio Code-ot. További információ: online végpontok helyi hibakeresése a Visual Studio Code-ban.

Conda telepítése

Az MLflow telepítésével kapcsolatos problémák általában a fájlban conda.yaml 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 naplókban a Conda telepítését. Ha a tároló összeomlott, vagy túl sokáig tart az indítás, valószínű, hogy a Conda-környezet frissítése nem oldódott meg megfelelően.

  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.

    1. A Conda-csomag telepítése futásidőben történik, ezért ha a termékváltozat mérete túl kicsi a környezeti fájlban conda.yaml részletezett összes csomag elhelyezéséhez, a tároló összeomlhat.
    2. A Standard_F4s_v2 virtuális gép jó kezdő termékváltozat-méret, de nagyobb méretűre lehet szükség attól függően, hogy mely függőségek vannak megadva a conda-fájlban.
    3. Kubernetes online végpont esetén a Kubernetes-fürtnek legalább 4 vCPU maggal és 8 GB memóriával kell rendelkeznie.

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

Nem férhet hozzá közvetlenül ahhoz a virtuális géphez, amelyen a modell üzembe lett helyezve. Lekérhet azonban naplókat a virtuális gépen futó egyes tárolókból. 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 egy üzenetet kap, amely később újrapróbálkozhat.

Kétféle tárolóból szerezheti be a naplókat:

  • Következtetési kiszolgáló: A naplók tartalmazzák a konzolnaplót (a következtetési kiszolgálóról), amely a pontozószkriptből (score.pykódból) származó nyomtatási/naplózási függvények kimenetét tartalmazza.
  • Tároló inicializáló: A naplók információkat tartalmaznak arról, hogy a kód- és modelladatok sikeresen le lettek-e töltve a tárolóba. A tároló a következtetési kiszolgáló tárolójának futtatása előtt fut.

A tároló naplókimenetének megtekintéséhez használja a következő PARANCSSOR-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

Adja hozzá és --workspace-name vegye fel --resource-group ezeket a parancsokat, ha még nem állította be ezeket a paramétereket.az configure

A paraméterek beállításáról és az értékek beállításáról a következő parancs futtatásával tájékozódhat:

az ml online-deployment get-logs -h

Alapértelmezés szerint a rendszer lekérte a naplókat a következtetési kiszolgálóról.

Feljegyzés

Ha Python-naplózást használ, győződjön meg arról, hogy a megfelelő naplózási szintű sorrendet használja a naplókban közzéteendő üzenetekhez. Például: INFO.

A tároló inicializáló tárolójából is lekérheti a naplókat a továbbítással –-container storage-initializer.

További információk megjelenítéséhez adjon hozzá és/vagy --debug adjon hozzá --help parancsokat.

A Kubernetes online végpontja esetében a rendszergazdák közvetlenül hozzáférhetnek ahhoz a fürthöz, ahol a modellt üzembe helyezik, ami rugalmasabb számukra a Kubernetes-napló ellenőrzéséhez. Példa:

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

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. Felülbíráljuk ezt a fejlécet, hogy érvényes GUID legyen.

    Feljegyzés

    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.

  • x-ms-client-request-id az ügyfél-nyomkövetési forgatókönyvekhez érhető el. Ez az élőfej úgy van megtisztítva, hogy csak alfanumerikus karaktereket, kötőjeleket és aláhúzásjeleket fogadjon el, és legfeljebb 40 karakterre csonkolja.

Gyakori telepítési hibák

Az alábbi lista az üzembe helyezési művelet állapotának részeként jelentett gyakori üzembehelyezési hibákat tartalmazza:

Ha Online Kubernetes-telepítést hoz létre vagy frissít, a Kubernetes-telepítésekkel kapcsolatos gyakori hibák láthatók.

HIBA: ImageBuildFailure

Ez a hiba a környezet (docker-rendszerkép) létrehozásakor jelenik meg. A hiba(ok)ról további információt a buildnaplóban talál. A buildnapló az Azure Machine Tanulás-munkaterület alapértelmezett tárolójában található. Lehetséges, hogy a pontos hely a hiba részeként jelenik meg. Például: "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

Az alábbi lista a rendszerképek buildelési hibáinak gyakori forgatókönyveit tartalmazza:

Azt is javasoljuk, hogy tekintse át az alapértelmezett mintavételi beállításokat , ha az ImageBuild időtúllépésekkel rendelkezik.

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

Ha a hibaüzenet megemlíti "container registry authorization failure" , az azt jelenti, hogy nem férhet hozzá a tárolóregisztrációs adatbázishoz az aktuális hitelesítő adatokkal. A munkaterület-erőforrás kulcsainak deszinkronizálása okozhatja ezt a hibát, és időbe telik az automatikus szinkronizálás. Manuálisan azonban meghívhatja a kulcsok szinkronizálását, ami megoldhatja az engedélyezési hibát.

A virtuális hálózat mögötti tárolóregisztrációs adatbázisok is tapasztalhatják ezt a hibát, ha helytelenül vannak beállítva. Ellenőriznie kell, 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 a 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 virtuális hálózatokat használ, és a munkaterület Azure Container Registry-adatbázisa privát, és privát végponttal van konfigurálva, engedélyeznie kell az Azure Container Registryt , hogy lehetővé tegye a rendszerképek létrehozását a virtuális hálózaton.

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

Ahogy korábban már említettem, a buildnaplóban további információt találhat a hibáról. Ha nem található nyilvánvaló hiba a buildnaplóban, és az utolsó sor az Installing pip dependencies: ...working..., akkor egy függőség okozhatja a hibát. A conda-fájl verziófüggőségeinek rögzítése megoldhatja ezt a problémát.

Azt is javasoljuk, hogy helyileg helyezzen üzembe a modellek teszteléséhez és hibakereséséhez, mielőtt üzembe helyeznénk a felhőben.

HIBA: OutOfQuota

Az alábbi lista olyan gyakori erőforrásokat tartalmaz, amelyek az Azure-szolgáltatások használatakor elfogyhatnak a kvótából:

Emellett az alábbi lista olyan gyakori erőforrásokat tartalmaz, amelyek csak a Kubernetes online végpontja esetében fogyhatnak ki a kvótából:

CPU-kvóta

A modell üzembe helyezése előtt elegendő számítási kvótával kell rendelkeznie. Ez a kvóta határozza meg, hogy előfizetésenként, munkaterületenként, termékváltozatonként és régiónként mennyi 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.

Lehetséges kockázatcsökkentés annak ellenőrzése, hogy vannak-e nem használt üzembe helyezések, amelyeket törölhet. Vagy elküldheti a kvótanövelésre vonatkozó kérelmet.

Fürtkvóta

Ez a probléma akkor fordul elő, ha nincs elegendő Azure Machine-Tanulás számítási fürtkvótája. Ez a kvóta határozza meg az előfizetésenként egyszerre használt fürtök teljes számát a CPU- vagy GPU-csomópontok Azure Cloudban való üzembe helyezéséhez.

Lehetséges kockázatcsökkentés annak ellenőrzése, hogy vannak-e nem használt üzembe helyezések, amelyeket törölhet. Vagy elküldheti a kvótanövelésre vonatkozó kérelmet. Győződjön meg arról, hogy a kvótanövelési kérelemhez kvótatípust választ Machine Learning Service: Cluster Quota .

Lemezkvóta

Ez a probléma 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álkozzon több lemezterülettel rendelkező termékváltozattal , vagy csökkentse a kép és a modell méretét.

Memóriakvóta

Ez a probléma 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éri a szerepkör-hozzárendelés korlátját , próbáljon törölni néhány nem használt szerepkör-hozzárendelést ebben az előfizetésben. Az Azure Portalon az összes szerepkör-hozzárendelést a Hozzáférés-vezérlés menüben ellenőrizheti.

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, megpróbálkozhat a végpontkorlát növelésével. A végpontkorláttal kapcsolatos további információkért tekintse meg az Azure Machine-Tanulás online végpontokkal és kötegelt végpontokkal rendelkező végpontkvótát.

Kubernetes-kvóta

Ez a probléma 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 azt jelzi, hogy az erőforrás nem elegendő a fürtben, ami azt jelenti, hogy túl sok pod található a fürtben, OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods...és nincs elegendő erőforrás az új modellnek a kérés alapján történő üzembe helyezéséhez.

A probléma megoldásához próbálja ki az alábbi megoldásokat:

  • A Kubernetes-fürtöt karbantartó informatikai op-k számára megpróbálhat további csomópontokat hozzáadni, vagy törölni néhány nem használt podot a fürtben, hogy felszabadítson néhány erőforrást.
  • A modelleket üzembe helyező gépi tanulási mérnökök számára megpróbálhatja 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, megpróbálhatja csökkenteni az erőforrás-kérést.
    • Ha erőforrást definiál instance type a modell üzembe helyezéséhez, kapcsolatba léphet az informatikai műveletekkel a példánytípus erőforrás-konfigurációjának módosításához. További részletekért tekintse meg a Kubernetes-példány típusának kezelését ismertető cikket.

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

Az Azure Machine Tanulás kapacitásának 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

A score.py megadottak az üzembe helyezés részeként való futtatásához az Azure létrehoz egy tárolót, amely tartalmazza az score.py összes szükséges erőforrást, és futtatja a pontozási szkriptet a tárolón.

Ha a tároló nem tudott elindulni, az azt jelenti, hogy a pontozás nem sikerült. Előfordulhat, hogy a tároló több erőforrást kér, mint amennyit instance_type támogat. Ha igen, fontolja meg az instance_type online üzembe helyezés frissítését.

A hiba pontos okának lekéréséhez futtassa a következőt:

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

HIBA: BadArgument

Az alábbi lista azokat az okokat sorolja fel, amelyek miatt ez a hiba a felügyelt online végpont vagy a Kubernetes online végpontjának használatakor jelentkezhet:

Az alábbi lista azokat az okokat sorolja fel, amelyek miatt ezt a hibát csak a Kubernetes online végpontjának használatakor tapasztalhatja:

Az előfizetés nem létezik

A megadott Azure-előfizetésnek meglévőnek kell lennie. Ez a hiba akkor fordul elő, ha nem találjuk a hivatkozott Azure-előfizetést. Ezt a hibát valószínűleg egy elírás okozza az előfizetés-azonosítóban. Ellenőrizze, hogy az előfizetés-azonosító helyesen van-e begépelve, és hogy jelenleg aktív-e.

Az Azure-előfizetésekkel kapcsolatos további információkért tekintse meg az előfeltételek szakaszt.

Engedélyezési hiba

Miután kiépítette a számítási erőforrást (üzembe helyezés létrehozása közben), az Azure megpróbálja lekérni a felhasználói tároló lemezképét az Azure Container Registry (ACR) munkaterületről. Megpróbálja csatlakoztatni 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.

Ezen műveletek végrehajtásához 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 a rendszer hozzárendelt identitással hozta 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.

  • Ha a társított végpontot felhasználó által hozzárendelt identitással hozta létre, a felhasználó felügyelt identitásának rendelkeznie kell a munkaterület tárfiókján tárolt blobadat-olvasó engedéllyel, a munkaterülethez tartozó Azure Container Registry (ACR) AcrPull-engedélyével. Győződjön meg arról, hogy a felhasználó által hozzárendelt identitás rendelkezik a megfelelő engedéllyel.

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, valamint az Azure szabályzatdefiníciós struktúracikkét, amely a sablonhibák elkerülésére szolgáló tippeket ismerteti.

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

Lehetséges, 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ő az ACR munkaterületen.

Ha például a rendszerkép az adattárban van testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest , ellenőrizze a következővel 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

Lehetséges, hogy a felhasználó modellje 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-e, mint az üzembe helyezés. Egy modell részleteinek megjelenítése egy munkaterületen:

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

Figyelmeztetés

A modell adatainak lekéréséhez meg kell adnia a verziót vagy a címkét.

Azt is ellenőrizheti, 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:

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

  • Ha a blob jelen van, a következő paranccsal szerezheti be a naplókat a tároló inicializálójátó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

Ez a hiba akkor fordul elő, ha kód nélküli üzembe helyezési megközelítéssel próbál üzembe helyezni egy MLflow-modellt a felügyelt online végpontok örökölt hálózatelkülönítési módszerével együtt. Ez a magánhálózati funkció nem használható MLFlow-modellformátummal együtt, ha az örökölt hálózatelkülönítési módszert használja. Ha kód nélküli üzembe helyezési megközelítéssel kell üzembe helyeznie egy MLflow-modellt, próbálkozzon a munkaterület által felügyelt virtuális hálózat használatával.

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, akkor alapértelmezett értékeket állítunk be, amikor a számítást egy Azure Machine Tanulás-munkaterülethez csatolja. A korlátozásokat az Azure Portalon vagy a az ml compute show parancs használatával ellenőrizheti.

azureml-fe nem áll készen

Az előtérbeli összetevő (azureml-fe), amely a bejövő következtetési kérelmeket az üzembe helyezett szolgáltatásokhoz irányítja, szükség szerint automatikusan skálázódik. A k8s-extension telepítése során települ.

Ennek az összetevőnek kifogástalannak kell lennie a fürtön, legalább egy kifogástalan replikának. Ez a hibaüzenet akkor jelenik meg, ha nem érhető el a Kubernetes online végpontjának és üzembe helyezési/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, és próbálja meg frissíteni a fürtre telepített k8s-bővítményt is.

HIBA: ResourceNotReady

A score.py megadottak az üzembe helyezés részeként való futtatásához az Azure létrehoz egy tárolót, amely tartalmazza az score.py összes szükséges erőforrást, és futtatja a pontozási szkriptet a tárolón. Ebben a forgatókönyvben az a hiba, hogy ez a tároló összeomlik futás közben, ami azt jelenti, hogy a pontozás nem történhet meg. Ez a hiba a következő esetekben fordul elő:

  • Hiba történt a következőben score.py: . Gyakori problémák diagnosztizálására használható get-logs :
    • Az importálni próbáló score.py csomagok nem szerepelnek 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ó indítása sikertelen volt. A probléma hibakereséséhez próbálja meg inkább 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 sokáig 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 nagyobb virtuálisgép-termékváltozattal a támogatott virtuálisgép-termékváltozatok között, ami felgyorsítja az inicializálást.
  • Hiba történt a tároló környezetében, például egy hiányzó függőség.
  • Ha a hiba jelenik TypeError: register() takes 3 positional arguments but 4 were given meg, ellenőrizze a Flask v2 és azureml-inference-server-httpa . További információkért lásd a HTTP-kiszolgáló következtetésére vonatkozó gyakori kérdéseket.

HIBA: ResourceNotFound

Az alábbi lista azokat az okokat sorolja fel, amelyek miatt a hiba csak felügyelt online végpont vagy Kubernetes online végpont használatakor jelentkezhet:

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ókra hivatkoztak, de nem található azon az elérési úton, amelyen meg lett adva. Ellenőrizze duplán azokat az erőforrásokat, amelyeket pontos elérési út vagy a nevük helyesírása adott meg.

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ó rendszerképet adott meg az üzembe helyezéshez. Az API-k jelenleg nem fogadják el 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 kövesse az alábbi lépéseket:

  1. Adja meg a magánregisztrációs adatbázis szerepkörét acrPull az online végpont rendszeridentitásának.
  2. A környezetdefinícióban adja meg a privát rendszerkép címét, valamint azt az utasítást, hogy ne módosítsa (buildelje) a rendszerképet.

Ha 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 diagnosztikai API használatát ismertető témakört.

HIBA: OperationCanceled

Az alábbi lista azokat az okokat sorolja fel, amelyek miatt ez a hiba a felügyelt online végpont vagy a Kubernetes online végpontjának használatakor jelentkezhet:

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 vannak végrehajtva. Ez a hiba akkor fordul elő, ha egy másik, magasabb prioritású művelet felülírta 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 van egy rövid várakozási időszakuk a beküldés után, amely során lekérnek egy zárolást, hogy ne ütközzünk versenyfeltételekbe. 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ítse, hogy megkapta a zárolást a folytatáshoz. Ez azt jelezheti, hogy a kezdeti kérés után túl hamar küldött el hasonló kérelmet.

Ha a műveletet több másodpercig, akár egy percig is újrapróbálkozza, előfordulhat, hogy a művelet megszakítás nélkül is végrehajtható.

HIBA: SecretsInjectionError

A titkos kulcsok 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 és/vagy kulcstartókból. Ez a hiba a következő esetekben fordul elő:

  • A végpontidentitás nem rendelkezik az Azure RBAC-engedéllyel a munkaterület-kapcsolatok és/vagy kulcstartók titkos kulcsainak beolvasására, annak ellenére, hogy a titkos kulcsokat az üzembehelyezési definíció hivatkozásként adta meg (környezeti változókra van leképezve). Ne feledje, hogy a szerepkör-hozzárendelés a módosítások érvénybe lépéséhez időbe telhet.
  • A titkos kulcshivatkozások formátuma érvénytelen, vagy a megadott titkos kulcsok nem léteznek a munkaterület-kapcsolatokban és/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

Bár mindent megteszünk, hogy stabil és megbízható szolgáltatást nyújtsunk, néha a dolgok nem a terv szerint mennek. Ha ezt a hibát kapja, az azt jelenti, hogy valami nem áll a mi oldalunkon, és ki kell javítanunk. Küldjön be egy ügyfélszolgálati jegyet az összes kapcsolódó információval, és meg tudjuk oldanunk a problémát.

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

Identitással és hitelesítéssel kapcsolatos hibák:

A crashloopbackofftal kapcsolatos hibák:

Pontozási szkripttel kapcsolatos hibák:

Egyebek:

HIBA: ACRSecretError

Az alábbi lista azokat az okokat sorolja fel, amelyek miatt ez a hiba a Kubernetes online üzemelő példányainak létrehozásakor/frissítésekor jelentkezhet:

  • A szerepkör-hozzárendelés még nem fejeződött be. Ebben az esetben várjon néhány másodpercet, és próbálkozzon újra később.
  • Az Azure ARC (Azure Arc Kubernetes-fürthöz) vagy az Azure Machine Tanulás bővítmény (AKS-hez) nincs megfelelően telepítve vagy konfigurálva. Próbálja meg ellenőrizni az Azure ARC vagy az Azure Machine Tanulás bővítmény konfigurációját és állapotát.
  • A Kubernetes-fürt nem megfelelő hálózati konfigurációval rendelkezik, ellenőrizze a proxyt, a hálózati házirendet vagy a tanúsítványt.
    • Ha privát AKS-fürtöt használ, privát végpontokat kell beállítania az ACR-hez, a tárfiókhoz és a munkaterülethez az AKS virtuális hálózaton.
  • Győződjön meg arról, hogy az Azure Machine Tanulás bővítményverziója nagyobb, mint az 1.1.25-ös verzió.

HIBA: TokenRefreshFailed

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

HIBA: GetAADTokenFailed

Ennek a hibának az az oka, hogy a Kubernetes-fürt azure AD-jogkivonat kérése meghiúsult vagy időtúllépés történt, ellenőrizze a hálózati akadálymentességet, majd próbálkozzon újra.

  • A kimenő proxy ellenőrzéséhez kövesse a szükséges hálózati forgalom konfigurálását, és győződjön meg arról, hogy a fürt csatlakozni tud a munkaterülethez.
  • A munkaterület végpontjának URL-címe a fürt online végpontjának CRD-jében található.

Ha a munkaterület egy privát munkaterület, amely letiltotta a nyilvános hálózati hozzáférést, a Kubernetes-fürtnek csak a privát kapcsolaton keresztül kell kommunikálnia ezzel a privát munkaterülettel.

  • Ellenőrizheti, hogy a munkaterület hozzáférése 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-e, nem fér hozzá a privát munkaterülethez.
  • További információ: Secure Azure Kubernetes Service következtetési környezet

HIBA: ACRAuthenticationChallengeFailed

Ennek a hibának az az oka, hogy a Kubernetes-fürt nem tudja elérni a munkaterület ACR szolgáltatását a hitelesítési feladat elvégzéséhez. Ellenőrizze a hálózatot, különösen az ACR 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, hogy a Kubernetes-fürt exchange ACR-jogkivonata meghiúsult, mert az Azure AD-jogkivonat még nincs engedélyezve. Mivel a szerepkör-hozzárendelés némi időt vesz igénybe, várjon egy kis időt, majd próbálkozzon újra.

A hiba oka lehet az is, hogy túl sok kérés érkezett az ACR szolgáltatáshoz abban az időben, átmeneti hibának kell lennie, amelyet később újra megpróbálhat.

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 a következőt teheti:

HIBA: ImagePullLoopBackOff

A Kubernetes online telepítések létrehozásakor/frissítésekor ennek a hibának az az oka, hogy 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.

Ebben az esetben ellenőrizheti a fürt hálózati szabályzatát és a munkaterület tárolóregisztrációs adatbázisát, ha a fürt le tudja-e húzni a lemezképet a tárolóregisztrációs adatbázisból.

HIBA: DeploymentCrashLoopBackOff

A Kubernetes online üzemelő példányainak létrehozásakor/frissítésekor ennek a hibának az oka az, hogy a felhasználói tároló inicializálása összeomlott. A hiba két lehetséges oka lehet:

  • A felhasználói szkript score.py szintaxishibával vagy importálási hibával rendelkezik, majd kivételeket emel ki az inicializálás során.
  • Vagy 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őrizheti az üzembehelyezési naplókat a felhasználói szkriptek kivételeinél. Ha a hiba továbbra is fennáll, próbálja kiterjeszteni az erőforrások/példánytípus memóriakorlátját.

HIBA: KubernetesCrashLoopBackOff

Az alábbi lista a Kubernetes online végpontjainak/üzemelő példányainak létrehozásakor/frissítésekor előfordulhat, hogy a hibába ütközik:

  • Egy vagy több pod elakadt a CrashLoopBackoff állapotában, ellenőrizheti, hogy létezik-e az üzembe helyezési napló, és ellenőrizheti, hogy vannak-e hibaüzenetek a naplóban.
  • Hiba score.py történt, és a tároló összeomlott a pontszámkód inicializálásakor, a KÖVETKEZŐ HIBAÜZENETet követheti : ResourceNotReady rész.
  • A pontozási folyamatnak több memóriára van szüksége, mert az üzembehelyezési konfigurációs korlát nem elegendő, megpróbálhatja frissíteni az üzembe helyezést egy nagyobb memóriakorláttal.

HIBA: NamespaceNotFound

A Kubernetes online végpontok létrehozásakor/frissítésekor ennek a hibának az az oka, hogy a kubernetes-számítás által használt névtér nem érhető el a fürtben.

A Kubernetes-számítást a munkaterület portálján ellenőrizheti, és ellenőrizheti a névteret a Kubernetes-fürtben. Ha a névtér nem érhető el, leválaszthatja az örökölt számítást, és újracsatlakoztathatja egy újat, megadva egy olyan névteret, amely már létezik a fürtben.

HIBA: UserScriptInitFailed

A Kubernetes online üzemelő példányainak létrehozásakor/frissítésekor ennek a hibának az az oka, hogy a feltöltött score.py fájl init függvénye kivételt okozott.

Az üzembehelyezési naplókban megtekintheti a kivételről szóló üzenetet, és kijavíthatja a kivételt.

HIBA: UserScriptImportError

A Kubernetes online üzemelő példányainak létrehozásakor/frissítésekor ennek a hibának az az oka, hogy a score.py feltöltött fájl nem elérhető csomagokat importált.

Az üzembehelyezési naplókban megtekintheti a kivételről szóló üzenetet, és kijavíthatja a kivételt.

HIBA: UserScriptFunctionNotFound

A Kubernetes online üzemelő példányainak létrehozásakor/frissítésekor ennek a hibának az az oka, hogy a score.py feltöltött fájl nem rendelkezik elnevezett vagy .run()init() Ellenőrizheti a kódot, és hozzáadhatja a függvényt.

HIBA: EndpointNotFound

Ennek a hibának az oka az, hogy a Kubernetes online üzemelő példányainak létrehozásakor/frissítésekor a rendszer nem találja az üzembe helyezés végponterőforrását a fürtben. Az üzembe helyezést egy létező végponton kell létrehoznia, vagy ezt a végpontot először a fürtben kell létrehoznia.

HIBA: EndpointAlreadyExists

A Kubernetes online végpont létrehozásakor ennek a hibának az az oka, hogy a létrehozási 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 ebben az esetben egy másik névvel kell létrehoznia a végpontot.

HIBA: ScoringFeUnhealthy

A Kubernetes online végpontjának/üzembe helyezésének létrehozásakor/frissítésekor ennek a hibának az az oka, hogy a fürtben futó rendszerszolgáltatás, az Azureml-fe nem található vagy nem megfelelő.

A probléma elhárításához újratelepítheti vagy frissítheti az Azure Machine Tanulás bővítményt a fürtben.

HIBA: ValidateScoringFailed

A Kubernetes online üzemelő példányainak létrehozásakor/frissítésekor ez a hiba azért fordulhat elő, mert a pontozási kérelem URL-ének érvényesítése nem sikerült a modell üzembe helyezése során.

Ebben az esetben először ellenőrizheti a végpont URL-címét, majd újra üzembe helyezheti az üzembe helyezést.

HIBA: InvalidDeploymentSpec

A Kubernetes online telepítések létrehozásakor/frissítésekor ennek a hibának az oka az, hogy az üzembehelyezési specifikáció érvénytelen.

Ebben az esetben ellenőrizheti a hibaüzenetet.

  • Győződjön meg arról, hogy az instance count érvényes.
  • Ha engedélyezte az automatikus skálázást, győződjön meg arról, hogy az minimum instance countmaximum instance count és mindkettő érvényes.

HIBA: PodUnschedulable

Az alábbi lista a Kubernetes online végpontjainak/üzemelő példányainak létrehozásakor/frissítésekor előfordulhat, hogy a hibába ütközik:

  • A fürt nem tudja ütemezni a podot a csomópontokra, mert nincs elegendő erőforrás a fürtben.
  • Nincs csomópontegyeztetés a csomópont affinitása/választója között.

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

  • Ellenőrizze a node selector használt definíciót instance type és node label a fürtcsomópontok konfigurálását.
  • Ellenőrizze instance type az AKS-fürt vagy az Arc-Kubernetes-fürt csomóponterőforrásának csomópont-termékváltozatának méretét.
    • Ha a fürt erőforrása nem megfelelő, csökkentheti a példánytípus erőforrásigényét, vagy használhat egy másik, kisebb erőforrást igénylő példánytípust.
  • Ha a fürtnek nincs több erőforrása az üzembe helyezés követelményének való megfeleléshez, törölje az erőforrások kiadásához szükséges néhány üzembe helyezést.

HIBA: PodOutOfMemory

Az online üzembe helyezés létrehozásakor/frissítésekor ennek a hibának az oka az, hogy az üzembe helyezéshez megadott memóriakorlát nem elegendő. A memóriakorlátot nagyobb értékre állíthatja be, vagy nagyobb példánytípust használhat a hiba elhárításához.

HIBA: InferencingClientCallFailed

Ennek a hibának az oka a Kubernetes online végpontjainak/üzemelő példányainak létrehozásakor/frissítésekor az, hogy a Kubernetes-fürt k8s-bővítménye nem csatlakoztatható.

Ebben az esetben leválaszthatja, majd újra csatolhatja a számítást.

Feljegyzés

Az újracsatlakoztatással kapcsolatos hibák elhárításához garantáljuk, hogy a korábban leválasztott számítással megegyező konfigurációval , például ugyanazzal a számítási névvel és névtérrel újracsatlakoztatjuk, ellenkező esetben más hibák léphetnek fel.

Ha még mindig nem működik, megkérheti 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.

Automatikus méretezési problémák

Ha problémákat tapasztal az automatikus skálázással kapcsolatban, tekintse meg az Azure automatikus skálázási hibáinak elhárítását.

Az online Kubernetes-végponthoz tartozik az Azure Machine Tanulás következtetési útválasztó, amely egy előtér-összetevő, amely a Kubernetes-fürt összes modelltelepítésének automatikus skálázását kezeli. További információt a Kubernetes-következtetési útválasztás automatikus skálázásával kapcsolatban talál.

Gyakori modellhasználati hibák

Az alábbi lista a végpontművelet invoke állapotából eredő gyakori modellhasználati hibákat tartalmazza.

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ése:

  • Használja a "Hálózati bájtok" metrikát az aktuális sávszélesség-használat megértéséhez. További információ: Felügyelt online végpontok figyelése.
  • Két válasz-pótkocsit adnak vissza, ha a sávszélesség-korlát érvényes:
    • ms-azureml-bandwidth-request-delay-ms: késleltetési idő ezredmásodpercben a kérelemfolyam átviteléhez.
    • ms-azureml-bandwidth-response-delay-ms: késleltetési idő ezredmásodpercben a válaszfolyam átvitelé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. Ezek a részletek azt ismertetik, hogy a végpontok meghívási és előrejelzési hibái hogyan képeznek le HTTP-állapotkódokat.

Felügyelt online végpontok gyakori hibakódjai

Az alábbi táblázat gyakori hibakódokat tartalmaz a felügyelt online végpontok REST-kérelmekkel való használatakor:

Állapotkód Ok kifejezés A kód visszaadása
200 OK A modell sikeresen végrehajtotta a késési korláton 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ókért tekintse meg a végponthitelesítés fogalmát és a végpont hitelesítésének módját.
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_msrequest_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 mintavételi beállítások módosítását, hogy hosszabb idő legyen a tároló élettartamának vagy készenlété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. Az Azure Machine Tanulás olyan rendszert vezetett be, amely lehetővé teszi, hogy egy adott pillanatban egyszerre legfeljebb 2 * max_concurrent_requests_per_instance * instance_count requests egyszerre lehessen feldolgozni a gördülékeny működést. A maximális értéket meghaladó egyéb kérelmeket a rendszer elutasítja. Ezeket a beállításokat a request_settings és scale_settings szakaszokban tekintheti át a modell üzembe helyezésének konfigurációját. Emellett a kérelem YAML-definíciójában leírtaknak megfelelően Gépház fontos gondoskodni arról, hogy a környezeti változó WORKER_COUNT megfelelően legyen átadva.

Ha automatikus skálázást használ, és ezt a hibát kapja, az azt jelenti, hogy a modell gyorsabban kap kéréseket, mint amennyit a rendszer fel tud skálázni. Ebben az esetben fontolja meg a kérések ismételt küldését exponenciális visszalépéssel , hogy a rendszer számára elegendő időt biztosítson a módosításhoz. 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. Ezek a lépések az automatikus skálázás beállításával együtt biztosítják, 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 Tanulás kiépített infrastruktúra meghibásodik.

Kubernetes online végpontok gyakori hibakódjai

Az alábbi táblázat gyakori hibakódokat tartalmaz a Kubernetes online végpontjainak REST-kérésekkel való használatakor:

Állapotkód Ok kifejezés A kód visszaadása
409 Ütközési hiba Ha egy művelet már folyamatban van, ugyanazon az online végponton lévő új műveletek 409 ütközési hibával válaszolnak. Ha például az online végpont létrehozása vagy frissítése folyamatban van, és ha új törlési műveletet indít el, az hibát jelez.
502 Kivételt jelzett vagy összeomlott a run() score.py fájl metódusában Ha hiba score.pytörtént, például egy importált csomag nem létezik a Conda környezetben, szintaxishiba vagy hiba a init() metódusban. A fájl hibakereséséhez kövesse az alábbi lépéseket.
503 Nagy kiugró kérések fogadása másodpercenként 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-ra szóló 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. Itt 503 állapotkódot akadályozhat meg.
504 A kérés túllépte 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 felgyorsíthatja a végpontot a szükségtelen hívások eltávolításához szükséges score.py módosításával. Ha ezek a műveletek nem oldják meg a problémát, az alábbi lépéseket követve hibakeresést végezhet a score.py fájlban. Előfordulhat, hogy a kód nem válaszoló állapotban vagy végtelen ciklusban van.
500 Belső kiszolgálóhiba Az Azure Machine Tanulás kiépített infrastruktúra meghibásodik.

503-as állapotkódok 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ót az Azure Machine Tanulás következtetési útválasztójában talál. A vertikális fel- és leskálázási döntések az aktuális tárolóreplikák kihasználtságán alapulnak.

Két dolog segíthet megelőzni az 503-at:

Tipp.

Ez a két megközelítés külön-külön vagy együttesen is használható.

  • Módosítsa azt a kihasználtsági szintet, amelyen az automatikus skálázás új replikákat hoz létre. A kihasználtsági célt alacsonyabb értékre állíthatja autoscale_target_utilization .

    Fontos

    Ez a módosítás nem eredményezi a replikák gyorsabb létrehozását. Ehelyett alacsonyabb kihasználtsági küszöbértéknél jönnek létre. Ahelyett, hogy megvárja a szolgáltatás 70%-os kihasználtságát, az érték 30%-ra történő módosítása replikákat hoz létre 30%-os kihasználtság esetén.

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

  • Módosítsa a replikák minimális számát. A minimális replikák számának növelése nagyobb készletet biztosít a bejövő kiugró értékek kezeléséhez.

    A példányok számának növeléséhez az alábbi kódokat követve kiszámíthatja 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ák által kezeltné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.

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

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

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)

CORS-szabályzat letiltva

Az online végpontok (v2) jelenleg nem támogatják natív módon az eltérő eredetű 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 jelenik 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.

Javasoljuk, hogy az Azure Functionst, Azure-alkalmazás Gatewayt vagy bármely szolgáltatást használjon köztes rétegként a CORS elővizsgálati kéréseinek kezeléséhez.

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

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

Az Azure Machine Tanulás munkaterület konfigurálható a v2 API-kat letiltó beállításhozv1_legacy_mode. 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.

Fontos

A letiltás előtt forduljon a hálózati biztonsági csapathoz v1_legacy_mode. Lehet, hogy a hálózati biztonsági csapat okkal engedélyezte.

További információ a letiltás v1_legacy_modemódjáról: Hálózatelkülönítés a v2-vel.

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

Az alábbi paranccsal listázhatja a munkaterülethez tartozó Azure Key Vault 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-dokumentumhoz:

{
    "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égpontok örökölt hálózatelkülönítési módszerét használja, amelyben az Azure Machine Tanulás létrehoz egy felügyelt virtuális hálózatot a végpontok alatt lévő minden egyes üzembe helyezéshez.

  1. Ellenőrizze, hogy a egress-public-network-access jelző le van-e tiltva az üzembe helyezéshez. Ha ez a jelző engedélyezve van, és a tárolóregisztrációs adatbázis láthatósága privát, akkor 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ületHez tartozó Azure Container Registry 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álaszdokumentumban ellenőrizze, hogy a status mező be van-e állítva Approved. Ha nincs jóváhagyva, 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 olyan virtuális hálózat-e, amely hozzáfér az Azure Machine Tanulás-munkaterülethez.

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

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

    A válasz tartalmaz egy címet. Ennek a címnek 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). Http-végpont esetén az IP-címet a végpont URI-ja tartalmazza, amelyet közvetlenül a Studio felhasználói felületén érhet el. A végpont IP-címének lekérésére további módszerek találhatók a Biztonságos Kubernetes online végpontján.

  3. Ha a parancs nem oldja fel a nslookup gazdagép nevét:

    Felügyelt online végpont esetén:

    1. Ellenőrizze, hogy létezik-e A rekord a virtuális hálózat privát DNS-zónájában.

      A rekordok ellenőrzéséhez használja a következő parancsot:

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

      Az eredményeknek tartalmazniuk kell egy, a következőhöz hasonló bejegyzést *.<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 használatával van beállítva: A munkaterület használata egyéni DNS-kiszolgálóval, a következő paranccsal ellenőrizheti, hogy a feloldás megfelelően működik-e az egyéni DNS-ből.

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

    Kubernetes online végpont esetén:

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

    2. Emellett ellenőrizheti, hogy az azureml-fe a várt módon működik-e, használja a következő parancsot:

      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-hez használja a

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

    Ha a curl HTTP-k meghiúsulnak (például időtúllépés), de a HTTP működik, ellenőrizze, hogy a tanúsítvány érvényes-e.

    Ha ez nem oldható fel 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

    Ha ez sikeres, akkor elháríthatja az egyéni DNS-alapú privát kapcsolat feltételes továbbítójának hibaelhárítását.

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

  1. Az alábbi paranccsal ellenőrizheti, hogy az üzembe helyezés sikeresen megtörtént-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 a state következő lesz 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

    Tipp.

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

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

  3. Ha a forgalom-hozzárendelések (vagy az üzembehelyezési fejléc) megfelelően vannak 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>

    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ó hibaelhárítása

Ebben a szakaszban alapvető hibaelhárítási tippeket nyújtunk az Azure Machine Tanulás következtetési HTTP-kiszolgálóhoz.

Alapszintű lépések

A hibaelhárítás alapvető lépései a következők:

  1. Verzióinformációk gyűjtése a Python-környezethez.
  2. Győződjön meg arról, hogy a környezeti fájlban megadott azureml-inference-server-http python csomagverzió megegyezik az indítási naplóban megjelenített AzureML-következtetési HTTP-kiszolgáló verziójával. Előfordulhat, hogy a Pip függőségfeloldója a telepített csomagok váratlan verzióihoz vezet.
  3. Ha a Flaskot (és annak függőségeit) adja meg a környezetében, távolítsa el őket. A függőségek közé tartoznak a Flaskkövetkezők: , Jinja2, itsdangerous, WerkzeugMarkupSafe, és click. A Flask függőségként szerepel a kiszolgálócsomagban, és a legjobb, ha engedélyezi a kiszolgáló telepítését. Így amikor a kiszolgáló támogatja a Flask új verzióit, automatikusan megkapja őket.

Kiszolgáló verziója

A kiszolgálócsomag azureml-inference-server-http közzé van téve a PyPI-ban. A változásnaplót és az összes korábbi verziót a PyPI oldalán találja. Frissítsen a legújabb verzióra, ha korábbi verziót használ.

  • 0.4.x: A betanítási képekben ≤ 20220601 és a azureml-defaults>=1.34,<=1.43. 0.4.13 az utolsó stabil verzió. Ha a kiszolgálót a verzió 0.4.11előtt használja, előfordulhat, hogy a Flask függőségi problémái nem tudnak nevet Markup importálni.jinja2 Ha lehetséges, javasoljuk, hogy frissítsen 0.4.13 a legújabb verzióra vagy 0.8.x (a legújabb verzióra).
  • 0.6.x: Az előre telepített verzió, amely a képek következtetésére ≤ 20220516. A legújabb stabil verzió a 0.6.1.
  • 0.7.x: Az első verzió, amely támogatja a Flask 2-t. A legújabb stabil verzió a 0.7.7.
  • 0.8.x: A naplóformátum megváltozott, és a Python 3.6 támogatása csökkent.

Csomagfüggőségek

A kiszolgáló azureml-inference-server-http legfontosabb csomagjai a következő csomagok:

  • Lombikot
  • opencensus-ext-azure
  • következtetési séma

Ha a Python-környezetben adta meg azureml-defaults , a azureml-inference-server-http csomag attól függ, és a rendszer automatikusan telepíti.

Tipp.

Ha Python SDK v1-et használ, és nem adja meg azureml-defaults explicit módon a Python-környezetben, az SDK hozzáadhatja Önnek a csomagot. Azonban zárolja az SDK azon verziójára, amelyen az SDK be van kapcsolva. Ha például az SDK-verzió, 1.38.0az hozzáadódik azureml-defaults==1.38.0 a környezet pipkövetelményeihez.

Gyakori kérdések

1. A kiszolgáló indításakor a következő hibát tapasztaltam:


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

A Flask 2 telepítve van a Python-környezetben, de olyan verziót azureml-inference-server-http futtat, amely nem támogatja a Flask 2-t. A Flask 2 támogatása a következőben azureml-inference-server-http>=0.7.0azureml-defaults>=1.44található:

  • Ha ezt a csomagot nem AzureML docker-rendszerképben használja, használja a legújabb verziót azureml-inference-server-http vagy azureml-defaults.

  • Ha ezt a csomagot Egy AzureML docker-lemezképpel használja, győződjön meg arról, hogy 2022 júliusában vagy azt követően létrehozott rendszerképet használ. A rendszerkép verziója elérhető a tárolónaplókban. A következőhöz hasonló naplót kell találnia:

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

    A rendszerkép buildelési dátuma a "Materialization Build" után jelenik meg, amely a fenti példában 202207082022. július 8. Ez a kép kompatibilis a Flask 2-vel. Ha nem jelenik meg ilyen szalagcím a tárolónaplóban, a rendszerkép elavult, ezért frissítenie kell. Ha CUDA-lemezképet használ, és nem talál újabb rendszerképet, ellenőrizze, hogy a rendszerkép elavult-e az AzureML-Containersben. Ha így van, akkor képesnek kell lennie a cserére.

  • Ha a kiszolgálót online végponttal használja, a naplókat az Azure Machine Tanulás Studio online végpontlapjának "Üzembe helyezési naplók" területén 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, akkor alapértelmezés szerint a helyi SDK-eszközkészletnek megfelelő verziót openmpi4.1.0-ubuntu20.04 kell használnia, amely lehet, hogy nem a rendszerkép legújabb verziója. Az SDK 1.43 alapértelmezés szerint openmpi4.1.0-ubuntu20.04:20220616nem kompatibilis. Győződjön meg arról, hogy a legújabb SDK-t használja az üzembe helyezéshez.

  • Ha valamilyen okból nem tudja frissíteni a lemezképet, ideiglenesen elkerülheti a problémát a rögzítéssel azureml-defaults==1.43 , vagy azureml-inference-server-http~=0.4.13, amely a régebbi verziókiszolgálót Flask 1.0.xtelepíti.

2. A következő üzenethez hasonlóan egy modulban vagy modulban, MarkupSafejinja2vagy click indításkor találkoztam ImportErrorModuleNotFoundError:opencensus

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

A kiszolgáló régebbi verziói (<= 0.4.10) nem rögzítette a Flask függőségét a kompatibilis verziókhoz. Ezt a problémát a kiszolgáló legújabb verziójában kijavítottuk.

Következő lépések