Udostępnij za pośrednictwem

Rozwiązywanie problemów z wdrażaniem i ocenianie punktów końcowych w trybie online

DOTYCZY: Rozszerzenie interfejsu wiersza polecenia platformy Azure w wersji 2 (current)Zestaw PYTHON SDK azure-ai-ml v2 (bieżąca)

W tym artykule opisano sposób rozwiązywania typowych problemów z wdrażaniem i ocenianiami punktów końcowych usługi Azure Machine Learning online oraz ich rozwiązywanie.

Struktura dokumentu odzwierciedla sposób rozwiązywania problemów:

  1. Użyj lokalnego wdrożenia, aby testować i debugować modele lokalnie przed ich wdrożeniem w chmurze.
  2. Wykorzystaj dzienniki kontenerów, aby łatwiej debugować problemy.
  3. Zapoznaj się z typowymi błędami wdrażania, jakie mogą wystąpić i dowiedz się jak je naprawić.

W sekcji Kody stanu HTTP wyjaśniono, jak wywołania i błędy przewidywania są mapowane na kody stanu HTTP podczas oceniania punktów końcowych za pomocą żądań REST.

Wymagania wstępne

  • Aktywna subskrypcja platformy Azure z bezpłatną lub płatną wersją usługi Azure Machine Learning. Uzyskaj bezpłatną subskrypcję platformy Azure w wersji próbnej.

Śledzenie żądań

Istnieją dwa obsługiwane nagłówki śledzenia:

  • x-request-id jest zarezerwowane do śledzenia serwera. Usługa Azure Machine Learning zastępuje ten nagłówek, aby upewnić się, że jest to prawidłowy identyfikator GUID. Po utworzeniu zgłoszenia pomocy technicznej dla nieudanego żądania, należy dołączyć identyfikator nieudanego żądania, aby przyspieszyć badanie. Alternatywnie podaj nazwę regionu i nazwę punktu końcowego.

  • x-ms-client-request-id jest dostępny dla scenariuszy śledzenia klientów. Ten nagłówek akceptuje tylko znaki alfanumeryczne, łączniki i podkreślenia i jest obcinany do maksymalnie 40 znaków.

Wdrażanie lokalne

Wdrożenie lokalne oznacza wdrożenie modelu w lokalnym środowisku platformy Docker. Wdrożenie lokalne obsługuje tworzenie, aktualizowanie i usuwanie lokalnego punktu końcowego oraz umożliwia wywoływanie i pobieranie dzienników z punktu końcowego. Wdrożenie lokalne jest przydatne do testowania i debugowania przed wdrożeniem w chmurze.

Napiwek

Możesz również użyć pakietu języka Python dla serwera HTTP wnioskowania usługi Azure Machine Learning, aby debugować skrypt oceniania lokalnie. Debugowanie za pomocą serwera wnioskowania ułatwia debugowanie skryptu oceniania przed wdrożeniem w lokalnych punktach końcowych, dzięki czemu można debugować bez wpływu na konfiguracje kontenera wdrożenia.

Lokalnie można wdrożyć za pomocą interfejsu wiersza polecenia platformy Azure lub zestawu SDK języka Python. Usługa Azure Machine Learning Studio nie obsługuje lokalnego wdrożenia ani lokalnych punktów końcowych.

Aby użyć wdrożenia lokalnego, dodaj --local do odpowiedniego polecenia.

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

Podczas wdrażania lokalnego są wykonywane następujące kroki:

  1. Platforma Docker tworzy nowy obraz kontenera lub ściąga istniejący obraz z lokalnej pamięci podręcznej platformy Docker. Platforma Docker używa istniejącego obrazu, jeśli pasuje do części środowiska pliku specyfikacji.
  2. Platforma Docker uruchamia nowy kontener z zainstalowanymi lokalnymi artefaktami, takimi jak pliki modelu i kodu.

Aby uzyskać więcej informacji, zobacz Wdrażanie i debugowanie lokalnie przy użyciu lokalnego punktu końcowego.

Napiwek

Możesz użyć programu Visual Studio Code do testowania i debugowania punktów końcowych lokalnie. Aby uzyskać więcej informacji, zobacz Debugowanie punktów końcowych online lokalnie w programie Visual Studio Code.

Pobierz dzienniki kontenera

Nie można uzyskać bezpośredniego dostępu do maszyny wirtualnej, na której jest wdrażany model, ale możesz pobrać dzienniki z niektórych kontenerów uruchomionych na maszynie wirtualnej. Ilość otrzymywanych informacji zależy od stanu aprowizacji wdrożenia. Jeśli określony kontener jest uruchomiony, zostaną wyświetlone jego dane wyjściowe konsoli. W przeciwnym razie zostanie wyświetlony komunikat, aby spróbować ponownie później.

Dzienniki można pobrać z następujących typów kontenerów:

  • Dziennik konsoli serwera wnioskowania zawiera dane wyjściowe funkcji drukowania i rejestrowania ze skryptu oceniania score.py kodu.
  • Dzienniki logowania inicjatora magazynu zawierają informacje o tym, czy kod i dane modelu zostały pomyślnie pobrane do kontenera. Kontener jest uruchamiany przed uruchomieniem kontenera serwera wnioskowania.

W przypadku punktów końcowych online platformy Kubernetes administratorzy mogą bezpośrednio uzyskać dostęp do klastra, w którym wdrożono model, i sprawdzić dzienniki w usłudze Kubernetes. Na przykład:

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

Uwaga

Jeśli używasz rejestrowania języka Python, upewnij się, że używasz poprawnego poziomu rejestrowania, takiego jak INFO, aby komunikaty zostały opublikowane w dziennikach.

Wyświetlanie danych wyjściowych dziennika z kontenerów

Aby wyświetlić dane wyjściowe dziennika z kontenera, użyj następującego polecenia:

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

lub

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

Domyślnie dzienniki są pobierane z serwera wnioskowania. Dzienniki można pobrać z kontenera inicjatora magazynu, przekazując polecenie –-container storage-initializer.

Dodaj --resource-group i --workspace-name do poleceń, jeśli nie ustawiłeś już tych parametrów za pomocą az configure. Aby wyświetlić informacje o sposobie ustawiania tych parametrów lub jeśli obecnie ustawiono wartości, uruchom następujące polecenie:

az ml online-deployment get-logs -h

Aby wyświetlić więcej informacji, dodaj --help lub --debug do poleceń.

Typowe błędy związane z wdrażaniem

Stan operacji wdrożenia może zgłaszać następujące typowe błędy wdrażania:

Jeśli tworzysz lub aktualizujesz wdrożenie online platformy Kubernetes, zobacz również Typowe błędy specyficzne dla wdrożeń platformy Kubernetes.

BŁĄD: ImageBuildFailure

Ten błąd jest zwracany podczas kompilowania środowiska obrazu platformy Docker. Aby uzyskać więcej informacji na temat błędu, możesz sprawdzić dziennik kompilacji. Dziennik kompilacji znajduje się w domyślnym magazynie dla obszaru roboczego usługi Azure Machine Learning.

Dokładna lokalizacja może zostać zwrócona w ramach błędu, na przykład "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

W poniższych sekcjach opisano typowe scenariusze niepowodzeń kompilacji obrazu:

Niepowodzenie autoryzacji usługi Azure Container Registry

Komunikat o błędzie mówi "container registry authorization failure", że nie można uzyskać dostępu do rejestru kontenerów przy użyciu bieżących poświadczeń. Desynchronizacja kluczy zasobów obszaru roboczego może spowodować ten błąd i automatyczne synchronizowanie zajmuje trochę czasu. Można jednak ręcznie wywołać synchronizację kluczy za pomocą polecenia az ml workspace sync-keys, co może rozwiązać problem z niepowodzeniem autoryzacji.

Rejestry kontenerów, które znajdują się za siecią wirtualną, mogą również napotkać ten błąd, jeśli są one niepoprawnie skonfigurowane. Sprawdź, czy sieć wirtualna jest prawidłowo skonfigurowana.

Obliczenia dla kompilacji obrazu nie są skonfigurowane w prywatnym obszarze roboczym z siecią wirtualną

Jeśli komunikat o błędzie zawiera wzmiankę "failed to communicate with the workspace's container registry", a używasz sieci wirtualnej, a rejestr kontenerów obszaru roboczego jest prywatny i skonfigurowany przy użyciu prywatnego punktu końcowego, musisz zezwolić usłudze Container Registry na kompilowanie obrazów w sieci wirtualnej.

Przekroczenie limitu czasu tworzenia obrazu

Przekroczenia limitu czasu kompilacji obrazu są często spowodowane zbyt dużym rozmiarem obrazu, aby można było ukończyć kompilowanie w przedziale czasowym tworzenia wdrożenia. Sprawdź dzienniki kompilacji obrazu w lokalizacji, którą określono w błędzie. Rejestrowane dane są ucinane w momencie przekroczenia limitu czasu budowania obrazu.

Aby rozwiązać ten problem, skompiluj obraz oddzielnie, aby obraz był ściągany tylko podczas tworzenia wdrożenia. Zapoznaj się również z domyślnymi ustawieniami sondy, jeśli występują przekroczenia limitu czasu podczas ImageBuild.

Błąd ogólnej budowy obrazu

Sprawdź dziennik kompilacji, aby uzyskać więcej informacji na temat błędu. Jeśli w dzienniku kompilacji nie znaleziono żadnego oczywistego błędu, a ostatni wiersz to Installing pip dependencies: ...working..., zależność może powodować błąd. Przypięcie zależności wersji w pliku conda może rozwiązać ten problem.

Spróbuj wdrożyć lokalnie , aby przetestować i debugować modele przed wdrożeniem w chmurze.

BŁĄD: OutOfQuota

W przypadku korzystania z usług platformy Azure następujące zasoby mogą zabraknąć limitu przydziału:

Tylko w przypadku punktów końcowych online platformy Kubernetes zasób Kubernetes może również zabraknąć limitu przydziału.

Limit przydziału CPU

Aby wdrożyć model, musisz mieć wystarczający limit przydziału zasobów obliczeniowych. Limit przydziału procesora DEFINIUJE liczbę rdzeni wirtualnych dostępnych dla subskrypcji, na obszar roboczy, jednostkę SKU i region. Każde wdrożenie odejmuje dostępny limit i dodaje go z powrotem po usunięciu, w zależności od typu jednostki SKU.

Możesz sprawdzić, czy istnieją nieużywane wdrożenia, które można usunąć, lub przesłać żądanie zwiększenia limitu przydziału.

Limit przydziału klastra

Ten OutOfQuota błąd występuje, gdy nie masz wystarczającego limitu przydziału klastra obliczeniowego usługi Azure Machine Learning. Limit przydziału definiuje łączną liczbę klastrów na subskrypcję, których można używać w tym samym czasie do wdrażania węzłów procesora CPU lub procesora GPU w chmurze platformy Azure.

Przydział dysku

Błąd OutOfQuota występuje, gdy rozmiar modelu jest większy niż dostępne miejsce na dysku i nie można pobrać modelu. Spróbuj użyć jednostki SKU z większą ilością miejsca na dysku lub zmniejszyć rozmiar obrazu i modelu.

Limit przydziału pamięci

Błąd OutOfQuota występuje, gdy ślad pamięci modelu jest większy niż dostępna pamięć. Spróbuj użyć jednostki SKU z większą ilością pamięci.

Przydział przydziału przypisania roli

Podczas tworzenia zarządzanego punktu końcowego online przypisanie roli jest wymagane, aby tożsamość zarządzana uzyskiwała dostęp do zasobów obszaru roboczego. Jeśli osiągniesz limit przydziału roli, spróbuj usunąć niektóre nieużywane przypisania ról w tej subskrypcji. Wszystkie przypisania ról można sprawdzić, wybierając pozycję Kontrola dostępu dla subskrypcji platformy Azure w witrynie Azure Portal.

Limit punktu końcowego

Spróbuj usunąć część nieużywanych punktów końcowych w tej subskrypcji. Jeśli wszystkie punkty końcowe są aktywnie używane, spróbuj zażądać zwiększenia limitu punktu końcowego. Aby dowiedzieć się więcej na temat limitu punktów końcowych, zapoznaj się z limitami przydziału punktów końcowych w usługach Azure Machine Learning, uwzględniając punkty końcowe online i wsadowe.

Limit przydziału platformy Kubernetes

Błąd OutOfQuota występuje, gdy żądanego procesora CPU lub pamięci nie można podać z powodu niemożliwych do uchwalenia węzłów dla tego wdrożenia. Na przykład węzły mogą być cordoned lub w inny sposób niedostępne.

Komunikat o błędzie zazwyczaj wskazuje brak zasobów w klastrze, na przykład OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Ten komunikat oznacza, że w klastrze znajduje się zbyt wiele podów i brakuje zasobów do wdrożenia nowego modelu zgodnie z twoim żądaniem.

Spróbuj wykonać następujące środki zaradcze, aby rozwiązać ten problem:

  • Operatorzy IT, którzy utrzymują klaster Kubernetes, mogą spróbować dodać więcej węzłów lub wyczyścić niektóre nieużywane zasobniki w klastrze, aby zwolnić niektóre zasoby.

  • Inżynierowie uczenia maszynowego, którzy wdrażają modele, mogą spróbować zmniejszyć żądanie zasobów wdrożenia.

    • Jeśli żądanie zasobu jest definiowane bezpośrednio w konfiguracji wdrożenia za pośrednictwem sekcji zasobu, spróbuj zmniejszyć żądanie zasobu.
    • Jeśli używasz instance_type do definiowania zasobu na potrzeby wdrażania modelu, skontaktuj się z operatorem IT, aby zmienić konfigurację wystąpień zasobów. Aby uzyskać więcej informacji, zobacz Tworzenie typów wystąpień i zarządzanie nimi.

Pojemność maszyny wirtualnej obejmującej cały region

Ze względu na brak pojemności usługi Azure Machine Learning w regionie usługa nie może aprowizować określonego rozmiaru maszyny wirtualnej. Spróbuj ponownie później lub spróbuj wdrożyć w innym regionie.

Inny limit przydziału

Aby uruchomić plik score.py , który należy podać w ramach wdrożenia, platforma Azure tworzy kontener zawierający wszystkie zasoby, których potrzebuje score.py . Następnie usługa Azure Machine Learning uruchamia skrypt oceniania w tym kontenerze. Jeśli nie można uruchomić kontenera, ocenianie nie będzie możliwe. Kontener może żądać większej ilości zasobów niż instance_type może obsłużyć. Rozważ zaktualizowanie instance_type wdrożenia online.

Aby uzyskać dokładną przyczynę błędu, wykonaj następującą akcję.

Uruchom następujące polecenie:

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

BŁĄD: BadArgument

Ten błąd może wystąpić w przypadku używania zarządzanych punktów końcowych online lub punktów końcowych online platformy Kubernetes z następujących powodów:

Ten błąd może również wystąpić tylko w przypadku korzystania z punktów końcowych online platformy Kubernetes z następujących powodów:

Subskrypcja nie istnieje

Przywołyna subskrypcja platformy Azure musi być istniejąca i aktywna. Ten błąd występuje, gdy platforma Azure nie może odnaleźć wprowadzonego identyfikatora subskrypcji. Błąd może być spowodowany literówką w identyfikatorze subskrypcji. Sprawdź dokładnie, czy identyfikator subskrypcji został poprawnie wprowadzony i jest obecnie aktywny.

Błąd autoryzacji

Po aprowizacji zasobu obliczeniowego podczas tworzenia wdrożenia platforma Azure ściąga obraz kontenera użytkownika z rejestru kontenerów obszaru roboczego i instaluje model użytkownika i artefakty kodu w kontenerze użytkownika z konta magazynu obszaru roboczego. Platforma Azure używa tożsamości zarządzanych do uzyskiwania dostępu do konta magazynu i rejestru kontenerów.

W przypadku utworzenia skojarzonego punktu końcowego z tożsamością przypisaną użytkownikowi, zarządzana tożsamość użytkownika musi mieć uprawnienia Czytelnik danych obiektu blob w magazynie na koncie magazynu obszaru roboczego oraz uprawnienie AcrPull w rejestrze kontenerów obszaru roboczego. Upewnij się, że tożsamość przypisana przez użytkownika ma odpowiednie uprawnienia.

Po włączeniu MDC, zarządzana tożsamość użytkownika musi mieć uprawnienie do współautorstwa danych w obiektach blob Storage na koncie magazynu obszaru roboczego. Aby uzyskać więcej informacji, zobacz Błąd autoryzacji obiektu blob Storage po włączeniu MDC.

Jeśli utworzysz skojarzony punkt końcowy z tożsamością przypisaną przez system, uprawnienie kontroli dostępu opartej na rolach (RBAC) platformy Azure zostanie automatycznie przyznane i nie będą potrzebne żadne dalsze uprawnienia. Aby uzyskać więcej informacji, zobacz Błąd autoryzacji rejestru kontenerów.

Nieprawidłowa specyfikacja funkcji szablonu

Ten błąd występuje, gdy funkcja szablonu została niepoprawnie określona. Napraw politykę lub usuń przypisanie polityki, aby odblokować. Komunikat o błędzie może zawierać nazwę przypisania zasad i definicję zasad, aby ułatwić debugowanie tego błędu. Zobacz Struktura definicji zasad platformy Azure, aby uzyskać porady, aby uniknąć błędów szablonów.

Nie można pobrać obrazu kontenera użytkownika

Nie można odnaleźć kontenera użytkownika. Sprawdź dzienniki kontenerów , aby uzyskać więcej szczegółów.

Upewnij się, że obraz kontenera jest dostępny w rejestrze kontenerów obszaru roboczego. Jeśli na przykład obraz to testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, możesz użyć następującego polecenia, aby sprawdzić repozytorium:

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

Nie można pobrać modelu użytkownika

Nie można odnaleźć modelu użytkownika. Sprawdź dzienniki kontenerów , aby uzyskać więcej szczegółów. Upewnij się, że model został zarejestrowany w tym samym obszarze roboczym co wdrożenie.

Aby wyświetlić szczegóły modelu w obszarze roboczym, wykonaj następującą akcję. Aby uzyskać informacje o modelu, należy określić wersję lub etykietę.

Uruchom następujące polecenie:

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

Sprawdź również, czy obiekty blob znajdują się na koncie magazynu obszaru roboczego. Jeśli na przykład obiekt blob to https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl, możesz użyć następującego polecenia, aby sprawdzić, czy obiekt blob istnieje:

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

Jeśli blob jest obecny, możesz użyć następującego polecenia, aby pobrać logi z inicjatora magazynu.

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

Format modelu MLflow z siecią prywatną jest nieobsługiwany

Nie można używać funkcji sieci prywatnej z formatem modelu MLflow, jeśli używasz starszej metody izolacji sieciowej dla zarządzanych punktów końcowych online. Jeśli musisz wdrożyć model MLflow za pomocą podejścia bez kodu, spróbuj użyć zarządzanej wirtualnej sieci obszaru roboczego.

Żądania zasobów większe niż limity

Żądania dotyczące zasobów muszą być mniejsze lub równe limitom. Jeśli nie ustawisz limitów, usługa Azure Machine Learning ustawia wartości domyślne podczas dołączania zasobów obliczeniowych do obszaru roboczego. Limity można sprawdzić w witrynie Azure Portal lub za pomocą az ml compute show polecenia .

Azureml-fe nie jest gotowy

Składnik front-end azureml-fe, który kieruje przychodzące żądania wnioskowania do wdrożonych usług, zostaje zainstalowany podczas instalacji rozszerzenia k8s i automatycznie skaluje się w razie potrzeby. Ten składnik powinien mieć co najmniej jedną replikę w dobrej kondycji w klastrze.

Ten błąd występuje, jeśli składnik nie jest dostępny podczas wyzwolenia punktu końcowego online Kubernetes lub w momencie utworzenia albo aktualizacji wdrożenia. Sprawdź status poda i dzienniki, aby rozwiązać ten problem. Możesz również spróbować zaktualizować rozszerzenie k8s zainstalowane w klastrze.

BŁĄD: ResourceNotReady

Aby uruchomić plik score.py , który należy podać w ramach wdrożenia, platforma Azure tworzy kontener zawierający wszystkie zasoby wymagane przez score.py i uruchamia skrypt oceniania w tym kontenerze. Błąd w tym scenariuszu polega na tym, że ten kontener ulega awarii podczas uruchamiania, więc ocenianie nie może się zdarzyć. Ten błąd może wystąpić w jednym z następujących warunków:

  • Wystąpił błąd w score.py. Użyj get-logs, aby zdiagnozować typowe problemy, takie jak:

    • Pakiet, który score.py próbuje zaimportować, nie jest uwzględniony w środowisku conda.
    • Błąd składni
    • Błąd w metodzie init()

    Jeśli get-logs nie generuje żadnych dzienników, zwykle oznacza to, że nie można uruchomić kontenera. Aby debugować ten problem, spróbuj wdrożyć lokalnie.

  • Sondy gotowości lub żywotności nie są prawidłowo skonfigurowane.

  • Inicjowanie kontenera trwa zbyt długo, więc sonda gotowości lub żywotności przekracza próg awarii. W takim przypadku dostosuj ustawienia sondy, aby umożliwić dłuższy czas inicjowania kontenera. Możesz też wypróbować większą, obsługiwaną jednostkę SKU maszyny wirtualnej, która przyspiesza inicjowanie.

  • W konfiguracji środowiska kontenera występuje błąd, taki jak brak zależności.

    Jeśli wystąpi TypeError: register() takes 3 positional arguments but 4 were given błąd, sprawdź zależność między Flask w wersji 2 a azureml-inference-server-http. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z serwerem HTTP.

BŁĄD: ResourceNotFound

Ten błąd może wystąpić podczas korzystania z zarządzanego punktu końcowego online lub punktu końcowego online platformy Kubernetes z następujących powodów:

Usługa Resource Manager nie może odnaleźć zasobu

Ten błąd występuje, gdy usługa Azure Resource Manager nie może znaleźć wymaganego zasobu. Na przykład, można otrzymać ten błąd, jeśli nie można znaleźć konta usługi magazynowej w określonej ścieżce. Sprawdź dokładnie ścieżkę lub specyfikacje nazw pod kątem dokładności i pisowni. Aby uzyskać więcej informacji, zobacz Rozwiązywanie błędów dotyczących nie znalezionego zasobu.

Błąd autoryzacji rejestru kontenerów

Ten błąd występuje, gdy do wdrożenia jest dostarczany obraz należący do prywatnego lub niedostępnego w inny sposób rejestru kontenerów. Interfejsy API usługi Azure Machine Learning nie mogą akceptować poświadczeń rejestru prywatnego.

Aby wyeliminować ten błąd, upewnij się, że rejestr kontenerów nie jest prywatny lub wykonaj następujące czynności:

  1. Nadaj rolę acrPull prywatnego rejestru dla tożsamości systemowej twojego punktu końcowego online.
  2. W definicji środowiska określ adres obrazu prywatnego i przekaż instrukcję, aby nie modyfikować ani kompilować obrazu.

Jeśli ten środek zaradczy powiedzie się, obraz nie wymaga budowania, a końcowy adres obrazu to podany adres obrazu. Podczas wdrażania, systemowa tożsamość punktu końcowego online pobiera obraz z rejestru prywatnego.

Aby uzyskać więcej informacji diagnostycznych, zobacz Jak używać diagnostyki obszaru roboczego.

BŁĄD: WorkspaceManagedNetworkNotReady

Ten błąd występuje, jeśli spróbujesz utworzyć wdrożenie online, które włącza zarządzaną sieć wirtualną obszaru roboczego, ale zarządzana sieć wirtualna nie jest jeszcze aprowizowana. Przygotuj zarządzaną sieć wirtualną obszaru roboczego przed utworzeniem wdrożenia online.

Aby ręcznie aprowizować zarządzaną sieć wirtualną obszaru roboczego, postępuj zgodnie z instrukcjami w temacie Ręczne aprowizuj zarządzaną sieć wirtualną. Następnie możesz rozpocząć tworzenie wdrożeń online. Aby uzyskać więcej informacji, zobacz Izolacja sieci z zarządzanym punktem końcowym online i Zabezpieczanie zarządzanych punktów końcowych online przy użyciu izolacji sieciowej.

BŁĄD: Anulowano operację

Ten błąd może wystąpić podczas korzystania z zarządzanego punktu końcowego online lub punktu końcowego online platformy Kubernetes z następujących powodów:

Operacja anulowana przez inną operację o wyższym priorytcie

Operacje platformy Azure mają określony poziom priorytetu i są wykonywane od najwyższego do najniższego. Ten błąd występuje, gdy inna operacja, która ma wyższy priorytet, zastępuje operację. Wykonanie ponownej próby operacji może umożliwić jej zakończenie bez anulowania.

Operacja anulowana. Oczekiwanie na potwierdzenie zamknięcia

Operacje platformy Azure mają krótki okres oczekiwania po przesłaniu, podczas którego pobierają blokadę, aby upewnić się, że nie napotykają warunków wyścigu. Ten błąd występuje, gdy przesłana operacja jest taka sama jak inna operacja. Druga operacja oczekuje obecnie na potwierdzenie otrzymania blokady przed kontynuowaniem.

Być może podobne żądanie zostało przesłane zbyt szybko po początkowym żądaniu. Ponawianie próby wykonania operacji po odczekaniu do minuty może pozwolić na jej wykonanie bez anulowania.

BŁĄD: SecretsInjectionError

Pobieranie i wstrzykiwanie tajemnic podczas tworzenia wdrożenia online wykorzystuje tożsamość związaną z punktem końcowym online do pobierania tajemnic z połączeń środowiska roboczego lub skarbców kluczy. Ten błąd występuje z jednego z następujących powodów:

  • Tożsamość punktu końcowego nie ma uprawnień Azure RBAC do odczytywania tajemnic z połączeń obszaru roboczego lub magazynów kluczy, nawet jeśli definicja wdrożenia wskazała tajemnice jako odwołania przypisane do zmiennych środowiskowych. Przypisanie roli może zająć trochę czasu, aby zmiany zaczęły obowiązywać.

  • Format odwołań do wpisów tajnych jest nieprawidłowy lub określone wpisy tajne nie istnieją w połączeniach obszaru roboczego lub magazynach kluczy.

Aby uzyskać więcej informacji, zobacz Wstrzykiwanie tajnych informacji w punktach końcowych online (wersja zapoznawcza) i Uzyskiwanie dostępu do tajemnic z wdrożenia online za pomocą wstrzykiwania tajnych informacji (wersja zapoznawcza).

BŁĄD: InternalServerError

Ten błąd oznacza, że wystąpił problem z usługą Azure Machine Learning, która musi zostać naprawiona. Wyślij zgłoszenie dla działu obsługi klienta ze wszystkimi informacjami potrzebnymi do rozwiązania problemu.

Typowe błędy specyficzne dla wdrożeń platformy Kubernetes

Błędy tożsamości i uwierzytelniania:

Błędy crashloopbackoff:

Błędy skryptu oceniania:

Inne błędy:

BŁĄD: ACRSecretError

Podczas tworzenia lub aktualizowania wdrożeń online platformy Kubernetes może wystąpić ten błąd z jednego z następujących powodów:

  • Przypisanie roli nie zostało ukończone. Poczekaj kilka sekund i spróbuj ponownie.

  • Klaster Kubernetes z obsługą Azure Arc lub rozszerzenie usługi Azure Machine Learning nie są poprawnie zainstalowane ani skonfigurowane. Sprawdź konfigurację i stan rozszerzenia Kubernetes z włączoną usługą Azure Arc lub Azure Machine Learning.

  • Klaster Kubernetes ma nieprawidłową konfigurację sieci. Sprawdź serwer proxy, zasady sieciowe lub certyfikat.

  • Prywatny klaster usługi AKS nie ma odpowiednich punktów końcowych. Upewnij się, że skonfigurujesz prywatne punkty końcowe dla Container Registry, konta magazynu i obszaru roboczego w sieci wirtualnej AKS.

  • Wersja rozszerzenia usługi Azure Machine Learning to wersja 1.1.25 lub nowsza. Upewnij się, że wersja rozszerzenia jest nowsza niż wersja 1.1.25.

BŁĄD: TokenRefreshFailed

Ten błąd występuje, ponieważ tożsamość klastra Kubernetes nie jest poprawnie ustawiona, więc rozszerzenie nie może uzyskać poświadczeń tożsamości z platformy Azure. Zainstaluj ponownie rozszerzenie usługi Azure Machine Learning i spróbuj ponownie.

BŁĄD: PobranieTokenuAADNieudane

Ten błąd występuje, ponieważ żądanie tokenu Microsoft Entra ID przez klaster Kubernetes nie powiodło się lub upłynął limit czasu. Sprawdź swoje połączenie z siecią, a następnie spróbuj ponownie.

  • Postępuj zgodnie z instrukcjami w artykule Korzystanie z obliczeń Kubernetes w celu sprawdzenia serwera proxy ruchu wychodzącego i upewnienia się, że klaster może połączyć się z obszarem roboczym. Adres URL punktu końcowego obszaru roboczego można znaleźć w niestandardowej definicji zasobu punktu końcowego online (CRD) w klastrze.

  • Sprawdź, czy obszar roboczy zezwala na dostęp publiczny. Niezależnie od tego, czy sam klaster usługi AKS jest publiczny czy prywatny, jeśli prywatny obszar roboczy wyłączy dostęp do sieci publicznej, klaster Kubernetes może komunikować się z tym obszarem roboczym tylko za pośrednictwem łącza prywatnego. Aby uzyskać więcej informacji, zobacz Co to jest bezpieczne środowisko wnioskowania usługi AKS.

BŁĄD: Niepowodzenie wyzwania uwierzytelniania ACR (ACRAuthenticationChallengeFailed)

Ten błąd występuje, ponieważ klaster Kubernetes nie może nawiązać połączenia z usługą Container Registry obszaru roboczego w celu wykonania zadania uwierzytelniania. Sprawdź sieć, zwłaszcza dostęp do sieci publicznej usługi Container Registry, a następnie spróbuj ponownie. Aby sprawdzić sieć, możesz wykonać kroki rozwiązywania problemów opisane w artykule GetAADTokenFailed .

BŁĄD: ACRTokenExchangeFailed

Ten błąd występuje, ponieważ token Microsoft Entra ID nie jest jeszcze autoryzowany, więc wymiana tokena w rejestrze kontenerów klastra Kubernetes kończy się niepowodzeniem. Przypisanie roli zajmuje trochę czasu, więc poczekaj minutę, a następnie spróbuj ponownie.

Ten błąd może być również spowodowany zbyt wieloma współbieżnych żądań do usługi Container Registry. Ten błąd powinien być przejściowy i można spróbować ponownie później.

BŁĄD: KubernetesUnaccessible

Podczas wdrożeń modelu Kubernetes może wystąpić następujący błąd:

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

Aby wyeliminować ten błąd, możesz przeprowadzić rotację certyfikatu AKS dla klastra. Nowy certyfikat powinien zostać zaktualizowany po upływie 5 godzin, aby można było poczekać 5 godzin i wdrożyć go ponownie. Aby uzyskać więcej informacji, zobacz Rotacja certyfikatów w usłudze Azure Kubernetes Service (AKS).

BŁĄD: ImagePullLoopBackOff

Ten błąd może wystąpić podczas tworzenia lub aktualizowania wdrożeń online platformy Kubernetes, ponieważ nie można pobrać obrazów z rejestru kontenerów, co powoduje niepowodzenie ściągania obrazów. Sprawdź zasady sieci klastra i rejestr kontenerów obszaru roboczego, aby sprawdzić, czy klaster może ściągać obrazy z rejestru kontenerów.

BŁĄD: DeploymentCrashLoopBackOff

Ten błąd może wystąpić podczas tworzenia lub aktualizowania wdrożeń online platformy Kubernetes, ponieważ kontener użytkownika uległ awarii podczas inicjowania. Istnieją dwa możliwe przyczyny tego błędu:

  • Skrypt użytkownika score.py zawiera błąd składniowy lub błąd importu, który zgłasza wyjątki podczas inicjowania.
  • Kontener wdrożeniowy potrzebuje więcej pamięci niż określony limit.

Aby wyeliminować ten błąd, najpierw sprawdź dzienniki wdrażania pod kątem wszelkich wyjątków w skryptach użytkownika. Jeśli błąd będzie się powtarzać, spróbuj rozszerzyć limit pamięci typu zasobu/wystąpienia.

BŁĄD: KubernetesCrashLoopBackOff

Ten błąd może wystąpić podczas tworzenia lub aktualizowania punktów końcowych usługi Kubernetes online lub wdrożeń z jednego z następujących powodów:

  • Co najmniej jeden pod jest zablokowany w stanie CrashLoopBackOff. Sprawdź, czy dziennik wdrażania istnieje i czy w dzienniku znajdują się komunikaty o błędach.
  • Wystąpił błąd w score.py , a kontener uległ awarii podczas inicjowania kodu oceny. Postępuj zgodnie z instrukcjami pod BŁĄD: ResourceNotReady.
  • Proces oceniania wymaga więcej pamięci niż limit konfiguracji wdrożenia. Możesz spróbować zaktualizować wdrożenie przy użyciu większego limitu pamięci.

BŁĄD: NamespaceNotFound

Taki błąd może wystąpić podczas tworzenia lub aktualizowania punktów końcowych Kubernetes online, ponieważ przestrzeń nazw wykorzystywana przez Twoje zasoby obliczeniowe Kubernetes jest niedostępna w klastrze. Sprawdź zasoby obliczeniowe Kubernetes w portalu obszaru roboczego i sprawdź przestrzeń nazw w klastrze Kubernetes. Jeśli przestrzeń nazw nie jest dostępna, odłącz starsze zasoby obliczeniowe i dołącz ponownie, aby utworzyć nową, określając przestrzeń nazw, która już istnieje w klastrze.

BŁĄD: UserScriptInitFailed

Ten błąd może wystąpić podczas tworzenia lub aktualizowania wdrożeń online usług Kubernetes, ponieważ funkcja init w przekazanym pliku score.py zgłosiła wyjątek. Sprawdź dzienniki wdrażania, aby wyświetlić szczegółowy komunikat o wyjątku i naprawić wyjątek.

BŁĄD: UserScriptImportError

Ten błąd może wystąpić podczas tworzenia lub aktualizowania wdrożeń online platformy Kubernetes, ponieważ przekazany plik score.py importuje niedostępne pakiety. Sprawdź dzienniki wdrażania, aby wyświetlić szczegółowy komunikat o wyjątku i naprawić wyjątek.

BŁĄD: UserScriptFunctionNotFound

Ten błąd może wystąpić podczas tworzenia lub aktualizowania wdrożeń online platformy Kubernetes, ponieważ przekazany plik score.py nie ma funkcji o nazwie init() lub run(). Sprawdź kod i dodaj funkcję .

BŁĄD: EndpointNotFound

Ten błąd może wystąpić podczas tworzenia lub aktualizowania wdrożeń online platformy Kubernetes, ponieważ system nie może odnaleźć zasobu punktu końcowego dla wdrożenia w klastrze. Utwórz wdrożenie w istniejącym punkcie końcowym lub, jeśli to konieczne, najpierw utwórz punkt końcowy w swoim klastrze.

BŁĄD: EndpointAlreadyExists

Ten błąd może wystąpić podczas tworzenia punktu końcowego online w Kubernetes, ponieważ ten punkt końcowy już istnieje w klastrze. Nazwa punktu końcowego powinna być unikatowa dla każdego obszaru roboczego i klastra, dlatego utwórz punkt końcowy o innej nazwie.

BŁĄD: ScoringFe nieprawidłowo działający

Ten błąd może wystąpić podczas tworzenia lub aktualizowania punktu końcowego usługi Kubernetes online lub wdrożenia, ponieważ usługa systemowa azureml-fe uruchomiona w klastrze nie została znaleziona lub jest w złej kondycji. Aby rozwiązać ten problem, zainstaluj ponownie lub zaktualizuj rozszerzenie usługi Azure Machine Learning w klastrze.

BŁĄD: Weryfikacja Wyniku Zakończona Niepowodzeniem

Ten błąd może wystąpić podczas tworzenia lub aktualizowania wdrożeń online platformy Kubernetes, ponieważ sprawdzanie poprawności adresu URL żądania oceniania nie powiodło się podczas przetwarzania modelu. Sprawdź adres URL punktu końcowego, a następnie spróbuj ponownie wdrożyć.

BŁĄD: NieprawidłowaSpecyfikacjaWdrożenia

Ten błąd może wystąpić podczas tworzenia lub aktualizowania wdrożeń online platformy Kubernetes, ponieważ specyfikacja wdrożenia jest nieprawidłowa. Sprawdź komunikat o błędzie, aby upewnić się, że instance count element jest prawidłowy. Jeśli włączono skalowanie automatyczne, upewnij się, że zarówno minimum instance count, jak i maximum instance count są prawidłowe.

BŁĄD: PodUnschedulable

Ten błąd może wystąpić podczas tworzenia lub aktualizowania punktów końcowych usługi Kubernetes online lub wdrożeń z jednego z następujących powodów:

  • System nie może zaplanować zasobnika na węzły z powodu niewystarczających zasobów w klastrze.
  • Żaden węzeł nie pasuje do selektora powiązania węzła.

Aby wyeliminować ten błąd, wykonaj następujące kroki:

  1. Sprawdź definicję node selector użytego instance_type oraz konfigurację węzłów klastra node label.
  2. instance_type Sprawdź rozmiar jednostki SKU węzła dla klastra usługi AKS lub zasobu węzła dla klastra Kubernetes z obsługą usługi Azure Arc.
  3. Jeśli klaster jest niedostatecznie zasobów, zmniejsz wymagania dotyczące zasobów typu instancji lub użyj innego typu instancji z mniejszymi wymaganiami dotyczącymi zasobów.
  4. Jeśli klaster nie ma więcej zasobów, aby spełnić wymagania wdrożenia, usuń niektóre wdrożenia, aby zwolnić zasoby.

BŁĄD: PodOutOfMemory

Ten błąd może wystąpić podczas tworzenia lub aktualizowania wdrożenia online, ponieważ limit pamięci udzielony dla wdrożenia jest niewystarczający. Aby wyeliminować ten błąd, możesz ustawić limit pamięci na większą wartość lub użyć większego typu wystąpienia.

BŁĄD: WnioskowanieClientCallFailed

Ten błąd może wystąpić podczas tworzenia lub aktualizowania punktów końcowych online lub wdrożeń w Kubernetes, ponieważ z rozszerzeniem k8s klastra Kubernetes nie można się połączyć. W takim przypadku odłącz i ponownie dołącz urządzenie obliczeniowe.

Aby rozwiązać problemy z błędami przez ponowne dołączanie, upewnij się, że ponownie dołączasz z tą samą konfiguracją co odłączone zasoby obliczeniowe, takie jak nazwa zasobu obliczeniowego i przestrzeń nazw, aby uniknąć innych błędów. Jeśli nadal nie działa, poproś administratora, który ma dostęp do klastra, aby użył kubectl get po -n azureml do sprawdzenia, czy pody serwera przekaźnika działają.

Problemy z konsumpcją modelu

Typowe błędy użycia modelu wynikające ze stanu operacji punktu końcowego invoke obejmują problemy z limitem przepustowości, zasady CORS i różne kody stanu HTTP.

Problemy z limitem przepustowości

Zarządzane punkty końcowe online mają limity przepustowości dla każdego punktu końcowego. Konfigurację limitu można znaleźć w limitach dla punktów końcowych online. Jeśli użycie przepustowości przekroczy limit, żądanie zostanie opóźnione.

Aby monitorować opóźnienie przepustowości, użyj metryki Bajty sieci, aby zrozumieć bieżące użycie przepustowości. Aby uzyskać więcej informacji, zobacz Monitorowanie zarządzanych punktów końcowych online.

W przypadku wymuszania limitu przepustowości są zwracane dwie przyczepy odpowiedzi:

  • ms-azureml-bandwidth-request-delay-ms to czas opóźnienia w milisekundach, który upłynął do przeniesienia strumienia żądania.
  • ms-azureml-bandwidth-response-delay-msto czas opóźnienia w milisekundach, który trwał na transfer strumienia odpowiedzi.

Zablokowane przez politykę CORS

Punkty końcowe online w wersji 2 nie obsługują natywnie współdzielenia zasobów między różnymi źródłami (CORS). Jeśli aplikacja internetowa próbuje wywołać punkt końcowy bez prawidłowej obsługi żądań wstępnych CORS, możesz uzyskać następujący komunikat o błędzie:

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.

Możesz użyć usługi Azure Functions, bramy aplikacyjnej systemu Azure lub innej usługi jako warstwy tymczasowej do obsługi żądań wstępnych CORS.

Kody stanu HTTP

W przypadku uzyskiwania dostępu do punktów końcowych online za pomocą żądań REST zwrócone kody stanu są zgodne ze standardami kodów stanu HTTP. W poniższych sekcjach przedstawiono szczegóły dotyczące sposobu, w jaki wywoływanie punktu końcowego i błędy przewidywania mapują się na kody stanu HTTP.

Typowe kody błędów zarządzanych punktów końcowych online

Poniższa tabela zawiera typowe kody błędów, gdy żądania REST używają zarządzanych punktów końcowych online:

Kod stanu Przyczyna opis
200 OK Model został wykonany pomyślnie w granicach opóźnienia.
401 Brak autoryzacji Nie masz uprawnień do wykonania żądanej akcji, takiej jak wynik, lub token wygasł lub ma nieprawidłowy format. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie dla zarządzanych punktów końcowych online i Uwierzytelnianie klientów dla punktów końcowych online.
404 Nie znaleziono Punkt końcowy nie ma żadnego prawidłowego wdrożenia z dodatnią wagą.
408 Przekroczono limit czasu żądania Wykonanie modelu trwało dłużej niż limit czasu podany w request_timeout_ms obszarze request_settings konfiguracji wdrożenia modelu.
424 Błąd modelu Jeśli kontener modelu zwraca odpowiedź inną niż 200, platforma Azure zwraca wartość 424. Model Status Code Sprawdź wymiar w Requests Per Minute obszarze metryki w Eksploratorze metryk usługi Azure Monitor punktu końcowego. Sprawdź też nagłówki odpowiedzi ms-azureml-model-error-statuscode i ms-azureml-model-error-reason, aby uzyskać więcej informacji. Jeśli 424 występuje z niepowodzeniem sondy liveness lub gotowości, rozważ dostosowanie parametru ProbeSettings, aby umożliwić więcej czasu na sondowanie gotowości lub działania kontenera.
429 Zbyt wiele oczekujących żądań Twój model otrzymuje obecnie więcej żądań, niż jest w stanie obsłużyć. Aby zagwarantować płynne działanie, usługa Azure Machine Learning pozwala na równoległe przetwarzanie maksymalnie 2 * max_concurrent_requests_per_instance * instance_count requests w dowolnym momencie. Żądania przekraczające tę wartość maksymalną są odrzucane.

Konfigurację wdrażania modelu można przejrzeć w sekcjach request_settings i scale_settings aby zweryfikować i dostosować te ustawienia. Upewnij się również, że zmienna środowiskowa WORKER_COUNT jest poprawnie przekazywana, zgodnie z opisem w artykule RequestSettings.

Jeśli wystąpi ten błąd podczas korzystania z skalowania automatycznego, model otrzymuje żądania szybciej niż system może skalować w górę. Rozważ ponowne wysyłanie żądań z wykładniczym odstępem czasowym, aby dać systemowi czas na dostosowanie. Można również zwiększyć liczbę wystąpień przy użyciu kodu w celu obliczenia liczby wystąpień. Połącz te kroki z ustawieniem skalowania automatycznego, aby upewnić się, że model jest gotowy do obsługi napływu żądań.
429 Ograniczony limit szybkości Liczba żądań na sekundę osiągnęła limity zarządzanych punktów końcowych online.
500 Wewnętrzny błąd serwera. Infrastruktura aprowizowana w usłudze Azure Machine Learning kończy się niepowodzeniem.

Typowe kody błędów dla punktów końcowych online platformy Kubernetes

Poniższa tabela zawiera typowe kody błędów, kiedy żądania REST konsumują punkty końcowe online platformy Kubernetes.

Kod stanu Błąd opis
409 Błąd konfliktu Kiedy operacja jest już w toku, każda nowa operacja na tym samym punkcie końcowym online powoduje błąd 409: konflikt. Jeśli na przykład operacja tworzenia lub aktualizowania punktu końcowego online jest w toku, wyzwalanie nowej operacji usuwania zgłasza błąd.
502 Wyjątek lub awaria run() w metodzie pliku score.py Jeśli wystąpił błąd w pliku score.py, na przykład zaimportowany pakiet, który nie istnieje w środowisku conda, błąd składni lub niepowodzenie w init() metodzie, sprawdź ERROR: ResourceNotReady aby debugować plik.
503 Duże skoki liczby żądań na sekundę Autoskalator został zaprojektowany tak, aby obsługiwał stopniowe zmiany obciążenia. W przypadku dużych skoków liczby żądań na sekundę klienci mogą otrzymywać kod stanu HTTP 503. Mimo że narzędzie do skalowania automatycznego szybko reaguje, utworzenie większej liczby kontenerów zajmuje usłudze AKS znaczną ilość czasu. Zobacz jak zapobiegać błędom związanym z kodem stanu 503.
504 Upłynął limit czasu żądania Kod stanu 504 wskazuje, że upłynął limit czasu żądania. Domyślne ustawienie limitu czasu wynosi 5 sekund. Możesz zwiększyć limit czasu lub spróbować przyspieszyć punkt końcowy, modyfikując score.py w celu usunięcia niepotrzebnych wywołań. Jeśli te akcje nie rozwiążą problemu, kod może znajdować się w stanie braku odpowiedzi lub nieskończonej pętli. Postępuj zgodnie z instrukcjami ERROR: ResourceNotReady , aby debugować plik score.py .
500 Wewnętrzny błąd serwera. Infrastruktura aprowizowana w usłudze Azure Machine Learning kończy się niepowodzeniem.

Jak zapobiec błędom kodu stanu 503

Wdrożenia online platformy Kubernetes obsługują skalowanie automatyczne, co umożliwia dodawanie replik do obsługi dodatkowego obciążenia. Aby uzyskać więcej informacji, zobacz Router inferencyjny usługi Azure Machine Learning. Decyzja o skalowaniu w górę lub w dół jest oparta na wykorzystaniu bieżących replik kontenerów.

Dwie akcje mogą pomóc w zapobieganiu błędom kodu stanu 503: zmiana poziomu wykorzystania na potrzeby tworzenia nowych replik lub zmiana minimalnej liczby replik. Można użyć tych podejść indywidualnie lub w połączeniu.

  • Zmień cel wykorzystania, w którym autoskalowanie tworzy nowe repliki, ustawiając autoscale_target_utilization wartość na niższą. Ta zmiana nie powoduje szybszego tworzenia replik, ale przy niższym progu wykorzystania. Na przykład zmiana wartości na 30% powoduje, że repliki są tworzone przy 30% wykorzystaniu, zamiast czekać, aż usługa będzie wykorzystywana w 70%.

  • Zmień minimalną liczbę replik, aby zapewnić większą pulę, która może obsługiwać nagłe wzrosty.

Jak obliczyć liczbę wystąpień

Aby zwiększyć liczbę wystąpień, możesz obliczyć wymagane repliki w następujący sposób:

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)

Uwaga

Jeśli otrzymasz skoki żądań większe niż mogą obsłużyć nowe minimalne repliki, kod błędu 503 może pojawić się ponownie. Na przykład w miarę wzrostu ruchu do punktu końcowego może być konieczne zwiększenie minimalnej liczby replik.

Jeśli punkt końcowy usługi Kubernetes w trybie online już używa bieżących maksymalnych replik i nadal otrzymujesz kody stanu 503, zwiększ wartość autoscale_max_replicas, aby zwiększyć maksymalną liczbę replik.

Problemy z izolacją sieci

Ta sekcja zawiera informacje o typowych problemach z izolacją sieci.

Tworzenie punktu końcowego online kończy się niepowodzeniem z komunikatem o starszym trybie w wersji 1

Zarządzane punkty końcowe online są funkcją platformy Azure Machine Learning API w wersji 2. Jeśli obszar roboczy usługi Azure Machine Learning jest skonfigurowany dla starszego trybu w wersji 1, zarządzane punkty końcowe online nie działają. W szczególności jeśli v1_legacy_mode ustawienie obszaru roboczego jest ustawione na true, tryb starszej wersji 1 jest włączony i nie ma obsługi interfejsów API w wersji 2.

Aby zobaczyć, jak wyłączyć tryb starszej wersji 1, zobacz Zmiana izolacji sieciowej za pomocą nowej platformy interfejsu API w usłudze Azure Resource Manager.

Ważne

Przed zmianą ustawienia z v1_legacy_mode na false skonsultuj się z zespołem ds. zabezpieczeń sieci, ponieważ tryb wstecznej zgodności wersji 1 może być włączony z jakiegoś powodu.

Tworzenie punktu końcowego online z uwierzytelnianiem opartym na kluczach kończy się niepowodzeniem

Użyj następującego polecenia, aby wyświetlić listę reguł sieciowych magazynu kluczy platformy Azure dla obszaru roboczego. Zastąp <key-vault-name> nazwą magazynu kluczy.

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

Odpowiedź dla tego polecenia jest podobna do następującego kodu JSON:

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

Jeśli wartość bypass nie jest równa AzureServices, skorzystaj ze wskazówek w temacie Konfigurowanie ustawień sieci usługi Azure Key Vault, aby ustawić ją na AzureServices.

Wdrożenia online kończą się niepowodzeniem z powodu błędu pobierania obrazu

Uwaga

Ten problem dotyczy użycia starszej metody izolacji sieciowej dla zarządzanych punktów końcowych online. W tej metodzie usługa Azure Machine Learning tworzy zarządzaną sieć wirtualną dla każdego wdrożenia w ramach punktu końcowego.

  1. Sprawdź, czy flaga egress-public-network-access ma wartość disabled dla wdrożenia. Jeśli ta flaga jest włączona, a widoczność rejestru kontenerów jest prywatna, ten błąd jest oczekiwany.

  2. Użyj następującego polecenia, aby sprawdzić stan połączenia prywatnego punktu końcowego. Zastąp <registry-name> nazwą usługi Azure Container Registry dla swojego obszaru roboczego.

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

    W kodzie odpowiedzi sprawdź, czy status pole jest ustawione na Approved. Jeśli wartość nie jest Approved, użyj następującego polecenia w celu zatwierdzenia połączenia. Zastąp <private-endpoint-connection-ID> identyfikatorem zwróconym przez poprzednie polecenie.

    az network private-endpoint-connection approve --id <private-endpoint-connection-ID> --description "Approved"

Nie można rozwiązać punktu końcowego skorowania

  1. Sprawdź, czy klient wystawiający żądanie oceniania jest siecią wirtualną, która może uzyskać dostęp do obszaru roboczego usługi Azure Machine Learning.

  2. nslookup Użyj polecenia w nazwie hosta punktu końcowego, aby pobrać informacje o adresie IP:

    nslookup <endpoint-name>.<endpoint-region>.inference.ml.azure.com

    Na przykład polecenie może wyglądać podobnie do następującego:

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

    Odpowiedź zawiera adres, który powinien znajdować się w zakresie dostarczonym przez sieć wirtualną.

    Uwaga

    • W przypadku punktu końcowego online platformy Kubernetes nazwa hosta punktu końcowego powinna być nazwą CName (nazwą domeny) określoną w klastrze Kubernetes.
    • Jeśli punkt końcowy używa protokołu HTTP, adres IP jest zawarty w identyfikatorze URI punktu końcowego, który można uzyskać z interfejsu użytkownika programu Studio.
    • Aby uzyskać więcej sposobów uzyskiwania adresu IP punktu końcowego, zobacz Aktualizowanie systemu DNS przy użyciu nazwy FQDN.

  3. nslookup Jeśli polecenie nie rozpozna nazwy hosta, wykonaj akcje w jednej z poniższych sekcji.

Zarządzane punkty końcowe online

  1. Użyj następującego polecenia, aby sprawdzić, czy rekord A istnieje w strefie prywatnej systemu nazw domen (DNS) dla sieci wirtualnej.

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

    Wyniki powinny zawierać wpis podobny do *.<GUID>.inference.<region>.

  2. Jeśli nie zostanie zwrócona żadna wartość inferencji, usuń prywatny punkt końcowy obszaru roboczego, a następnie utwórz go ponownie. Aby uzyskać więcej informacji, zobacz Jak skonfigurować prywatny punkt końcowy.

  3. Jeśli obszar roboczy z prywatnym punktem końcowym używa niestandardowego serwera DNS, uruchom następujące polecenie, aby sprawdzić, czy rozpoznawanie z niestandardowego serwera DNS działa poprawnie:

    dig <endpoint-name>.<endpoint-region>.inference.ml.azure.com

Punkty końcowe online platformy Kubernetes

  1. Sprawdź konfigurację DNS w klastrze Kubernetes.

  2. Sprawdź, azureml-feczy router wnioskowania usługi Azure Machine Learning działa zgodnie z oczekiwaniami. Aby wykonać tę kontrolę, wykonaj następujące czynności:

    1. Uruchom następujące polecenie w podzie azureml-fe :

      kubectl exec -it deploy/azureml-fe -- /bin/bash

    2. Uruchom jedno z następujących poleceń:

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

      W przypadku protokołu HTTP użyj następującego polecenia:

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

  3. Jeśli polecenie curl HTTPS kończy się niepowodzeniem lub upłynął limit czasu, ale polecenie HTTP działa, sprawdź, czy certyfikat jest prawidłowy.

  4. Jeśli poprzedni proces nie może rozpoznać rekordu A, użyj następującego polecenia, aby sprawdzić, czy rozpoznawanie działa z wirtualnego publicznego adresu IP usługi Azure DNS, 168.63.129.16:

    dig @168.63.129.16 <endpoint-name>.<endpoint-region>.inference.ml.azure.com

  5. Jeśli powyższe polecenie zakończy się pomyślnie, rozwiąż problemy z usługą przesyłania dalej warunkowego dla usługi Azure Private Link w niestandardowym systemie DNS.

Nie można ocenić wdrożeń online

  1. Uruchom następujące polecenie, aby wyświetlić stan wdrożenia, którego nie można ocenić:

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

    Wartość Succeeded pola state wskazuje pomyślne wdrożenie.

  2. W przypadku pomyślnego wdrożenia użyj następującego polecenia, aby sprawdzić, czy ruch jest przypisany do wdrożenia:

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

    Odpowiedź z tego polecenia powinna zawierać wartość procentową ruchu przypisanego do każdego wdrożenia.

    Napiwek

    Ten krok nie jest konieczny, jeśli używasz nagłówka azureml-model-deployment w żądaniu, aby skierować to wdrożenie.

  3. Jeśli przypisania ruchu lub nagłówek wdrożenia są poprawnie skonfigurowane, użyj następującego polecenia, aby pobrać logi dla punktu końcowego.

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

  4. Przejrzyj dzienniki, aby sprawdzić, czy wystąpił problem z uruchomieniem kodu oceniania podczas przesyłania żądania do wdrożenia.

Problemy z serwerem wnioskowania

Ta sekcja zawiera podstawowe porady dotyczące rozwiązywania problemów dla serwera HTTP do wnioskowania usługi Azure Machine Learning.

Sprawdzanie zainstalowanych pakietów

Wykonaj następujące kroki, aby rozwiązać problemy z zainstalowanymi pakietami:

  1. Zbierz informacje o zainstalowanych pakietach i wersjach dla środowiska języka Python.

  2. W pliku środowiska sprawdź wersję określonego azureml-inference-server-http pakietu języka Python. W dziennikach uruchamiania serwera HTTP usługi Azure Machine Learning sprawdź wersję serwera wnioskowania, która jest wyświetlana. Upewnij się, że obie wersje są zgodne.

    W niektórych przypadkach narzędzie pip do rozwiązywania zależności instaluje nieoczekiwane wersje pakietów. Może być konieczne uruchomienie polecenia pip , aby poprawić zainstalowane pakiety i wersje.

  3. Jeśli wymienisz Flask lub jego zależności w środowisku, usuń te elementy.

    • Pakiety zależne obejmują flask, , jinja2, itsdangerouswerkzeug, markupsafe, i click.
    • Pakiet flask jest wyświetlany jako zależność w pakiecie serwera wnioskowania. Najlepszym rozwiązaniem jest umożliwienie serwerowi wnioskowania zainstalowanie flask pakietu.
    • Gdy serwer wnioskowania jest skonfigurowany do obsługi nowych wersji platformy Flask, serwer wnioskowania automatycznie odbiera aktualizacje pakietów w miarę ich dostępności.

Sprawdzanie wersji serwera wnioskowania

Pakiet azureml-inference-server-http serwera jest publikowany na PyPI. Na stronie PyPI jest wyświetlana lista zmian i wszystkie wersje pakietu.

Jeśli używasz wczesnej wersji pakietu, zaktualizuj konfigurację do najnowszej wersji. Poniższa tabela zawiera podsumowanie stabilnych wersji, typowych problemów i zalecanych korekt:

Wersja pakietu opis Problem Rozwiązanie
0.4.x W pakiecie w obrazach szkoleniowych datowanych na 20220601 lub wcześniejsze oraz w wersjach pakietu od 0.1.34 do 1.43. Najnowsza stabilna wersja to 0.4.13. W przypadku wersji serwera starszych niż 0.4.11 mogą wystąpić problemy z zależnościami platformy Flask, takie jak can't import name Markup from jinja2. Uaktualnij do wersji 0.4.13 lub 1.4.x, jeśli jest to możliwe, najnowszą wersję.
0.6.x Wstępnie zainstalowane obrazy przetwarzania wnioskowania datowane na 20220516 i wcześniej. Najnowsza stabilna wersja to 0.6.1. Brak Brak
0.7.x Obsługuje platformę Flask 2. Najnowsza stabilna wersja to 0.7.7. Brak Brak
0.8.x Używa zaktualizowanego formatu dziennika. Kończy obsługę języka Python 3.6. Brak Brak
1.0.x Kończy obsługę języka Python 3.7. Brak Brak
1.1.x Migruje do pydantic wersji 2.0. Brak Brak
1.2.x Dodaje obsługę języka Python 3.11. Aktualizuje gunicorn do wersji 22.0.0. Aktualizacje werkzeug wersji 3.0.3 lub nowszej. Brak Brak
1.3.x Dodaje obsługę języka Python 3.12. certifi Uaktualnienia do wersji 2024.7.4. Uaktualnia flask-cors do wersji 5.0.0. Aktualizuje pakiety gunicorn i pydantic. Brak Brak
1.4.x waitress Uaktualnienia do wersji 3.0.1. Kończy obsługę języka Python 3.8. Usuwa warstwę zgodności, która zapobiega złamaniu kodu obiektu żądania podczas uaktualniania Flask 2.0. Jeśli zależysz od warstwy zgodności, kod obiektu żądania może nie działać. Przeprowadź migrację skryptu oceny do platformy Flask 2.

Sprawdzanie zależności pakietów

Najbardziej istotne pakiety zależne dla azureml-inference-server-http pakietu serwera obejmują:

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

Jeśli określisz pakiet azureml-defaults w swoim środowisku Python, to pakiet azureml-inference-server-http jest pakietem zależnym. Zależność jest instalowana automatycznie.

Napiwek

Jeśli używasz zestawu AZURE Machine Learning SDK dla języka Python w wersji 1 i nie określasz azureml-defaults jawnie pakietu w środowisku języka Python, zestaw SDK może automatycznie dodać pakiet. Jednak wersja pakietu jest zablokowana względem wersji zestawu SDK. Jeśli na przykład wersja zestawu SDK to 1.38.0, wpis azureml-defaults==1.38.0 zostanie dodany do wymagań środowiska pip.

TypeError podczas uruchamiania serwera wnioskowania

Podczas uruchamiania serwera wnioskowania mogą wystąpić następujące błędy 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

Ten błąd występuje, gdy platforma Flask 2 jest zainstalowana w środowisku języka Python, ale azureml-inference-server-http wersja pakietu nie obsługuje platformy Flask 2. Obsługa platformy Flask 2 jest dostępna w azureml-inference-server-http pakiecie 0.7.0 i nowszych wersjach oraz azureml-defaults pakiecie 1.44 i nowszych wersjach.

  • Jeśli nie używasz pakietu Flask 2 w obrazie Docker usługi Azure Machine Learning, użyj najnowszej wersji pakietu azureml-inference-server-http lub azureml-defaults.

  • Jeśli używasz pakietu Flask 2 w obrazie Docker usługi Azure Machine Learning, upewnij się, że wersja kompilacji obrazu jest July 2022 lub późniejsza.

    Wersję obrazu można znaleźć w dziennikach kontenera. Spójrz na przykład na następujące wyrażenia logów:

    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 |

    Data kompilacji obrazu pojawia się po notacji Materialization Build. W poprzednim przykładzie wersja obrazu to 20220708, czyli 8 lipca 2022 r. Obraz w tym przykładzie jest zgodny z platformą Flask 2.

    Jeśli w dzienniku kontenera nie widzisz podobnego komunikatu, obraz jest nieaktualny i powinien zostać zaktualizowany. Jeśli używasz obrazu Compute Unified Device Architecture (CUDA) i nie możesz znaleźć nowszego obrazu, sprawdź repozytorium AzureML-Containers , aby sprawdzić, czy obraz jest przestarzały. Można znaleźć wyznaczone zamienniki dla przestarzałych obrazów.

    Jeśli używasz serwera wnioskowania z punktem końcowym online, możesz również znaleźć dzienniki w usłudze Azure Machine Learning Studio. Na stronie punktu końcowego wybierz kartę Dzienniki .

Jeśli wdrażasz przy użyciu SDK v1 i nie określisz jawnie obrazu w konfiguracji wdrożenia, serwer wnioskowania użyje openmpi4.1.0-ubuntu20.04 pakietu z wersją zgodną z lokalnym zestawem SDK. Jednak zainstalowana wersja może nie być najnowszą dostępną wersją obrazu.

W przypadku zestawu SDK w wersji 1.43 serwer wnioskowania domyślnie instaluje openmpi4.1.0-ubuntu20.04:20220616 wersję pakietu, ale ta wersja pakietu nie jest zgodna z zestawem SDK 1.43. Upewnij się, że używasz najnowszego zestawu SDK do wdrożenia.

Jeśli nie możesz zaktualizować obrazu, możesz tymczasowo obejść ten problem, przypinając wpisy azureml-defaults==1.43 lub azureml-inference-server-http~=0.4.13 w pliku środowiska. Te wpisy kierują serwer wnioskowania, aby zainstalować starszą wersję za pomocą polecenia flask 1.0.x.

ImportError lub ModuleNotFoundError podczas uruchamiania serwera wnioskowania

Podczas uruchamiania serwera wnioskowania może wystąpić element ImportError lub ModuleNotFoundError w określonych modułach, takich jak opencensus, jinja2, markupsafelub click. Poniższy przykład przedstawia komunikat o błędzie:

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

Podczas korzystania z wersji 0.4.10 lub starszej wersji serwera wnioskowania występują błędy importowania i modułu, które nie przypinają zależności platformy Flask do zgodnej wersji. Aby zapobiec problemowi, zainstaluj nowszą wersję serwera wnioskowania.

Inne typowe problemy

Inne typowe problemy związane z punktami końcowymi online dotyczą instalacji conda i automatycznego skalowania.

Problemy z instalacją narzędzia Conda

Problemy z wdrożeniem platformy MLflow zwykle wynikają z problemów z instalacją środowiska użytkownika określonego w pliku conda.yml .

Aby debugować problemy z instalacją conda, spróbuj wykonać następujące czynności:

  1. Sprawdź dzienniki instalacji conda. Jeśli kontener uległ awarii lub uruchamiał się zbyt długo, aktualizacja środowiska conda prawdopodobnie nie powiodła się poprawnie.
  2. Zainstaluj lokalnie plik mlflow conda za pomocą polecenia conda env create -n userenv -f <CONDA_ENV_FILENAME>.
  3. Jeśli występują błędy lokalnie, spróbuj naprawić środowisko conda i utworzyć funkcjonalne środowisko przed ponownym wdrożeniem.
  4. Jeśli kontener ulegnie awarii, nawet jeśli rozwiąże problem lokalnie, rozmiar jednostki SKU używany do wdrożenia może być zbyt mały.
    • Instalacja pakietu Conda występuje w czasie wykonywania, więc jeśli rozmiar jednostki SKU jest zbyt mały, aby pomieścić wszystkie pakiety w pliku środowiska conda.yml , kontener może ulec awarii.
    • Maszyna wirtualna Standard_F4s_v2 jest dobrym początkowym rozmiarem jednostki SKU, ale może być potrzebna większa maszyna wirtualna w zależności od zależności, które określa plik Conda.
    • W przypadku punktów końcowych online platformy Kubernetes klaster Kubernetes musi mieć co najmniej cztery rdzenie procesorów wirtualnych i 8 GB pamięci.

Problemy z skalowaniem automatycznym

Jeśli masz problemy z skalowaniem automatycznym, zobacz Rozwiązywanie problemów z autoskalowaniem w usłudze Azure Monitor.

W przypadku punktów końcowych online Kubernetes, router wnioskowania usługi Azure Machine Learning jest składnikiem frontonowego, który obsługuje skalowanie automatyczne dla wszystkich wdrożeń modelu w klastrze Kubernetes. Aby uzyskać więcej informacji, zobacz Routing wnioskowania automatycznego skalowania Kubernetes.

Powiązana zawartość