Sdílet prostřednictvím

Řešení potíží s nasazením a vyhodnocováním online koncového bodu

  • Článek

PLATÍ PRO:Rozšíření Azure CLI ml v2 (aktuální)Python SDK azure-ai-ml v2 (aktuální)

Tento článek popisuje, jak řešit a řešit běžné problémy s nasazením a vyhodnocováním online koncového bodu služby Azure Machine Learning.

Struktura dokumentu odráží způsob, jakým byste měli řešit potíže:

  1. Použijte místní nasazení a před nasazením do cloudu proveďte místní otestování a odladění vašich modelů.
  2. Použijte protokoly kontejnerů, které vám pomohou odladit případné potíže.
  3. Seznamte se s běžnými chybami nasazení, ke kterým může dojít, a zjistěte, jak je opravit.

Část stavových kódů HTTP vysvětluje, jak se chyby vyvolání a predikce mapují na stavové kódy HTTP při vyhodnocování koncových bodů pomocí požadavků REST.

Požadavky

Trasování požadavků

Existují dvě podporovaná hlavička trasování:

  • x-request-id je vyhrazen pro trasování serverů. Azure Machine Learning tuto hlavičku přepíše, aby se zajistilo, že se jedná o platný identifikátor GUID. Když vytvoříte lístek podpory pro neúspěšnou žádost, připojte ID neúspěšné žádosti, abyste urychlili šetření. Případně zadejte název oblasti a název koncového bodu.

  • x-ms-client-request-id je k dispozici pro scénáře trasování klientů. Toto záhlaví přijímá pouze alfanumerické znaky, pomlčky a podtržítka a zkracuje se na maximálně 40 znaků.

Místní nasazení

Místní nasazení znamená nasazení modelu do místního prostředí Dockeru. Místní nasazení podporuje vytváření, aktualizaci a odstraňování místního koncového bodu a umožňuje vyvolat a získat protokoly z koncového bodu. Místní nasazení je užitečné pro testování a ladění před nasazením do cloudu.

Tip

K místnímu ladění hodnoticího skriptu můžete použít balíček Pythonu pro odvozování serveru HTTP služby Azure Machine Learning. Ladění pomocí serveru odvozování vám pomůže ladit bodovací skript před nasazením do místních koncových bodů, abyste mohli ladit bez ovlivnění konfigurací kontejneru nasazení.

Nasazení můžete provést místně pomocí Azure CLI nebo sady Python SDK. studio Azure Machine Learning nepodporuje místní nasazení ani místní koncové body.

Pokud chcete použít místní nasazení, přidejte --local do příslušného příkazu.

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

Během místního nasazení dochází k následujícím krokům:

  1. Docker buď sestaví novou image kontejneru, nebo stáhne existující image z místní mezipaměti Dockeru. Docker používá existující image, pokud se shoduje s prostředím v souboru specifikace.
  2. Docker spustí nový kontejner s připojenými místními artefakty, jako jsou soubory modelu a kódu.

Další informace najdete v tématu Místní nasazení a ladění pomocí místního koncového bodu.

Tip

Visual Studio Code můžete použít k místnímu testování a ladění koncových bodů. Další informace naleznete v tématu Ladění online koncových bodů místně v editoru Visual Studio Code.

Získání protokolů kontejneru

Nemůžete získat přímý přístup k virtuálnímu počítači, na kterém se model nasazuje, ale můžete získat protokoly z některých kontejnerů spuštěných na virtuálním počítači. Množství informací, které získáte, závisí na stavu zřizování nasazení. Pokud je zadaný kontejner spuštěný a spuštěný, zobrazí se jeho výstup konzoly. V opačném případě se zobrazí zpráva, která se má později zkusit znovu.

Protokoly můžete získat z následujících typů kontejnerů:

  • Protokol konzoly serveru pro odvozování obsahuje výstup funkcí tisku a protokolování z bodovacího skriptu score.py kódu.
  • Protokoly inicializátoru úložiště obsahují informace o tom, jestli se data kódu a modelu úspěšně stáhla do kontejneru. Kontejner se spustí před spuštěním kontejneru serveru pro odvození.

U online koncových bodů Kubernetes můžou správci přistupovat přímo ke clusteru, do kterého model nasazujete, a kontrolovat protokoly v Kubernetes. Příklad:

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

Poznámka:

Pokud používáte protokolování Pythonu, nezapomeňte použít správnou úroveň protokolování, například INFO, aby se zprávy publikovaly do protokolů.

Zobrazení výstupu protokolu z kontejnerů

Pokud chcete zobrazit výstup protokolu z kontejneru, použijte následující příkaz:

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

Nebo

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

Ve výchozím nastavení se protokoly načítají ze serveru odvozování. Protokoly můžete získat z kontejneru inicializátoru úložiště předáním –-container storage-initializer.

Pokud jste tyto parametry ještě nenastavili, az configurepřidejte --resource-group je do --workspace-name příkazů. Pokud chcete zobrazit informace o tom, jak tyto parametry nastavit, nebo pokud máte aktuálně nastavené hodnoty, spusťte následující příkaz:

az ml online-deployment get-logs -h

Pokud chcete zobrazit další informace, přidejte --help nebo --debug do příkazů.

Běžné chyby nasazení

Stav operace nasazení může hlásit následující běžné chyby nasazení:

Pokud vytváříte nebo aktualizujete online nasazení Kubernetes, podívejte se také na běžné chyby specifické pro nasazení Kubernetes.

CHYBA: ImageBuildFailure

Tato chyba se vrátí při vytváření prostředí image Dockeru. Další informace o selhání najdete v protokolu sestavení. Protokol sestavení se nachází ve výchozím úložišti pro váš pracovní prostor Azure Machine Learning.

Přesné umístění může být vráceno jako součást chyby, například "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

Následující části popisují běžné scénáře selhání sestavení image:

Selhání autorizace ve službě Azure Container Registry

Chybová zpráva se zobrazí "container registry authorization failure" , když nemůžete získat přístup k registru kontejneru s aktuálními přihlašovacími údaji. Desynchronizace klíčů prostředků pracovního prostoru může způsobit tuto chybu a automatická synchronizace nějakou dobu trvá. Synchronizaci klíčů ale můžete ručně volat pomocí příkazu az ml workspace sync-keys, což může vyřešit selhání autorizace.

Registry kontejnerů, které jsou za virtuální sítí, se můžou také setkat s touto chybou, pokud jsou správně nastavené. Ověřte, že je virtuální síť správně nastavená.

Výpočetní prostředky sestavení image se nenastavují v privátním pracovním prostoru s virtuální sítí

Pokud se chybová zpráva zmíní "failed to communicate with the workspace's container registry"a používáte virtuální síť a registr kontejneru pracovního prostoru je privátní a nakonfigurovaný s privátním koncovým bodem, musíte službě Container Registry povolit vytváření imagí ve virtuální síti.

Časový limit sestavení image

Časové limity sestavení image jsou často způsobené příliš velkými imagemi, aby bylo možné dokončit sestavování v rámci časového rámce vytváření nasazení. Zkontrolujte protokoly sestavení image v umístění, které tato chyba určuje. Protokoly jsou v okamžiku, kdy vypršel časový limit sestavení image.

Pokud chcete tento problém vyřešit, sestavte image samostatně, aby se image během vytváření nasazení načítá jenom. Zkontrolujte také výchozí nastavení sondy, pokud máte vypršení časových limitů nástroje ImageBuild.

Selhání sestavení obecné image

Další informace o selhání najdete v protokolu sestavení. Pokud se v protokolu sestavení nenajde žádná zjevná chyba a poslední řádek je Installing pip dependencies: ...working..., může chyba způsobovat závislost. Tento problém můžete vyřešit připnutím závislostí verzí v souboru conda.

Zkuste modely otestovat a ladit místně před nasazením do cloudu.

CHYBA: OutOfQuota

Při používání služeb Azure může dojít k vyčerpání kvóty následujících prostředků:

Pouze u online koncových bodů Kubernetes může dojít k vyčerpání kvóty prostředku Kubernetes.

Kvóta procesoru

K nasazení modelu potřebujete dostatečnou kvótu výpočetních prostředků. Kvóta procesoru definuje, kolik virtuálních jader je dostupných na předplatné, na pracovní prostor, na skladovou položku a v jednotlivých oblastech. Každé nasazení odečte dostupnou kvótu a přidá ji zpět po odstranění na základě typu skladové položky.

Můžete zkontrolovat, jestli neexistují nepoužívané nasazení, která můžete odstranit, nebo můžete odeslat žádost o navýšení kvóty.

Kvóta clusteru

K OutOfQuota chybě dochází v případě, že nemáte dostatečnou kvótu výpočetního clusteru služby Azure Machine Learning. Kvóta definuje celkový počet clusterů na předplatné, které můžete použít současně k nasazení uzlů PROCESORu nebo GPU v cloudu Azure.

Kvóta disků

K OutOfQuota chybě dochází, když je velikost modelu větší než dostupné místo na disku a model nejde stáhnout. Zkuste použít skladovou položku s větším místem na disku nebo zmenšit velikost image a modelu.

Kvóta paměti

K OutOfQuota chybě dochází, když je využití paměti modelu větší než dostupná paměť. Zkuste skladovou položku s větší pamětí.

Kvóta přiřazení rolí

Když vytvoříte spravovaný online koncový bod, vyžaduje se přiřazení role pro spravovanou identitu pro přístup k prostředkům pracovního prostoru. Pokud dosáhnete limitu přiřazení role, zkuste odstranit některá nepoužitá přiřazení rolí v tomto předplatném. Všechna přiřazení rolí můžete zkontrolovat tak , že na webu Azure Portal vyberete Řízení přístupu pro vaše předplatné Azure.

Kvóta koncových bodů

Zkuste odstranit některé nepoužívané koncové body v tomto předplatném. Pokud se aktivně používají všechny vaše koncové body, zkuste požádat o navýšení limitu koncového bodu. Další informace o limitu koncového bodu najdete v tématu Kvóta koncových bodů pomocí online koncových bodů služby Azure Machine Learning a dávkových koncových bodů.

Kvóta Kubernetes

K OutOfQuota chybě dochází v případě, že požadovaný procesor nebo paměť nelze poskytnout kvůli neplánovatelným uzlům pro toto nasazení. Uzly můžou být například pod cordonované nebo jinak nedostupné.

Chybová zpráva obvykle značí nedostatečnost prostředků v clusteru, například OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Tato zpráva znamená, že v clusteru je příliš mnoho podů a není dostatek prostředků k nasazení nového modelu na základě vaší žádosti.

Pokud chcete tento problém vyřešit, zkuste následující omezení rizik:

  • Operátoři IT, kteří udržují cluster Kubernetes, se můžou pokusit přidat další uzly nebo vymazat některé nepoužívané pody v clusteru a uvolnit některé prostředky.

  • Technici strojového učení, kteří nasazují modely, se mohou pokusit snížit požadavek na prostředky nasazení.

    • Pokud přímo definujete požadavek na prostředek v konfiguraci nasazení prostřednictvím oddílu prostředků, zkuste snížit požadavek na prostředek.
    • Pokud používáte instance_type k definování prostředku pro nasazení modelu, obraťte se na it operátora a upravte konfiguraci prostředku typu instance. Další informace najdete v tématu Vytváření a správa typů instancí.

Kapacita virtuálního počítače na úrovni celé oblasti

Kvůli nedostatku kapacity služby Azure Machine Learning v oblasti se službě nepodařilo zřídit zadanou velikost virtuálního počítače. Zkuste to znovu později nebo zkuste nasazení do jiné oblasti.

Jiná kvóta

Pokud chcete spustit soubor score.py , který zadáte jako součást nasazení, Azure vytvoří kontejner, který obsahuje všechny prostředky, které score.py potřebuje. Azure Machine Learning pak v tomto kontejneru spustí bodovací skript. Pokud se váš kontejner nedá spustit, bodování se nestane. Kontejner může vyžadovat více prostředků, než instance_type může podporovat. Zvažte aktualizaci instance_type online nasazení.

Pokud chcete získat přesný důvod chyby, proveďte následující akci.

Spusťte následující příkaz:

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

CHYBA: BadArgument

K této chybě může dojít při použití spravovaných online koncových bodů nebo online koncových bodů Kubernetes z následujících důvodů:

Tato chyba se může zobrazit také při používání online koncových bodů Kubernetes, a to z následujících důvodů:

Předplatné neexistuje.

Odkazované předplatné Azure musí být existující a aktivní. K této chybě dochází, když Azure nemůže najít ID předplatného, které jste zadali. Příčinou chyby může být překlep v ID předplatného. Pečlivě zkontrolujte, jestli se ID předplatného správně zadalo a je aktuálně aktivní.

Chyba autorizace

Po zřízení výpočetního prostředku při vytváření nasazení azure stáhne image kontejneru uživatele z registru kontejneru pracovního prostoru a připojí artefakty uživatelského modelu a kódu do kontejneru uživatele z účtu úložiště pracovního prostoru. Azure používá spravované identity pro přístup k účtu úložiště a registru kontejneru.

Pokud vytvoříte přidružený koncový bod s identitou přiřazenou uživatelem, musí mít spravovaná identita uživatele oprávnění čtenáře dat objektů blob úložiště k účtu úložiště pracovního prostoru a oprávnění AcrPull v registru kontejneru pracovního prostoru. Ujistěte se, že vaše identita přiřazená uživatelem má správná oprávnění.

Pokud vytvoříte přidružený koncový bod s identitou přiřazenou systémem, automaticky se udělí oprávnění řízení přístupu na základě role (RBAC) Azure a žádná další oprávnění se nepotřebují. Další informace najdete v tématu Chyba autorizace registru kontejneru.

Neplatná specifikace funkce šablony

K této chybě dochází, když byla nesprávně zadána funkce šablony. Opravte zásadu nebo zrušte odblokování přiřazení zásad. Chybová zpráva může obsahovat název přiřazení zásady a definici zásady, které vám pomůžou tuto chybu ladit. Tipy , jak se vyhnout chybám šablon, najdete v tématu Struktura definic zásad Azure.

Nejde stáhnout image kontejneru uživatele

Kontejner uživatele pravděpodobně nebyl nalezen. Další podrobnosti najdete v protokolech kontejneru.

Ujistěte se, že je image kontejneru dostupná v registru kontejneru pracovního prostoru. Pokud je testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latestimage například , můžete pomocí následujícího příkazu zkontrolovat úložiště:

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

Nejde stáhnout uživatelský model

Uživatelský model pravděpodobně nebyl nalezen. Další podrobnosti najdete v protokolech kontejneru. Ujistěte se, že jste model zaregistrovali do stejného pracovního prostoru jako nasazení.

Pokud chcete zobrazit podrobnosti modelu v pracovním prostoru, proveďte následující akci. Abyste získali informace o modelu, musíte zadat buď verzi, nebo popisek.

Spusťte následující příkaz:

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

Zkontrolujte také, jestli jsou objekty blob v účtu úložiště pracovního prostoru. Pokud je https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pklobjekt blob například , můžete pomocí následujícího příkazu zkontrolovat, jestli objekt blob existuje:

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

Pokud je objekt blob k dispozici, můžete pomocí následujícího příkazu získat protokoly z inicializátoru úložiště:

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

Formát modelu MLflow s privátní sítí není podporován.

Pokud používáte starší metodu izolace sítě pro spravované online koncové body, nemůžete použít funkci privátní sítě s formátem modelu MLflow. Pokud potřebujete nasadit model MLflow s přístupem bez kódu, zkuste použít virtuální síť spravovanou pracovním prostorem.

Požadavky na prostředky větší než limity

Požadavky na prostředky musí být menší nebo rovny limitům. Pokud nenastavíte limity, Azure Machine Learning při připojení výpočetních prostředků k pracovnímu prostoru nastaví výchozí hodnoty. Limity můžete zkontrolovat na webu Azure Portal nebo pomocí az ml compute show příkazu.

Azureml-fe není připravený

Front-endová azureml-fe komponenta, která směruje příchozí požadavky na odvozovací požadavky na nasazené služby, se nainstaluje během instalace rozšíření k8s a podle potřeby se automaticky škáluje. Tato komponenta by měla mít v clusteru alespoň jednu repliku, která je v pořádku.

Tato chyba se zobrazí, pokud komponenta není dostupná při aktivaci online koncového bodu Kubernetes nebo vytvoření nasazení nebo žádosti o aktualizaci. Pokud chcete tento problém vyřešit, zkontrolujte stav podu a protokoly. Můžete se také pokusit aktualizovat rozšíření k8s nainstalované v clusteru.

CHYBA: ResourceNotReady

Pokud chcete spustit soubor score.py , který zadáte jako součást nasazení, Azure vytvoří kontejner, který obsahuje všechny prostředky, které score.py potřebuje, a spustí v daném kontejneru bodovací skript. Chyba v tomto scénáři spočívá v tom, že se tento kontejner při spuštění chybově ukončí, takže bodování se nestane. K této chybě může dojít za jedné z následujících podmínek:

  • V score.py došlo k chybě. Slouží get-logs k diagnostice běžných problémů, například:

    • Balíček, který se score.py pokusí importovat, který není součástí prostředí conda
    • Chyba syntaxe
    • Selhání v init() metodě

    Pokud get-logs nevytvářejí žádné protokoly, obvykle to znamená, že se kontejner nepodařilo spustit. Pokud chcete tento problém ladit, zkuste ho nasadit místně.

  • Testy připravenosti nebo aktivity nejsou správně nastavené.

  • Inicializace kontejneru trvá příliš dlouho, takže test připravenosti nebo aktivity selže nad prahovou hodnotu selhání. V tomto případě upravte nastavení sondy tak, aby se kontejner inicializoval delší dobu. Nebo zkuste větší podporovanou skladovou položku virtuálního počítače, která inicializaci zrychluje.

  • V nastavení prostředí kontejneru došlo k chybě, například chybějící závislost.

    Pokud se zobrazí TypeError: register() takes 3 positional arguments but 4 were given chyba, zkontrolujte závislost mezi flaskem v2 a azureml-inference-server-http. Další informace najdete v tématu Řešení potíží se serverem HTTP.

CHYBA: ResourceNotFound

K této chybě může dojít při použití spravovaného online koncového bodu nebo online koncového bodu Kubernetes z následujících důvodů:

Resource Manager nemůže najít prostředek

K této chybě dochází, když Azure Resource Manager nemůže najít požadovaný prostředek. Tato chyba se může zobrazit například v případě, že se v zadané cestě nepodařilo najít účet úložiště. Pečlivě zkontrolujte cestu nebo specifikace názvu pro přesnost a pravopis. Další informace naleznete v tématu Řešení chyb pro prostředek nenalezena.

Chyba autorizace registru kontejneru

K této chybě dochází v případě, že je pro nasazení zadána image patřící do privátního nebo jinak nepřístupného registru kontejneru. Rozhraní API služby Azure Machine Learning nemůžou přijímat přihlašovací údaje privátního registru.

Pokud chcete tuto chybu zmírnit, ujistěte se, že registr kontejneru není soukromý, nebo proveďte následující kroky:

  1. Udělte roli acrPull vašeho privátního registru systémové identitě vašeho online koncového bodu.
  2. V definici prostředí zadejte adresu vaší privátní image a dejte pokyn, aby image neupravil ani nevystavil.

Pokud toto omezení rizik proběhne úspěšně, image nevyžaduje sestavení a konečná adresa obrázku je daná adresa obrázku. V době nasazení načte identita systému vašeho online koncového bodu image z privátního registru.

Další diagnostické informace najdete v tématu Použití diagnostiky pracovního prostoru.

CHYBA: WorkspaceManagedNetworkNotReady

K této chybě dochází v případě, že se pokusíte vytvořit online nasazení, které umožňuje virtuální síť spravovanou pracovním prostorem, ale spravovaná virtuální síť ještě není zřízená. Před vytvořením online nasazení zřiďte virtuální síť spravovanou pracovním prostorem.

Pokud chcete ručně zřídit spravovanou virtuální síť pracovního prostoru, postupujte podle pokynů v části Ruční zřízení spravované virtuální sítě. Pak můžete začít vytvářet online nasazení. Další informace najdete v tématu Izolace sítě se spravovaným online koncovým bodem a zabezpečení spravovaných online koncových bodů pomocí izolace sítě.

CHYBA: OperationCanceled

K této chybě může dojít při použití spravovaného online koncového bodu nebo online koncového bodu Kubernetes z následujících důvodů:

Operace zrušená jinou operací s vyšší prioritou

Operace Azure mají určitou úroveň priority a provádějí se od nejvyšších po nejnižší. K této chybě dochází v případě, že vaše operace přepíše jinou operaci s vyšší prioritou. Opakování operace může umožnit provádění bez zrušení.

Operace se zrušila a čeká se na potvrzení zámku.

Operace Azure mají po odeslání krátkou čekací dobu, během které načtou zámek, aby se zajistilo, že nenarazí na podmínky časování. K této chybě dochází, když je operace, kterou jste odeslali, stejná jako jiná operace. Druhá operace aktuálně čeká na potvrzení, že obdržela zámek před tím, než bude pokračovat.

Možná jste po počátečním požadavku odeslali podobný požadavek příliš brzy. Opakování operace po čekání až minutu může umožnit, aby se operace prováděla bez zrušení.

CHYBA: SecretsInjectionError

Načítání tajných kódů a injektáž během vytváření online nasazení používá identitu přidruženou k online koncovému bodu k načtení tajných kódů z připojení pracovního prostoru nebo trezorů klíčů. K této chybě dochází z jednoho z následujících důvodů:

  • Identita koncového bodu nemá oprávnění Azure RBAC ke čtení tajných kódů z připojení pracovního prostoru nebo trezorů klíčů, i když definice nasazení zadala tajné kódy jako odkazy namapované na proměnné prostředí. Přiřazení role může nějakou dobu trvat, než se změny projeví.

  • Formát odkazů na tajné kódy je neplatný nebo zadané tajné kódy neexistují v připojeních pracovního prostoru nebo trezorech klíčů.

Další informace najdete v tématu Injektáž tajných kódů v online koncových bodech (Preview) a Přístup k tajným kódům z online nasazení pomocí injektáže tajných kódů (Preview).

CHYBA: InternalServerError

Tato chyba znamená, že ve službě Azure Machine Learning je něco špatně, co je potřeba opravit. Odešlete lístek zákaznické podpory se všemi informacemi potřebnými k vyřešení problému.

Běžné chyby specifické pro nasazení Kubernetes

Chyby identit a ověřování:

Chyby crashloopbackoff:

Chyby hodnoticího skriptu:

Jiné chyby:

CHYBA: ACRSecretError

Při vytváření nebo aktualizaci online nasazení Kubernetes se může zobrazit tato chyba z jednoho z následujících důvodů:

  • Přiřazení role není dokončeno. Počkejte několik sekund a zkuste to znovu.

  • Cluster Kubernetes s podporou Služby Azure Arc nebo rozšíření AKS Azure Machine Learning není správně nainstalovaný nebo nakonfigurovaný. Zkontrolujte konfiguraci a stav rozšíření Azure Machine Learning s podporou Služby Azure Arc.

  • Cluster Kubernetes má nesprávnou konfiguraci sítě. Zkontrolujte proxy server, zásady sítě nebo certifikát.

  • Váš privátní cluster AKS nemá správné koncové body. Nezapomeňte nastavit privátní koncové body pro Container Registry, účet úložiště a pracovní prostor ve virtuální síti AKS.

  • Vaše verze rozšíření Azure Machine Learning je v1.1.25 nebo nižší. Ujistěte se, že je vaše verze rozšíření větší než verze 1.1.25.

CHYBA: TokenRefreshFailed

K této chybě dochází, protože identita clusteru Kubernetes není správně nastavená, takže rozšíření nemůže získat hlavní přihlašovací údaje z Azure. Přeinstalujte rozšíření Azure Machine Learning a zkuste to znovu.

CHYBA: GetAADTokenFailed

K této chybě dochází, protože došlo k selhání nebo vypršení časového limitu požadavku clusteru Kubernetes na token Microsoft Entra ID. Zkontrolujte síťový přístup a zkuste to znovu.

  • Podle pokynů v části Použití výpočetních prostředků Kubernetes zkontrolujte odchozí proxy server a ujistěte se, že se cluster může připojit k pracovnímu prostoru. Adresu URL koncového bodu pracovního prostoru najdete v online definici vlastních prostředků koncového bodu online v clusteru.

  • Zkontrolujte, jestli pracovní prostor umožňuje veřejný přístup. Bez ohledu na to, jestli je samotný cluster AKS veřejný nebo soukromý, může cluster Kubernetes komunikovat s tímto pracovním prostorem pouze prostřednictvím privátního propojení. Další informace najdete v tématu Co je zabezpečené prostředí pro odvozování AKS.

CHYBA: ACRAuthenticationChallengeFailed

K této chybě dochází, protože cluster Kubernetes se nemůže spojit se službou Container Registry pracovního prostoru a provést výzvu ověřování. Zkontrolujte síť, zejména přístup k veřejné síti služby Container Registry, a zkuste to znovu. Při kontrole sítě můžete postupovat podle kroků pro řešení potíží v getAADTokenFailed .

CHYBA: ACRTokenExchangeFailed

K této chybě dochází, protože token ID Microsoft Entra ještě není autorizovaný, takže cluster Kubernetes exchange Container Registry token selže. Přiřazení role nějakou dobu trvá, proto chvíli počkejte a zkuste to znovu.

Příčinou tohoto selhání může být také příliš mnoho souběžných požadavků na službu Container Registry. Tato chyba by měla být přechodná a můžete to zkusit později.

CHYBA: KubernetesUnaccessible

Při nasazení modelu Kubernetes se může zobrazit následující chyba:

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

Pokud chcete tuto chybu zmírnit, můžete certifikát AKS pro cluster otočit. Nový certifikát by se měl aktualizovat po 5 hodinách, takže můžete počkat na 5 hodin a znovu ho nasadit. Další informace najdete v tématu Obměny certifikátů ve službě Azure Kubernetes Service (AKS).

CHYBA: ImagePullLoopBackOff

Tato chyba se může zobrazit při vytváření nebo aktualizaci online nasazení Kubernetes, protože nemůžete stáhnout image z registru kontejneru, což vede k selhání načítání imagí. Zkontrolujte zásady sítě clusteru a registr kontejneru pracovního prostoru a zjistěte, jestli cluster dokáže načíst image z registru kontejneru.

CHYBA: DeploymentCrashLoopBackOff

Tato chyba se může zobrazit při vytváření nebo aktualizaci online nasazení Kubernetes, protože při inicializaci došlo k chybovému ukončení kontejneru uživatele. K této chybě existují dva možné důvody:

  • Uživatelský skript score.py má chybu syntaxe nebo chybu importu, která vyvolává výjimky při inicializaci.
  • Pod nasazení potřebuje více paměti, než je jeho limit.

Pokud chcete tuto chybu zmírnit, nejprve zkontrolujte, jestli protokoly nasazení neobsahují výjimky ve skriptech uživatelů. Pokud chyba přetrvává, zkuste rozšířit limit paměti typu prostředku nebo instance.

CHYBA: KubernetesCrashLoopBackOff

K této chybě může dojít při vytváření nebo aktualizaci online koncových bodů nebo nasazení Kubernetes z jednoho z následujících důvodů:

  • Jeden nebo více podů se zasekne ve stavu CrashLoopBackoff. Zkontrolujte, jestli protokol nasazení existuje, a v protokolu jsou chybové zprávy.
  • Při inicializaci kódu skóre došlo k chybě v score.py a kontejneru došlo k chybě. Postupujte podle pokynů v části CHYBA: ResourceNotReady.
  • Proces vyhodnocování potřebuje více paměti, než je limit konfigurace nasazení. Můžete zkusit aktualizovat nasazení s větším limitem paměti.

CHYBA: NamespaceNotFound

K této chybě může dojít při vytváření nebo aktualizaci online koncových bodů Kubernetes, protože použitý obor názvů výpočetních prostředků Kubernetes není ve vašem clusteru dostupný. Zkontrolujte výpočetní prostředky Kubernetes na portálu pracovního prostoru a zkontrolujte obor názvů v clusteru Kubernetes. Pokud obor názvů není dostupný, odpojte starší výpočetní prostředky a znovu se připojte, abyste vytvořili nový, a zadejte obor názvů, který už v clusteru existuje.

CHYBA: UserScriptInitFailed

K této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, protože init funkce v nahraném souboru score.py vyvolala výjimku. Podrobné informace o výjimce najdete v protokolech nasazení a opravte výjimku.

CHYBA: UserScriptImportError

Tato chyba se může zobrazit při vytváření nebo aktualizaci online nasazení Kubernetes, protože score.py soubor, který jste nahráli, importuje nedostupné balíčky. Podrobné informace o výjimce najdete v protokolech nasazení a opravte výjimku.

CHYBA: UserScriptFunctionNotFound

Tato chyba se může zobrazit při vytváření nebo aktualizaci online nasazení Kubernetes, protože score.py soubor, který jste nahráli, nemá funkci s názvem init() nebo run(). Zkontrolujte kód a přidejte funkci.

CHYBA: EndpointNotFound

Tato chyba se může zobrazit při vytváření nebo aktualizaci online nasazení Kubernetes, protože systém nemůže najít prostředek koncového bodu pro nasazení v clusteru. Vytvořte nasazení v existujícím koncovém bodu nebo nejprve vytvořte koncový bod v clusteru.

CHYBA: EndpointAlreadyExists

Tato chyba se může zobrazit při vytváření online koncového bodu Kubernetes, protože koncový bod už ve vašem clusteru existuje. Název koncového bodu by měl být jedinečný pro každý pracovní prostor a pro cluster, takže vytvořte koncový bod s jiným názvem.

CHYBA: BodováníFeUnhealthy

K této chybě může dojít při vytváření nebo aktualizaci online koncového bodu nebo nasazení Kubernetes, protože služba systému azureml-fe , která běží v clusteru, nebyla nalezena nebo není v pořádku. Pokud chcete tento problém zmírnit, přeinstalujte nebo aktualizujte rozšíření Azure Machine Learning ve vašem clusteru.

CHYBA: ValidateScoringFailed

K této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, protože ověření adresy URL žádosti o bodování selhalo při zpracování modelu. Zkontrolujte adresu URL koncového bodu a pak se pokuste znovu nasadit.

CHYBA: InvalidDeploymentSpec

K této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, protože specifikace nasazení je neplatná. Zkontrolujte chybovou zprávu a ujistěte se, instance count že je platná. Pokud jste povolili automatické škálování, ujistěte se, že minimum instance count jsou obě maximum instance count platné.

CHYBA: PodUnschedulable

K této chybě může dojít při vytváření nebo aktualizaci online koncových bodů nebo nasazení Kubernetes z jednoho z následujících důvodů:

  • Systém nemůže naplánovat pod na uzly kvůli nedostatečným prostředkům v clusteru.
  • Žádný uzel neodpovídá selektoru spřažení uzlů.

Pokud chcete tuto chybu zmírnit, postupujte takto:

  1. Zkontrolujte definici node selector použitého instance_type clusteru node label a konfiguraci uzlů clusteru.
  2. instance_type Zkontrolujte velikost skladové položky uzlu pro cluster AKS nebo prostředek uzlu pro cluster Kubernetes s podporou Azure Arc.
  3. Pokud je cluster nedostatečně prostředků, snižte požadavek na prostředek typu instance nebo použijte jiný typ instance s menšími požadavky na prostředky.
  4. Pokud cluster nemá další prostředky, které by splňovaly požadavek nasazení, odstraňte některá nasazení, aby uvolnila prostředky.

CHYBA: PodOutOfMemory

K této chybě může dojít při vytváření nebo aktualizaci online nasazení, protože limit paměti, který jste zadali pro nasazení, není dostatečná. Pokud chcete tuto chybu zmírnit, můžete nastavit limit paměti na větší hodnotu nebo použít větší typ instance.

CHYBA: InferencingClientCallFailed

K této chybě může dojít při vytváření nebo aktualizaci online koncových bodů nebo nasazení Kubernetes, protože rozšíření k8s clusteru Kubernetes není možné připojit. V takovém případě odpojte a znovu připojte výpočetní prostředky.

Pokud chcete vyřešit chyby opětovným připojením, nezapomeňte se znovu připojit se stejnou konfigurací jako odpojené výpočetní prostředky, jako je název výpočetních prostředků a obor názvů, abyste se vyhnuli dalším chybám. Pokud to stále nefunguje, požádejte správce, který má přístup ke clusteru kubectl get po -n azureml , aby zkontroloval, jestli jsou pody přenosového serveru spuštěné.

Problémy se spotřebou modelů

Mezi běžné chyby spotřeby modelu vyplývající ze stavu operace koncového bodu invoke patří problémy s omezením šířky pásma, zásady CORS a různé stavové kódy HTTP.

Problémy s limitem šířky pásma

Spravované online koncové body mají pro každý koncový bod omezení šířky pásma. Konfiguraci limitu najdete v limitech pro online koncové body. Pokud využití šířky pásma překročí limit, vaše žádost se zpozdí.

Pokud chcete monitorovat zpoždění šířky pásma, použijte metriku bajtů sítě k pochopení aktuálního využití šířky pásma. Další informace najdete v tématu Monitorování spravovaných online koncových bodů.

Pokud se vynutí limit šířky pásma, vrátí se dva přívěsy odpovědí:

  • ms-azureml-bandwidth-request-delay-ms je doba zpoždění v milisekundách, kterou trvalo pro přenos datového proudu požadavku.
  • ms-azureml-bandwidth-response-delay-msje doba zpoždění v milisekundách, která trvala pro přenos datového proudu odpovědi.

Blokované zásadami CORS

Online koncové body V2 nativně nepodporují sdílení prostředků mezi zdroji (CORS). Pokud se vaše webová aplikace pokusí vyvolat koncový bod bez správného zpracování předběžných požadavků CORS, zobrazí se následující chybová zpráva:

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.

Azure Functions, Aplikace Azure lication Gateway nebo jinou službu můžete použít jako dočasnou vrstvu pro zpracování předběžných požadavků CORS.

Stavové kódy HTTP

Při přístupu k online koncovým bodům pomocí požadavků REST splňují vrácené stavové kódy standardy stavových kódů HTTP. Následující části obsahují podrobnosti o tom, jak se chyby volání a predikce koncového bodu mapují na stavové kódy HTTP.

Běžné kódy chyb pro spravované online koncové body

Následující tabulka obsahuje běžné kódy chyb, když požadavky REST spotřebovávají spravované online koncové body:

Stavový kód Důvod Popis
200 OK Model se úspěšně spustil v mezích latence.
401 Neautorizováno Nemáte oprávnění k provedení požadované akce, například skóre nebo vypršení platnosti tokenu nebo nesprávného formátu. Další informace najdete v tématu Ověřování spravovaných online koncových bodů a ověřování klientů pro online koncové body.
404 Nenalezeno Koncový bod nemá žádné platné nasazení s kladnou váhou.
408 Vypršení časového limitu požadavku Provádění modelu trvalo déle než časový limit zadaný v request_timeout_ms rámci request_settings konfigurace nasazení modelu.
424 Chyba modelu Pokud kontejner modelu vrátí odpověď, která není 200, Azure vrátí hodnotu 424. Model Status Code Zkontrolujte dimenzi pod metrikou Requests Per Minute v Průzkumníku metrik služby Azure Monitor vašeho koncového bodu. Nebo zkontrolujte hlavičky ms-azureml-model-error-statuscode odpovědí a ms-azureml-model-error-reason další informace. Pokud se 424 dodává se selháním živého testu nebo sondy připravenosti, zvažte úpravu probeSettings , abyste umožnili větší dobu odezvy nebo připravenosti kontejneru.
429 Příliš mnoho čekajících požadavků Váš model momentálně dostává více požadavků, než dokáže zpracovat. Aby bylo zaručeno bezproblémové fungování, azure Machine Learning umožňuje v libovolném okamžiku provádět paralelní 2 * max_concurrent_requests_per_instance * instance_count requests zpracování. Žádosti, které překračují toto maximum, jsou odmítnuty.

Konfiguraci nasazení modelu můžete zkontrolovat v request_settings části a scale_settings ověřit a upravit tato nastavení. Také se ujistěte, že je proměnná WORKER_COUNT prostředí správně předána, jak je uvedeno v části RequestSettings.

Pokud se vám při použití automatického škálování zobrazí tato chyba, váš model dostává požadavky rychleji, než může vertikálně navýšit kapacitu systému. Zvažte opětovné odeslání požadavků s exponenciálním zpoždováním , abyste systému poskytli čas na úpravu. Počet instancí můžete také zvýšit pomocí kódu k výpočtu počtu instancí. Zkombinujte tyto kroky s nastavením automatického škálování, abyste měli jistotu, že je váš model připravený ke zpracování nárůstu požadavků.
429 Omezení rychlosti Počet žádostí za sekundu dosáhl limitů spravovaných online koncových bodů.
500 Vnitřní chyba serveru Infrastruktura zřízená službou Azure Machine Learning selhává.

Běžné kódy chyb pro online koncové body Kubernetes

Následující tabulka obsahuje běžné kódy chyb, když požadavky REST spotřebovávají online koncové body Kubernetes:

Stavový kód Chyba Popis
409 Chyba konfliktu Pokud už operace probíhá, všechny nové operace na stejném online koncovém bodu reagují chybou 409 konfliktů. Pokud například probíhá operace vytvoření nebo aktualizace online koncového bodu, vyvolá se při aktivaci nové operace odstranění chyba.
502 Výjimka nebo chybové ukončení v run() metodě souboru score.py Pokud dojde k chybě v score.py, například importovaný balíček, který v prostředí conda neexistuje, chyba syntaxe nebo chyba v init() metodě, přečtěte si téma CHYBA: ResourceNotReady pro ladění souboru.
503 Velké špičky požadavků za sekundu Automatické škálování je navržené tak, aby zpracovával postupné změny zatížení. Pokud dostáváte velké špičky požadavků za sekundu, klienti můžou obdržet stavový kód HTTP 503. I když automatické škálování rychle reaguje, trvá AKS značné množství času, než vytvoří více kontejnerů. Podívejte se, jak zabránit chybám stavových kódů 503.
504 Vyprší časový limit žádosti Stavový kód 504 označuje, že vypršel časový limit požadavku. Výchozí nastavení časového limitu je 5 sekund. Časový limit můžete zvýšit nebo zkusit urychlit koncový bod úpravou score.py , aby se odebraly nepotřebná volání. Pokud tyto akce problém neopraví, může být kód v nereagujícím stavu nebo nekonečné smyčce. Postupujte podle chyby: ResourceNotReady k ladění souboru score.py .
500 Vnitřní chyba serveru Infrastruktura zřízená službou Azure Machine Learning selhává.

Jak zabránit chybám stavových kódů 503

Online nasazení Kubernetes podporují automatické škálování, což umožňuje přidání replik pro podporu dodatečného zatížení. Další informace najdete v tématu Směrovač odvozování ve službě Azure Machine Learning. Rozhodnutí vertikálně navýšit nebo snížit kapacitu závisí na využití aktuálních replik kontejneru.

Dvě akce můžou pomoct zabránit chybám stavového kódu 503: Změna úrovně využití pro vytváření nových replik nebo změna minimálního počtu replik. Tyto přístupy můžete použít jednotlivě nebo v kombinaci.

  • Změňte cíl využití, při kterém automatické škálování vytváří nové repliky nastavením autoscale_target_utilization na nižší hodnotu. Tato změna nezpůsobí rychlejší vytváření replik, ale s nižší prahovou hodnotou využití. Změna hodnoty na 30 % například způsobí, že se repliky vytvoří, když dojde k 30% využití místo čekání na využití služby 70 %.

  • Změňte minimální počet replik tak, aby poskytoval větší fond, který dokáže zpracovat příchozí špičky.

Jak vypočítat počet instancí

Pokud chcete zvýšit počet instancí, můžete vypočítat požadované repliky následujícím způsobem:

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)

Poznámka:

Pokud obdržíte špičky požadavků větší než nové minimální repliky, můžete obdržet 503 znovu. Například s nárůstem provozu do koncového bodu možná budete muset zvýšit minimální repliky.

Pokud online koncový bod Kubernetes už používá aktuální maximální počet replik a stále získáte stavové kódy 503, zvyšte hodnotu, abyste zvýšili autoscale_max_replicas maximální počet replik.

Problémy s izolací sítě

Tato část obsahuje informace o běžných problémech s izolací sítě.

Online koncový bod se nepovede vytvořit se zprávou V1LegacyMode == true

Můžete nakonfigurovat pracovní prostor Služby Azure Machine Learning, pro v1_legacy_modekterý zakážete rozhraní API v2. Spravované online koncové body jsou funkcí platformy rozhraní API v2 a nefungují, pokud v1_legacy_mode je pro pracovní prostor povolený.

Zakázání v1_legacy_modenajdete v tématu Izolace sítě s v2.

Důležité

Před zakázání v1_legacy_modese obraťte na tým zabezpečení sítě, protože ho možná z nějakého důvodu povolil.

Vytvoření online koncového bodu s ověřováním na základě klíčů selže

Pomocí následujícího příkazu vypíšete pravidla sítě trezoru klíčů Azure pro váš pracovní prostor. Nahraďte <keyvault-name> názvem trezoru klíčů:

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

Odpověď pro tento příkaz se podobá následujícímu kódu JSON:

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

Pokud hodnota bypass není AzureServices, použijte pokyny v nastavení konfigurace sítě trezoru klíčů a nastavte ho na AzureServices.

Selhání online nasazení s chybou při stahování image

Poznámka:

Tento problém se týká použití starší verze metody izolace sítě pro spravované online koncové body, ve kterých Azure Machine Learning vytvoří spravovanou virtuální síť pro každé nasazení v rámci koncového bodu.

  1. Zkontrolujte, jestli egress-public-network-access je disabled příznakem nasazení. Pokud je tento příznak povolený a viditelnost registru kontejneru je soukromá, očekává se toto selhání.

  2. Pomocí následujícího příkazu zkontrolujte stav připojení privátního koncového bodu. Nahraďte <registry-name> názvem registru kontejneru Azure pro váš pracovní prostor:

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

    V kódu odpovědi ověřte, že status je pole nastavené na Approved. Pokud ne, použijte k jeho schválení následující příkaz. Nahraďte <private-endpoint-name> názvem vráceným z předchozího příkazu.

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

Bodovací koncový bod nejde přeložit

  1. Ověřte, že klient, který vydává žádost o hodnocení, je virtuální síť, která má přístup k pracovnímu prostoru Azure Machine Learning.

  2. nslookup Pomocí příkazu na názvu hostitele koncového bodu načtěte informace o IP adrese, například:

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

    Odpověď obsahuje adresu, která by měla být v rozsahu poskytovaném virtuální sítí.

    Poznámka:

    • V případě online koncového bodu Kubernetes by název hostitele koncového bodu měl být název hostitele CName (název domény), který je zadaný v clusteru Kubernetes.
    • Pokud je koncový bod HTTP, IP adresa se nachází v identifikátoru URI koncového bodu, který můžete získat z uživatelského rozhraní studia.
    • Další způsoby získání IP adresy koncového bodu najdete v online koncovém bodu Zabezpečeného Kubernetes.

  3. Pokud příkaz nslookup nepřeloží název hostitele, proveďte následující akce:

Spravované online koncové body

  1. Pomocí následujícího příkazu zkontrolujte, jestli záznam A existuje v zóně privátního názvového serveru domény (DNS) pro virtuální síť.

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

    Výsledky by měly obsahovat položku podobnou *.<GUID>.inference.<region>.

  2. Pokud se žádná hodnota odvozování nevrátí, odstraňte privátní koncový bod pracovního prostoru a pak ho znovu vytvořte. Další informace najdete v tématu Konfigurace privátního koncového bodu.

  3. Pokud pracovní prostor s privátním koncovým bodem používá vlastní server DNS, spuštěním následujícího příkazu ověřte, že překlad z vlastního DNS funguje správně.

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

Online koncové body Kubernetes

  1. Zkontrolujte konfiguraci DNS v clusteru Kubernetes.

  2. Pomocí následujícího příkazu také zkontrolujte, jestli azureml-fe funguje podle očekávání:

    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"

    V případě protokolu HTTP použijte následující příkaz:

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

  3. Pokud protokolY HTTPS curl selžou nebo vyprší časový limit, ale protokol HTTP funguje, zkontrolujte, jestli je certifikát platný.

  4. Pokud se předchozí proces nepodaří přeložit na záznam A, ověřte, jestli překlad funguje z Azure DNS (168.63.129.16).

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

  5. Pokud předchozí příkaz proběhne úspěšně, vyřešte potíže s podmíněným předáváním privátního propojení ve vlastním DNS.

U online nasazení nejde určit skóre

  1. Spuštěním následujícího příkazu zkontrolujte, jestli nasazení proběhlo úspěšně:

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

    Pokud se nasazení úspěšně dokončilo, hodnota state je Succeeded.

  2. Pokud nasazení proběhlo úspěšně, pomocí následujícího příkazu zkontrolujte, jestli je k nasazení přiřazený provoz. Nahraďte <endpointname> názvem vašeho koncového bodu.

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

    Odpověď z tohoto příkazu by měla obsahovat procento provozu přiřazeného k nasazením.

    Tip

    Tento krok není nutný, pokud k cílení na toto nasazení použijete hlavičku azureml-model-deployment v požadavku.

  3. Pokud jsou přiřazení provozu nebo hlavička nasazení správně nastavené, pomocí následujícího příkazu získejte protokoly pro koncový bod. Nahraďte <endpointname> názvem koncového bodu a <deploymentname> nasazením.

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

  4. Zkontrolujte protokoly a zjistěte, jestli při odeslání požadavku do nasazení nedochází k potížím se spuštěním kódu bodování.

Problémy se serverem odvození

Tato část obsahuje základní tipy pro řešení potíží pro server HTTP odvozování služby Azure Machine Learning.

Kontrola nainstalovaných balíčků

Při řešení problémů s nainstalovanými balíčky postupujte podle těchto kroků.

  1. Shromážděte informace o nainstalovaných balíčcích a verzích pro vaše prostředí Pythonu.

  2. Ověřte, že azureml-inference-server-http verze balíčku Pythonu zadaná v souboru prostředí odpovídá verzi serveru HTTP pro odvozování služby Azure Machine Learning zobrazenou v spouštěcím protokolu.

    V některých případech nástroj pro překladače závislostí pip nainstaluje neočekávané verze balíčků. Možná budete muset spustit pip , abyste opravovali nainstalované balíčky a verze.

  3. Pokud zadáte Flask nebo jeho závislosti ve vašem prostředí, odeberte tyto položky.

    • Závislé balíčky zahrnují flask, , itsdangerousjinja2, werkzeug, markupsafe, a click.
    • flask je uveden jako závislost v balíčku serveru. Nejlepším přístupem je umožnit serveru flask odvozovat balíček.
    • Pokud je server odvozování nakonfigurovaný tak, aby podporoval nové verze Flasku, server automaticky obdrží aktualizace balíčku, jakmile budou k dispozici.

Kontrola verze serveru

Balíček azureml-inference-server-http serveru se publikuje do PyPI. Stránka PyPI obsahuje protokol změn a všechny předchozí verze.

Pokud používáte starší verzi balíčku, aktualizujte konfiguraci na nejnovější verzi. Následující tabulka shrnuje stabilní verze, běžné problémy a doporučené úpravy:

Verze balíčku Popis Problém Rozlišení
0.4.x Zabalené v trénovacích obrázcích datovaných 20220601 nebo starších verzích a azureml-defaults verzích .1.34 balíčků prostřednictvím 1.43. Nejnovější stabilní verze je 0.4.13. U serverových verzí starších než 0.4.11 může docházet k problémům se závislostmi Flasku, například "can't import name Markup from jinja2". Pokud je to možné, upgradujte na verzi 0.4.13 nebo 0.8.x.
0.6.x Předinstalováno při odvozování imagí datovaných 20220516 a dřívějších verzí. Nejnovější stabilní verze je 0.6.1. – N/A
0.7.x Podporuje Flask 2. Nejnovější stabilní verze je 0.7.7. – N/A
0.8.x Změnil se formát protokolu. Podpora Pythonu 3.6 skončila. – N/A

Kontrola závislostí balíčků

Mezi nejdůležitější závislé balíčky pro azureml-inference-server-http balíček serveru patří:

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

Pokud jste balíček zadali azureml-defaults ve svém prostředí Pythonu, azureml-inference-server-http je balíček závislým balíčkem. Závislost se nainstaluje automaticky.

Tip

Pokud používáte sadu Python SDK v1 a explicitně nezadáte azureml-defaults balíček v prostředí Pythonu, může sada SDK balíček automaticky přidat. Verze packageru je však uzamčená vzhledem k verzi sady SDK. Pokud je 1.38.0například verze sady SDK , položka azureml-defaults==1.38.0 se přidá do požadavků pip prostředí.

TypeError při spuštění serveru

Při spuštění serveru se může zobrazit následující TypeError :

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

K této chybě dochází v případě, že máte ve svém prostředí Pythonu nainstalovaný Flask 2, ale azureml-inference-server-http verze balíčku flask 2 nepodporuje. Podpora flask 2 je k dispozici v azureml-inference-server-http balíčku verze 0.7.0 a novější a azureml-defaults balíček verze 1.44 a novější.

  • Pokud balíček Flask 2 nepoužíváte v imagi Dockeru služby Azure Machine Learning, použijte nejnovější verzi azureml-inference-server-http balíčku nebo azureml-defaults balíčku.

  • Pokud v imagi Dockeru služby Azure Machine Learning použijete balíček Flask 2, ověřte, že verze sestavení image je 2022 nebo novější.

    Verzi image najdete v protokolech kontejneru. Příklad:

    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 |

    Datum sestavení obrázku se zobrazí po zápisu Materialization Build . V předchozím příkladu je 20220708 verze image 8. července 2022. Obrázek v tomto příkladu je kompatibilní s Flaskem 2.

    Pokud v protokolu kontejneru nevidíte podobnou zprávu, vaše image je za aktuální a měla by se aktualizovat. Pokud používáte image CUDA (Compute Unified Device Architecture) a nemůžete najít novější image, zkontrolujte, jestli je vaše image v kontejnerech AzureML zastaralá. Určené nahrazení zastaralých imagí najdete.

    Pokud používáte server s online koncovým bodem, najdete protokoly také na stránce Protokoly na stránce Koncové body v studio Azure Machine Learning.

Pokud nasadíte pomocí sady SDK v1 a explicitně nezadáte image v konfiguraci nasazení, server použije openmpi4.1.0-ubuntu20.04 balíček s verzí, která odpovídá vaší místní sadě nástrojů sady SDK. Nainstalovaná verze ale nemusí být nejnovější dostupnou verzí image.

Pro sadu SDK verze 1.43 server ve výchozím nastavení nainstaluje openmpi4.1.0-ubuntu20.04:20220616 verzi balíčku, ale tato verze balíčku není kompatibilní se sadou SDK 1.43. Ujistěte se, že pro nasazení používáte nejnovější sadu SDK.

Pokud image nemůžete aktualizovat, můžete se dočasně vyhnout tomuto problému tak, že připnete azureml-defaults==1.43 položky nebo azureml-inference-server-http~=0.4.13 položky v souboru prostředí. Tyto položky směrují server k instalaci starší verze s flask 1.0.x.

ImportError nebo ModuleNotFoundError během spouštění serveru

Během spouštění serveru se můžete setkat s ImportError ModuleNotFoundError určitými moduly, například opencensus, jinja2, markupsafenebo click. Následující příklad ukazuje chybovou zprávu:

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

K chybám importu a modulu dochází při použití verze 0.4.10 nebo starších verzí serveru, které nepřipnou závislost Flask na kompatibilní verzi. Pokud chcete tomuto problému zabránit, nainstalujte novější verzi serveru.

Další běžné problémy

Další běžné problémy s online koncovými body souvisí s instalací a automatickým škálováním conda.

Problémy s instalací Conda

Problémy s nasazením MLflow obvykle vyplývají z problémů s instalací uživatelského prostředí zadaného v souboru conda.yml .

Pokud chcete ladit problémy s instalací conda, vyzkoušejte následující kroky:

  1. Zkontrolujte protokoly instalace conda. Pokud došlo k chybovému ukončení kontejneru nebo spuštění trvalo příliš dlouho, aktualizace prostředí Conda se pravděpodobně nepodařilo správně vyřešit.
  2. Nainstalujte soubor conda mlflow místně pomocí příkazu conda env create -n userenv -f <CONDA_ENV_FILENAME>.
  3. Pokud dojde k chybám místně, zkuste před opětovným nasazením vyřešit prostředí Conda a vytvořit funkční prostředí.
  4. Pokud se kontejner chybově ukončí, i když se vyřeší místně, může být velikost skladové položky použitá pro nasazení příliš malá.
    • Instalace balíčku Conda probíhá za běhu, takže pokud je velikost skladové položky příliš malá, aby vyhovovala všem balíčkům v souboru prostředí conda.yml , může dojít k chybovému ukončení kontejneru.
    • Virtuální počítač Standard_F4s_v2 je dobrá počáteční velikost skladové položky, ale v závislosti na závislostech, které určuje soubor conda, možná budete potřebovat větší virtuální počítače.
    • V případě online koncových bodů Kubernetes musí mít cluster Kubernetes minimálně čtyři jádra vCPU a 8 GB paměti.

Problémy s automatickým škálováním

Pokud máte potíže s automatickým škálováním, přečtěte si téma Řešení potíží s automatickým škálováním služby Azure Monitor.

U online koncových bodů Kubernetes je směrovač odvozování služby Azure Machine Learning front-end komponentou, která zpracovává automatické škálování pro všechna nasazení modelu v clusteru Kubernetes. Další informace najdete v tématu Automatické škálování směrování odvozování Kubernetes.

Související obsah