Řešení potíží s nasazením a vyhodnocováním online koncových bodů

  • Článek

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

Zjistěte, jak vyřešit běžné problémy s nasazením a vyhodnocováním koncových bodů Azure Machine Učení online.

Tento dokument je strukturovaný způsobem, 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.

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

Požadavky

Místní nasazení

Místním nasazením se označuje nasazení modelu do místního prostředí Dockeru. Místní nasazení je užitečné pro testování a ladění před nasazením do cloudu.

Tip

Můžete také použít Azure Machine Učení odvozování balíčku Python serveru HTTP k místnímu ladění hodnoticího skriptu. 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í.

Místní nasazení podporuje vytváření, aktualizaci a odstraňování místních koncových bodů. Umožňuje také vyvolat a získat protokoly z koncového bodu.

Pokud chcete použít místní nasazení, přidejte --local ho do příslušného příkazu rozhraní příkazového řádku:

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

V rámci místního nasazení se provádí následující kroky:

  • Docker buď sestaví novou image kontejneru, nebo stáhne existující image z místní mezipaměti Dockeru. Existující image se používá, pokud existuje, která odpovídá části prostředí souboru specifikace.
  • 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 Nasazení místně v části Nasazení a určení skóre modelu strojového učení.

Tip

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

Instalace Conda

Obecně platí, že problémy s nasazením MLflow pocházejí z problémů s instalací uživatelského prostředí zadaného conda.yaml v souboru.

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

  1. Zkontrolujte protokoly instalace conda. Pokud se kontejner chybově ukončil nebo se spustil příliš dlouho, je pravděpodobné, že se aktualizace prostředí Conda správně vyřešila.

  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á.

    1. 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 podrobně popsaným v conda.yaml souboru prostředí, může dojít k chybovému ukončení kontejneru.
    2. Virtuální počítač Standard_F4s_v2 je dobrá počáteční velikost skladové položky, ale v závislosti na tom, které závislosti jsou zadané v souboru conda, můžou být potřeba větší.
    3. V případě online koncového bodu Kubernetes musí mít cluster Kubernetes minimálně 4 jádra vCPU a 8 GB paměti.

Získání protokolů kontejneru

Nemůžete získat přímý přístup k virtuálnímu počítači, na kterém je model nasazený. Můžete ale získat protokoly z některých kontejnerů, které jsou na tomto virtuálním počítači spuštěné. 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.

Existují dva typy kontejnerů, ze které můžete protokoly získat:

  • Server odvozování: Protokoly zahrnují protokol konzoly (ze serveru odvozování), který obsahuje výstup funkcí tisku/protokolování ze skriptu bodování (score.py kód).
  • Inicializátor úložiště: Protokoly 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í.

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

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

--workspace-name Pokud --resource-group jste tyto parametry ještě nenastavili přes az configure.

Pokud chcete zobrazit informace o tom, jak tyto parametry nastavit, a pokud máte aktuálně nastavené hodnoty, spusťte:

az ml online-deployment get-logs -h

Ve výchozím nastavení se protokoly natahují ze serveru odvozování.

Poznámka:

Pokud používáte protokolování Pythonu, ujistěte se, že používáte správné pořadí úrovně protokolování pro publikování zpráv do protokolů. Například INFORMACE.

Protokoly můžete získat také z kontejneru inicializátoru úložiště předáním –-container storage-initializer.

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

U online koncového bodu Kubernetes mají správci přímý přístup ke clusteru, ve kterém model nasadíte, což je flexibilnější, aby mohli zkontrolovat přihlášení v Kubernetes. Příklad:

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

Trasování požadavků

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

  • x-request-id je vyhrazen pro trasování serverů. Tuto hlavičku přepíšeme, abychom zajistili, že se jedná o platný identifikátor GUID.

    Poznámka:

    Když vytvoříte lístek podpory pro neúspěšnou žádost, připojte ID neúspěšné žádosti, abyste urychlili šetření.

  • x-ms-client-request-id je k dispozici pro scénáře trasování klientů. Toto záhlaví je sanitizované tak, aby přijímalo pouze alfanumerické znaky, spojovníky a podtržítka a je zkráceno na maximálně 40 znaků.

Běžné chyby nasazení

Následující seznam obsahuje běžné chyby nasazení, které jsou hlášeny jako součást stavu operace nasazení:

Pokud vytváříte nebo aktualizujete online nasazení Kubernetes, zobrazí se 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ích najdete v protokolu sestavení. Protokol sestavení se nachází ve výchozím úložišti vašeho pracovního prostoru azure machine Učení. 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í seznam obsahuje běžné scénáře selhání sestavení image:

Pokud máte vypršení časových limitů ImageBuildu, doporučujeme také zkontrolovat výchozí nastavení sondy.

Selhání autorizace registru kontejneru

Pokud se chybová zpráva zmíní "container registry authorization failure" , znamená to, že nemůžete získat přístup k registru kontejneru s aktuálními přihlašovacími údaji. Desynchronizace klíčů prostředku pracovního prostoru může způsobit tuto chybu a automatická synchronizace nějakou dobu trvá. Můžete ale ručně volat synchronizaci klíčů, což může vyřešit selhání autorizace.

Registry kontejnerů, které jsou za virtuální sítí, se také můžou setkat s touto chybou, pokud jsou správně nastavené. Musíte ověřit, ž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ítě a služba Azure Container Registry pracovního prostoru je privátní a nakonfigurovaná s privátním koncovým bodem, musíte službě Azure Container Registry povolit vytváření imagí ve virtuální síti.

Selhání sestavení obecné image

Jak jsme uvedli dříve, můžete v protokolu sestavení zkontrolovat další informace o selhání. Pokud se v protokolu sestavení nenajde žádná zjevná chyba a poslední řádek je Installing pip dependencies: ...working..., může závislost způsobit chybu. Tento problém můžete vyřešit připnutím závislostí verzí v souboru conda.

Před nasazením do cloudu také doporučujeme nasadit místně a otestovat a ladit modely.

CHYBA: OutOfQuota

Následující seznam obsahuje běžné prostředky, které můžou při používání služeb Azure docházet k vyčerpání kvóty:

Kromě toho je následující seznam běžných prostředků, které můžou narazit na kvótu pouze pro online koncový bod Kubernetes:

Kvóta procesoru

Před nasazením modelu musíte mít dostatečnou kvótu výpočetních prostředků. Tato kvóta definuje, kolik virtuálních jader je k dispozici 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.

Možným zmírněním rizik je zkontrolovat, jestli neexistují nepoužívané nasazení, která můžete odstranit. Nebo můžete odeslat žádost o navýšení kvóty.

Kvóta clusteru

K tomuto problému dochází v případě, že nemáte dostatek kvóty clusteru Azure Machine Učení Compute. Tato kvóta definuje celkový počet clusterů, které se můžou používat najednou v rámci předplatného k nasazení uzlů CPU nebo GPU v Cloudu Azure.

Možným zmírněním rizik je zkontrolovat, jestli neexistují nepoužívané nasazení, která můžete odstranit. Nebo můžete odeslat žádost o navýšení kvóty. Nezapomeňte pro tuto žádost o navýšení kvóty vybrat Machine Learning Service: Cluster Quota typ kvóty.

Kvóta disků

K tomuto problému dochází v případě, že je velikost modelu větší než dostupné místo na disku a model se nedá stáhnout. Zkuste skladovou položku s větším místem na disku nebo zmenšit velikost image a modelu.

Kvóta paměti

K tomuto problému 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í

Při vytváření spravovaného online koncového bodu se pro přístup k prostředkům pracovního prostoru vyžaduje přiřazení role spravované identitě . Pokud dojde k dosažení 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 na webu Azure Portal tak, že přejdete do nabídky Řízení přístupu.

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, můžete zkusit 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í služby Azure Machine Učení online koncových bodů a dávkových koncových bodů.

Kvóta Kubernetes

K tomuto problému dochází v případě, že požadovaný procesor nebo paměť není možné poskytnout kvůli nenaplánovatelným uzlům pro toto nasazení. Uzly můžou být například pod cordonované nebo jinak nedostupné.

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

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

  • V případě it operací, které udržují cluster Kubernetes, můžete zkusit přidat další uzly nebo vymazat některé nepoužívané pody v clusteru a uvolnit některé prostředky.
  • Pro techniky strojového učení, kteří nasazují modely, se můžete pokusit snížit požadavek na prostředky vašeho nasazení:
    • Pokud přímo definujete požadavek na prostředek v konfiguraci nasazení prostřednictvím oddílu prostředků, můžete zkusit snížit požadavek na prostředek.
    • Pokud používáte instance type k definování prostředku pro nasazení modelu, můžete kontaktovat IT operace a upravit konfiguraci prostředku typu instance, další podrobnosti najdete v tématu Správa typu instance Kubernetes.

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

Kvůli nedostatku kapacity azure machine Učení 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

score.py Azure vytvoří kontejner, který zahrnuje všechny prostředky, které score.py jsou potřeba, a spustí skript bodování v daném kontejneru.

Pokud se váš kontejner nepodařilo spustit, znamená to, že se vyhodnocení nepovedlo. Může se stát, že kontejner požaduje více prostředků než to, co instance_type může podporovat. Pokud ano, zvažte aktualizaci instance_type online nasazení.

Pokud chcete získat přesný důvod chyby, spusťte:

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

CHYBA: BadArgument

Následující seznam obsahuje důvody, proč k této chybě může dojít při použití spravovaného online koncového bodu nebo online koncového bodu Kubernetes:

Následující seznam obsahuje důvody, proč k této chybě může dojít pouze při použití online koncového bodu Kubernetes:

Předplatné neexistuje

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

Další informace o předplatných Azure najdete v části Požadavky.

Chyba autorizace

Po zřízení výpočetního prostředku (při vytváření nasazení) se Azure pokusí vyžádat image kontejneru uživatele z pracovního prostoru Azure Container Registry (ACR). Pokusí se připojit uživatelský model a artefakty kódu do kontejneru uživatele z účtu úložiště pracovního prostoru.

K provedení těchto akcí Azure používá spravované identity pro přístup k účtu úložiště a registru kontejneru.

  • Pokud jste vytvořili 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 nepotřebujete žádná další oprávnění.

  • Pokud jste vytvořili 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 služby Storage k účtu úložiště pro pracovní prostor a oprávnění AcrPull pro pracovní prostor ve službě Azure Container Registry (ACR). Ujistěte se, že vaše identita přiřazená uživatelem má správná oprávnění.

Další informace najdete v tématu Chyba autorizace služby Container Registry.

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ásad a definici zásad, které vám pomůžou ladit tuto chybu, a článek struktury definic zásad Azure, který popisuje tipy pro zabránění selhání šablon.

Nejde stáhnout image kontejneru uživatele

Je možné, že se nepodařilo najít kontejner uživatele. Další podrobnosti najdete v protokolech kontejneru.

Ujistěte se, že je image kontejneru dostupná v ACR pracovního prostoru.

Pokud například image testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest zkontroluje úložiště s az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output tablepříponou .

Nejde stáhnout uživatelský model

Je možné, že model uživatele nebyl nalezen. Další podrobnosti najdete v protokolech kontejneru.

Ujistěte se, jestli jste model zaregistrovali do stejného pracovního prostoru jako nasazení. Zobrazení podrobností o modelu v pracovním prostoru:

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

Upozorňující

Pokud chcete získat informace o modelu, musíte zadat buď verzi, nebo popisek.

Můžete také zkontrolovat, 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.pklnapříklad objekt blob, můžete pomocí tohoto příkazu zkontrolovat, jestli existuje:

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

  • Pokud objekt blob existuje, můžete pomocí tohoto 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.

K této chybě dochází při pokusu o nasazení modelu MLflow s přístupem bez kódu ve spojení se starší metodou izolace sítě pro spravované online koncové body. Tuto funkci privátní sítě nelze použít ve spojení s formátem modelu MLFlow, pokud používáte starší metodu izolace sítě. 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, nastavíme při připojení výpočetních prostředků k pracovnímu prostoru Učení Azure 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á komponenta (azureml-fe), která směruje příchozí požadavky na odvozovací požadavky do nasazených služeb, se podle potřeby automaticky škáluje. Instaluje se během instalace rozšíření k8s.

Tato komponenta by měla být v pořádku v clusteru, alespoň jedna v pořádku replika. Tato chybová zpráva se zobrazí, pokud není dostupná při aktivaci online koncového bodu Kubernetes a vytvoření nebo žádosti o aktualizaci nasazení.

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

score.py Azure vytvoří kontejner, který zahrnuje všechny prostředky, které score.py jsou potřeba, a spustí skript bodování v daném kontejneru. Chyba v tomto scénáři spočívá v tom, že při spuštění dochází k chybovému ukončení tohoto kontejneru, což znamená, že bodování se nestane. K této chybě dochází v těchto případech:

  • Došlo k chybě .score.py Slouží get-logs k diagnostice běžných problémů:
    • Balíček, který score.py se pokusí importovat, není součástí prostředí conda.
    • Syntaktická chyba.
    • Chyba v init() metodě.
  • Pokud get-logs neprodukuje žádné protokoly, obvykle to znamená, že se kontejner nepodařilo spustit. Pokud chcete tento problém ladit, zkuste místo toho nasadit místně .
  • Testy připravenosti nebo aktivity nejsou správně nastavené.
  • Inicializace kontejneru trvá příliš dlouho, aby připravenost nebo sonda aktivity selhala nad rámec prahové hodnoty selhání. V tomto případě upravte nastavení sondy, abyste umožnili delší dobu inicializaci kontejneru. Nebo zkuste větší skladovou položku virtuálního počítače mezi podporovanými skladovými položkami virtuálních počítačů, což urychluje inicializaci.
  • V prostředí nastaveném kontejneru došlo k chybě, například chybějící závislost.
  • Když se TypeError: register() takes 3 positional arguments but 4 were given zobrazí chyba, zkontrolujte závislost mezi flask v2 a azureml-inference-server-http. Další informace najdete v nejčastějších dotazech k odvozování serveru HTTP.

CHYBA: ResourceNotFound

Následující seznam obsahuje důvody, proč k této chybě může dojít pouze při použití spravovaného online koncového bodu nebo online koncového bodu Kubernetes:

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 byl na účet úložiště odkazovaný, ale nemůžete ho najít v cestě, na které byl zadán. Nezapomeňte pečlivě zkontrolovat prostředky, které mohly být zadány přesnou cestou nebo pravopisem jejich názvů.

Další informace naleznete v tématu Řešení chyb nenalezena prostředku.

Chyba autorizace registru kontejneru

K této chybě dochází v případě, že se pro nasazení zadala image, která patří do privátního nebo jinak nepřístupného registru kontejneru. V tuto chvíli naše rozhraní API 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 postupujte následovně:

  1. Udělte roli vašeho privátního acrPull registru systémové identitě vašeho online koncového bodu.
  2. V definici prostředí zadejte adresu vaší privátní image a instrukci, která nebude upravovat (sestavit) image.

Pokud je zmírnění rizik ú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í rozhraní API pro diagnostiku pracovního prostoru.

CHYBA: OperationCanceled

Následující seznam obsahuje důvody, proč k této chybě může dojít při použití spravovaného online koncového bodu nebo online koncového bodu Kubernetes:

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í, když byla operace přepsána jinou operací, která má vyšší prioritu.

Opakování operace může umožnit provedení 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, abychom zajistili, že nenarazíme 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, aby pokračovala. Může to znamenat, že jste po počátečním požadavku odeslali podobný požadavek příliš brzy.

Opakování operace po čekání na několik sekund až minutu může umožnit jeho provedení 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í v těchto případech:

  • 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ž byly tajné kódy určené definicí nasazení jako odkazy (namapované na proměnné prostředí). Nezapomeňte, že 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

I když se snažíme poskytovat stabilní a spolehlivou službu, někdy se věci nedají podle plánu. Pokud se zobrazí tato chyba, znamená to, že na naší straně není něco v pořádku a musíme ji opravit. Odešlete lístek zákaznické podpory se všemi souvisejícími informacemi a můžeme problém vyřešit.

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

Chyby týkající se identity a ověřování:

Chyby týkající se crashloopbackoff:

Chyby týkající se hodnoticího skriptu:

Ostatní:

CHYBA: ACRSecretError

Následující seznam obsahuje důvody, proč při vytváření nebo aktualizaci online nasazení Kubernetes narazíte na tuto chybu:

  • Přiřazení role nebylo dokončeno. V takovém případě počkejte několik sekund a zkuste to znovu později.
  • Azure ARC (pro cluster Azure Arc Kubernetes) nebo rozšíření Azure Machine Učení (pro AKS) není správně nainstalované nebo nakonfigurované. Zkuste zkontrolovat konfiguraci a stav rozšíření Azure ARC nebo Azure Machine Učení.
  • Cluster Kubernetes má nesprávnou konfiguraci sítě, zkontrolujte proxy server, zásady sítě nebo certifikát.
    • Pokud používáte privátní cluster AKS, je potřeba nastavit privátní koncové body pro ACR, účet úložiště, pracovní prostor ve virtuální síti AKS.
  • Ujistěte se, že je vaše verze rozšíření Azure Machine Učení větší než verze 1.1.25.

CHYBA: TokenRefreshFailed

Příčinou této chyby je, že rozšíření nemůže získat přihlašovací údaje objektu zabezpečení z Azure, protože identita clusteru Kubernetes není správně nastavená. Přeinstalujte rozšíření Azure Machine Učení a zkuste to znovu.

CHYBA: GetAADTokenFailed

Příčinou této chyby je to, že požadavek clusteru Kubernetes na token Azure AD selhal nebo vypršel časový limit, zkontrolujte přístupnost sítě a zkuste to znovu.

  • Můžete postupovat podle konfigurace požadovaného síťového provozu a zkontrolovat odchozí proxy server a ujistit se, že se cluster může připojit k pracovnímu prostoru.
  • Adresu URL koncového bodu pracovního prostoru najdete v online koncovém bodu CRD v clusteru.

Pokud je váš pracovní prostor privátním pracovním prostorem, který zakázal přístup k veřejné síti, cluster Kubernetes by měl komunikovat pouze s tímto privátním pracovním prostorem prostřednictvím privátního propojení.

  • Můžete zkontrolovat, jestli přístup k pracovnímu prostoru umožňuje veřejný přístup, bez ohledu na to, jestli je samotný cluster AKS veřejný nebo soukromý, nemůže přistupovat k privátnímu pracovnímu prostoru.
  • Další informace najdete v prostředí pro odvozování služby Azure Kubernetes Service.

CHYBA: ACRAuthenticationChallengeFailed

Příčinou této chyby je to, že cluster Kubernetes nemůže kontaktovat službu ACR pracovního prostoru, aby mohl provést výzvu ověřování. Zkontrolujte síť, zejména přístup k veřejné síti ACR, a zkuste to znovu.

Při kontrole sítě můžete postupovat podle kroků pro řešení potíží v getAADTokenFailed .

CHYBA: ACRTokenExchangeFailed

Příčinou této chyby je to, že token ACR v clusteru Kubernetes selhal, protože token Azure AD ještě není autorizovaný. Vzhledem k tomu, že přiřazení role nějakou dobu trvá, můžete chvíli počkat a pak to zkusit znovu.

Příčinou tohoto selhání může být také příliš mnoho požadavků na službu ACR v té době, měla by se jednat o přechodnou chybu, kterou můžete zkusit později.

CHYBA: KubernetesUnaccessible

Během 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:

CHYBA: ImagePullLoopBackOff

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, je to, že nemůžete stáhnout image z registru kontejneru, což vede k selhání načítání imagí.

V takovém případě můžete zkontrolovat zásady sítě clusteru a registr kontejneru pracovního prostoru, pokud cluster dokáže vyžádat image z registru kontejneru.

CHYBA: DeploymentCrashLoopBackOff

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, je inicializace kontejneru uživatele. K této chybě existují dva možné důvody:

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

Pokud chcete tuto chybu zmírnit, nejprve můžete v protokolech nasazení zkontrolovat případné výjimky v uživatelských skriptech. Pokud chyba přetrvává, zkuste rozšířit prostředky nebo limit paměti typu instance.

CHYBA: KubernetesCrashLoopBackOff

Následující seznam obsahuje důvody, proč při vytváření nebo aktualizaci online koncových bodů/nasazení Kubernetes narazíte na tuto chybu:

  • Jeden nebo více podů zablokované ve stavu CrashLoopBackoff, můžete zkontrolovat, jestli protokol nasazení existuje, a zkontrolovat, jestli v protokolu nejsou chybové zprávy.
  • Při inicializaci kódu skóre došlo k chybě score.py a kontejner se chybově ukončil, můžete postupovat podle chyby: Část ResourceNotReady .
  • Proces vyhodnocování potřebuje více paměti, než je limit konfigurace nasazení nedostatečný, můžete zkusit nasazení aktualizovat s větším limitem paměti.

CHYBA: NamespaceNotFound

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online koncových bodů Kubernetes, je to, že obor názvů, který používá váš výpočetní objekt Kubernetes, není ve vašem clusteru dostupný.

Výpočetní prostředky Kubernetes můžete zkontrolovat na portálu pracovního prostoru a zkontrolovat obor názvů v clusteru Kubernetes. Pokud obor názvů není dostupný, můžete starší výpočetní prostředky odpojit a znovu připojit, abyste vytvořili nový, a zadat obor názvů, který už v clusteru existuje.

CHYBA: UserScriptInitFailed

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, je to, že funkce inicializace v nahraném score.py souboru vyvolala výjimku.

V protokolech nasazení můžete zobrazit podrobnou zprávu o výjimce a opravit ji.

CHYBA: UserScriptImportError

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, je to, že score.py nahraný soubor importoval nedostupné balíčky.

V protokolech nasazení můžete zobrazit podrobnou zprávu o výjimce a opravit ji.

CHYBA: UserScriptFunctionNotFound

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, je to, že score.py soubor, který jste nahráli, nemá funkci s názvem init() nebo run(). Kód můžete zkontrolovat a přidat funkci.

CHYBA: EndpointNotFound

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, je to, že systém nemůže najít prostředek koncového bodu pro nasazení v clusteru. Nasazení byste měli vytvořit v existujícím koncovém bodu nebo nejprve vytvořit tento koncový bod v clusteru.

CHYBA: EndpointAlreadyExists

Důvodem, proč k této chybě může dojít při vytváření online koncového bodu Kubernetes, je to, že ve vašem clusteru už existuje koncový bod pro vytvoření.

Název koncového bodu by měl být jedinečný pro každý pracovní prostor a pro cluster, takže v tomto případě byste měli vytvořit koncový bod s jiným názvem.

CHYBA: BodováníFeUnhealthy

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online koncového bodu nebo nasazení Kubernetes, je to proto , že služba Azureml-fe , která je systémová služba spuštěná v clusteru, nebyla nalezena nebo není v pořádku.

Pokud chcete tento problém vyřešit, můžete přeinstalovat nebo aktualizovat rozšíření Azure Machine Učení ve vašem clusteru.

CHYBA: ValidateScoringFailed

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, je to, že ověření adresy URL žádosti o bodování selhalo při zpracování nasazení modelu.

V takovém případě můžete nejprve zkontrolovat adresu URL koncového bodu a pak se pokusit nasazení znovu nasadit.

CHYBA: InvalidDeploymentSpec

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online nasazení Kubernetes, je to, že specifikace nasazení je neplatná.

V takovém případě můžete zkontrolovat chybovou zprávu.

  • 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

Následující seznam obsahuje důvody, proč při vytváření nebo aktualizaci online koncových bodů/nasazení Kubernetes narazíte na tuto chybu:

  • Nejde naplánovat pody na uzly, protože v clusteru nejsou dostatečné prostředky.
  • Spřažení nebo selektor uzlu neodpovídá žádnému uzlu.

Pokud chcete tuto chybu zmírnit, můžete postupovat takto:

  • Zkontrolujte definici node selector použitého instance type clusteru a node label konfiguraci uzlů clusteru.
  • Zkontrolujte instance type velikost skladové položky uzlu pro cluster AKS nebo prostředek uzlu pro cluster Arc-Kubernetes.
    • Pokud je cluster nedostatečně prostředků, můžete snížit požadavek na prostředek typu instance nebo použít jiný typ instance s menším požadovaným prostředkem.
  • Pokud cluster nemá další prostředek, který by splňoval požadavek nasazení, odstraňte některé nasazení, aby uvolnil prostředky.

CHYBA: PodOutOfMemory

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online nasazení, je limit paměti, který zadáte 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

Důvodem, proč k této chybě může dojít při vytváření nebo aktualizaci online koncových bodů Nebo nasazení Kubernetes, je to, že rozšíření k8s clusteru Kubernetes není možné připojit.

V takovém případě můžete výpočetní prostředky odpojit a pak znovu připojit .

Poznámka:

Pokud chcete vyřešit chyby opětovným připojením, ujistěte se, že chcete znovu připojit stejnou konfiguraci jako dříve odpojené výpočetní prostředky, jako je stejný název výpočetních prostředků a obor názvů, jinak může dojít k jiným chybám.

Pokud stále nefunguje, můžete požádat 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 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 Azure.

Pro online koncový bod Kubernetes existuje směrovač pro odvozování azure machine Učení, který je front-endovou komponentou pro zpracování automatického škálování pro všechna nasazení modelů v clusteru Kubernetes, najdete další informace o automatickém škálování směrování odvozování Kubernetes.

Běžné chyby spotřeby modelu

Následující seznam obsahuje běžné chyby spotřeby modelu způsobené stavem operace koncového bodu invoke .

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í. Monitorování zpoždění šířky pásma:

  • K pochopení aktuálního využití šířky pásma použijte metriku "Bajty sítě". 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: Prodleva v milisekundách trvala pro přenos datového proudu požadavku.
    • ms-azureml-bandwidth-response-delay-ms: Prodleva v milisekundách trvala pro přenos datového proudu odpovědi.

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. Toto jsou podrobnosti o tom, jak se chyby volání koncového bodu a predikce 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 při využívání spravovaných online koncových bodů s požadavky REST:

Stavový kód Fráze důvodu Proč se tento kód může vrátit
200 OK Model se úspěšně spustil v rámci vazby 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 Koncept ověřování koncového bodu a postup ověření pro koncový bod.
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 sondy aktivity nebo připravenosti, zvažte úpravu nastavení sondy, která umožní delší dobu odezvy sondy 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. Služba Azure Machine Učení implementovala systém, který v libovolném okamžiku umožňuje zpracování maximálního 2 * max_concurrent_requests_per_instance * instance_count requests počtu paralelně za účelem zajištění hladkého provozu. Ostatní žádosti, které toto maximum překročí, jsou odmítnuty. Konfiguraci nasazení modelu můžete zkontrolovat v částech request_settings a scale_settings a ověřit a upravit tato nastavení. Kromě toho, jak je uvedeno v definici YAML pro Požadavek Nastavení je důležité zajistit, aby byla proměnná WORKER_COUNT prostředí správně předána.

Pokud používáte automatické škálování a zobrazí se tato chyba, znamená to, že váš model dostává požadavky rychleji, než může systém vertikálně navýšit. V této situaci zvažte opětovné odeslání požadavků s exponenciálním zpožděním , aby systém získal čas, který potřebuje upravit. Počet instancí můžete také zvýšit pomocí kódu k výpočtu počtu instancí. Tyto kroky v kombinaci s nastavením automatického škálování pomáhají zajistit, aby váš model byl 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 Azure Machine Učení zřízená infrastruktura selhává.

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

Následující tabulka obsahuje běžné kódy chyb při využívání online koncových bodů Kubernetes s požadavky REST:

Stavový kód Fráze důvodu Proč se tento kód může vrátit
409 Chyba konfliktu Pokud už operace probíhá, všechny nové operace na stejném online koncovém bodu reagují na konfliktní chybu 409. Pokud například probíhá operace vytvoření nebo aktualizace online koncového bodu a pokud aktivujete novou operaci odstranění, dojde k chybě.
502 Vyvolala výjimku nebo došlo k chybě v run() metodě souboru score.py Pokud dojde k chybě score.py, například importovaný balíček neexistuje v prostředí conda, syntaktická chyba nebo selhání v init() metodě. Tady můžete ladit soubor.
503 Příjem velkých špiček v požadavcích 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ů. Tady můžete postupovat, abyste zabránili stavové kódy 503.
504 Vypršel časový limit požadavku. 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 tak, aby se odebraly nepotřebná volání. Pokud tyto akce problém neopraví, můžete ladit soubor score.py sem . Kód může být v nereagujícím stavu nebo nekonečné smyčce.
500 Vnitřní chyba serveru Azure Machine Učení zřízená infrastruktura selhává.

Jak zabránit stavovým kódům 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, které najdete v Azure Machine Učení směrovači odvozování. Rozhodnutí o vertikálním navýšení/snížení kapacity jsou založená na využití aktuálních replik kontejnerů.

Existují dvě věci, které vám můžou pomoct zabránit stavové kódy 503:

Tip

Tyto dva přístupy lze použít jednotlivě nebo v kombinaci.

  • Změňte úroveň využití, na které automatické škálování vytváří nové repliky. Cíl využití můžete upravit nastavením autoscale_target_utilization na nižší hodnotu.

    Důležité

    Tato změna nezpůsobí rychlejší vytváření replik. Místo toho se vytvoří s nižší prahovou hodnotou využití. Místo čekání na využití služby 70 % způsobí změna hodnoty na 30 % vytvoření replik při 30% využití.

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

  • Změňte minimální počet replik. Zvýšení minimálních replik poskytuje větší fond pro zpracování příchozích špiček.

    Pokud chcete zvýšit počet instancí, můžete vypočítat požadované repliky podle těchto kódů.

    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 znovu obdržet 503. Například s nárůstem provozu do koncového bodu možná budete muset zvýšit minimální repliky.

Jak vypočítat počet instancí

Pokud chcete zvýšit počet instancí, můžete vypočítat požadované repliky pomocí následujícího kódu:

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)

Blokované zásadami CORS

Online koncové body (v2) momentálně 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.

Doporučujeme používat Azure Functions, Aplikace Azure Gateway nebo jakoukoli službu jako dočasnou vrstvu pro zpracování předběžných požadavků CORS.

Běžné problémy s izolací sítě

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

Pracovní prostor Azure Machine Učení je možné nakonfigurovat pro v1_legacy_mode, což zakáže rozhraní API v2. Spravované online koncové body jsou funkcí platformy rozhraní API v2 a nebudou fungovat, pokud v1_legacy_mode je pro pracovní prostor povolený.

Důležité

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

Informace o zakázání v1_legacy_modenaleznete v tématu Izolace sítě s v2.

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ě služby Azure Key Vault 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 je podobná následujícímu dokumentu 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 Učení vytvoří spravovanou virtuální síť pro každé nasazení v rámci koncového bodu.

  1. Zkontrolujte, jestli egress-public-network-access je příznak pro nasazení zakázaný . 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 služby Azure Container Registry 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 dokumentu odpovědi ověřte, zda status je pole nastaveno na Approvedhodnotu . Pokud není schválená, pomocí následujícího příkazu ho schvalte. 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 Učení.

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

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

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

    Poznámka:

    V případě online koncového bodu Kubernetes by měl být název hostitele koncového bodu CName (název domény), který byl zadán v clusteru Kubernetes. Pokud se jedná o koncový bod HTTP, IP adresa bude obsažena v identifikátoru URI koncového bodu, který můžete získat přímo v uživatelském rozhraní sady Studio. Další způsoby, jak získat IP adresu koncového bodu, najdete v online koncovém bodu Secure Kubernetes.

  3. Pokud se název hostitele nepřeloží příkazem nslookup :

    Pro spravovaný online koncový bod:

    1. Zkontrolujte, jestli záznam A existuje v privátní zóně DNS pro virtuální síť.

      Pokud chcete zkontrolovat záznamy, použijte následující příkaz:

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

      Výsledky by měly obsahovat položku, která je podobná *.<GUID>.inference.<region>.

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

    3. Pokud je pracovní prostor s privátním koncovým bodem nastavený pomocí vlastního serveru DNS, použijte následující příkaz k ověření, jestli překlad funguje správně z vlastního DNS.

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

    Pro online koncový bod Kubernetes

    1. Zkontrolujte konfiguraci DNS v clusteru Kubernetes.

    2. Kromě toho můžete zkontrolovat, jestli azureml-fe funguje podle očekávání, použijte následující příkaz:

      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"

      Pro HTTP použijte

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

    Pokud protokolY HTTPS curl selže (např. vypršení časového limitu), ale http funguje, zkontrolujte, jestli je certifikát platný.

    Pokud se to 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

    Pokud to bude úspěšné, můžete vyřešit 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. Pomocí následujícího příkazu zkontrolujte, jestli se nasazení úspěšně nasadilo:

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

    Pokud se nasazení úspěšně dokončilo, bude Succeededhodnota state .

  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 koncového bodu:

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

    Tip

    Tento krok není potřeba, pokud k cílení na toto nasazení používáte hlavičku azureml-model-deployment v požadavku.

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

  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>

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

Řešení potíží se serverem odvození

V této části poskytujeme základní tipy pro řešení potíží pro Azure Machine Učení odvozování serveru HTTP.

Základní kroky

Základní kroky pro řešení potíží jsou:

  1. Shromážděte informace o verzi pro vaše prostředí Pythonu.
  2. Ujistěte se, že verze balíčku pythonu azureml-inference-server-http, která je zadaná v souboru prostředí, odpovídá verzi serveru HTTP pro odvozování AzureML, která se zobrazila v spouštěcím protokolu. Někdy překladač závislostí pipu vede k neočekávaným verzím nainstalovaných balíčků.
  3. Pokud ve svém prostředí zadáte Flask (a jeho závislosti), odeberte je. Mezi závislosti patří Flask, , Jinja2itsdangerous, Werkzeug, MarkupSafe, a click. Flask je v balíčku serveru uvedený jako závislost a je nejlepší nechat ho nainstalovat. Když server podporuje nové verze Flasku, automaticky je získáte.

Verze serveru

Balíček azureml-inference-server-http serveru se publikuje do PyPI. Náš protokol změn a všechny předchozí verze najdete na naší stránce PyPI. Pokud používáte starší verzi, aktualizujte na nejnovější verzi.

  • 0.4.x: Verze, která je součástí trénovacích obrázků ≤ 20220601 a v azureml-defaults>=1.34,<=1.43. 0.4.13 je poslední stabilní verze. Pokud používáte server před verzí 0.4.11, můžou se zobrazit problémy se závislostmi Flasku, například nejde importovat název Markup z jinja2. Pokud je to možné, doporučujeme upgradovat na 0.4.13 nebo 0.8.x (nejnovější verzi).
  • 0.6.x: Verze, která je předinstalovaná v odvozování obrázků ≤ 20220516. Nejnovější stabilní verze je 0.6.1.
  • 0.7.x: První verze, která podporuje Flask 2. Nejnovější stabilní verze je 0.7.7.
  • 0.8.x: Formát protokolu se změnil a podpora Pythonu 3.6 se ukončila.

Závislosti balíčků

Nejdůležitější balíčky pro server azureml-inference-server-http jsou následující balíčky:

  • Baňky
  • opencensus-ext-azure
  • odvození schématu

Pokud jste zadali azureml-defaults ve svém prostředí Pythonu, závisí balíček azureml-inference-server-http a nainstaluje se automaticky.

Tip

Pokud používáte sadu Python SDK v1 a explicitně nezadáte azureml-defaults v prostředí Pythonu, může sada SDK přidat balíček za vás. Uzamkne ho ale na verzi, na které je sada SDK zapnutá. Pokud je 1.38.0například verze sady SDK, přidá azureml-defaults==1.38.0 se do požadavků pip prostředí.

Nejčastější dotazy

1. Při spuštění serveru došlo k následující chybě:


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

Ve svém prostředí Pythonu máte nainstalovaný Flask 2 , ale používáte verzi azureml-inference-server-http , která nepodporuje Flask 2. Přidali jsme azureml-inference-server-http>=0.7.0podporu pro Flask 2, která je také součástí azureml-defaults>=1.44.

  • Pokud tento balíček nepoužíváte v imagi Dockeru AzureML, použijte nejnovější verzi azureml-inference-server-http nebo azureml-defaults.

  • Pokud tento balíček používáte s imagí Dockeru AzureML, ujistěte se, že používáte image integrovanou nebo po červenci 2022. Verze image je dostupná v protokolech kontejneru. Měli byste být schopni najít protokol podobný následujícímu:

    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 |

    Datum sestavení obrázku se zobrazí po "Materialization Build", který v předchozím příkladu je 20220708, nebo 8. července 2022. Tato image je kompatibilní s Flaskem 2. Pokud v protokolu kontejneru nevidíte banner podobný tomuto typu, je vaše image zahlcená a měla by se aktualizovat. Pokud používáte image CUDA a nemůžete najít novější image, zkontrolujte, jestli je vaše image v Kontejnerech AzureML zastaralá. Pokud ano, měli byste být schopni najít náhrady.

  • Pokud používáte server s online koncovým bodem, najdete protokoly také v části Protokoly nasazení na stránce online koncového bodu v studio Azure Machine Learning. Pokud nasadíte pomocí sady SDK v1 a explicitně nezadáte image v konfiguraci nasazení, použije se výchozí verze openmpi4.1.0-ubuntu20.04 , která odpovídá vaší místní sadě nástrojů sady SDK, což nemusí být nejnovější verze image. Například sada SDK 1.43 se ve výchozím nastavení použije openmpi4.1.0-ubuntu20.04:20220616, což není kompatibilní. Ujistěte se, že pro nasazení používáte nejnovější sadu SDK.

  • Pokud z nějakého důvodu nemůžete aktualizovat image, můžete se dočasně vyhnout problému připnutím azureml-defaults==1.43 nebo azureml-inference-server-http~=0.4.13, který nainstaluje starší verzi serveru s Flask 1.0.x.

2. Narazil(a) jsem na moduly ImportError nebo ModuleNotFoundError na moduly opencensus, MarkupSafejinja2, nebo click při spuštění, jako je následující zpráva:

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

Starší verze (<= 0.4.10) serveru nepřipnuly závislost Flasku na kompatibilní verze. Tento problém je opravený v nejnovější verzi serveru.

Další kroky