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

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

Dowiedz się, jak rozwiązywać typowe problemy podczas wdrażania i oceniania punktów końcowych usługi Azure Machine Edukacja online.

Ten dokument jest ustrukturyzowany w sposób, w jaki należy rozwiązać problemy:

  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

Wdrażanie lokalne

Wdrożenie lokalne wdraża model w lokalnym środowisku platformy Docker. Wdrożenie lokalne jest przydatne do testowania i debugowania przed wdrożeniem w chmurze.

Napiwek

Możesz również użyć usługi Azure Machine Edukacja wnioskowania pakietu JĘZYKA Python serwera HTTP w celu lokalnego debugowania skryptu oceniania. 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.

Wdrożenie lokalne obsługuje tworzenie, aktualizowanie i usuwanie lokalnego punktu końcowego. Umożliwia również wywoływanie i uzyskiwanie dzienników z punktu końcowego.

Aby użyć wdrożenia lokalnego, dodaj --local do odpowiedniego polecenia interfejsu wiersza polecenia:

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

W ramach wdrożenia lokalnego należy wykonać następujące czynności:

  • Platforma Docker tworzy nowy obraz kontenera lub ściąga istniejący obraz z lokalnej pamięci podręcznej platformy Docker. Istniejący obraz jest używany, jeśli istnieje taki, który pasuje do części środowiska pliku specyfikacji.
  • Platforma Docker uruchamia nowy kontener z zainstalowanymi lokalnymi artefaktami, takimi jak pliki modelu i kodu.

Aby uzyskać więcej informacji, zobacz Wdrażanie lokalne w temacie Wdrażanie i ocenianie modelu uczenia maszynowego.

Napiwek

Użyj programu Visual Studio Code, aby przeprowadzić testowanie i debugowanie punktów końcowych lokalnie. Aby uzyskać więcej informacji, zobacz debugowanie punktów końcowych online lokalnie w programie Visual Studio Code.

Instalacja conda

Ogólnie rzecz biorąc, problemy z wdrożeniem platformy MLflow wynikają z problemów z instalacją środowiska użytkownika określonego conda.yaml w pliku.

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

  1. Sprawdź dzienniki instalacji conda. Jeśli uruchomienie kontenera uległo awarii lub trwa zbyt długo, prawdopodobnie aktualizacja środowiska conda nie mogła poprawnie rozwiązać problemu.

  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 rozwiązać środowisko conda i utworzyć funkcjonalny 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.

    1. Instalacja pakietu Conda występuje w czasie wykonywania, więc jeśli rozmiar jednostki SKU jest zbyt mały, aby pomieścić wszystkie pakiety szczegółowe w conda.yaml pliku środowiska, kontener może ulec awarii.
    2. Maszyna wirtualna Standard_F4s_v2 jest dobrym początkowym rozmiarem jednostki SKU, ale większe mogą być potrzebne w zależności od tego, które zależności są określone w pliku conda.
    3. W przypadku punktu końcowego online platformy Kubernetes klaster Kubernetes musi mieć co najmniej 4 rdzenie wirtualne i 8 GB pamięci.

Pobieranie dzienników kontenera

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

Istnieją dwa typy kontenerów, z których można pobrać dzienniki:

  • Serwer wnioskowania: dzienniki obejmują dziennik konsoli (z serwera wnioskowania), który zawiera dane wyjściowe funkcji drukowania/rejestrowania ze skryptu oceniania (score.py kod).
  • Inicjator magazynu: dzienniki zawierają informacje o tym, czy dane kodu i modelu zostały pomyślnie pobrane do kontenera. Kontener jest uruchamiany przed uruchomieniem kontenera serwera wnioskowania.

Aby wyświetlić dane wyjściowe dziennika z kontenera, użyj następującego polecenia interfejsu wiersza 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

Dodaj --resource-group polecenia i --workspace-name do tych poleceń, jeśli nie ustawiono jeszcze tych parametrów za pomocą polecenia az configure.

Aby wyświetlić informacje o sposobie ustawiania tych parametrów i jeśli obecnie ustawiono wartości, uruchom polecenie:

az ml online-deployment get-logs -h

Domyślnie dzienniki są pobierane z serwera wnioskowania.

Uwaga

Jeśli używasz rejestrowania języka Python, upewnij się, że używasz poprawnej kolejności rejestrowania komunikatów do opublikowania w dziennikach. Na przykład INFORMACJE.

Dzienniki można również pobrać z kontenera inicjatora magazynu, przekazując polecenie –-container storage-initializer.

Dodaj --help polecenia i/lub --debug do poleceń, aby wyświetlić więcej informacji.

W przypadku punktu końcowego online platformy Kubernetes administratorzy mogą bezpośrednio uzyskać dostęp do klastra, w którym wdrożono model, co jest bardziej elastyczne w celu sprawdzenia dziennika na platformie Kubernetes. Na przykład:

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

Śledzenie żądań

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

  • x-request-id jest zarezerwowana do śledzenia serwera. Zastąpimy ten nagłówek, aby upewnić się, że jest to prawidłowy identyfikator GUID.

    Uwaga

    Po utworzeniu biletu pomocy technicznej dla żądania, które zakończyło się niepowodzeniem, dołącz identyfikator żądania, który zakończył się niepowodzeniem, aby przyspieszyć badanie.

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

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

Poniższa lista zawiera typowe błędy wdrażania zgłaszane w ramach stanu operacji wdrażania:

Jeśli tworzysz lub aktualizujesz wdrożenie online platformy Kubernetes, możesz zobaczyć 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łędów, możesz sprawdzić dziennik kompilacji. Dziennik kompilacji znajduje się w domyślnym magazynie dla obszaru roboczego usługi Azure Machine Edukacja. 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]'".

Poniższa lista zawiera typowe scenariusze niepowodzenia kompilacji obrazu:

Zalecamy również przejrzenie domyślnych ustawień sondy, jeśli masz limity czasu programu ImageBuild.

Niepowodzenie autoryzacji rejestru kontenerów

Jeśli komunikat o błędzie wskazuje "container registry authorization failure" , że oznacza to, że nie można uzyskać dostępu do rejestru kontenerów przy użyciu bieżących poświadczeń. Desynchronizacja kluczy zasobu obszaru roboczego może spowodować ten błąd i automatyczne synchronizowanie zajmuje trochę czasu. Można jednak ręcznie wywołać synchronizację kluczy, co może rozwiązać problem z błędem autoryzacji.

Rejestry kontenerów, które znajdują się za siecią wirtualną, mogą również napotkać ten błąd, jeśli konfiguracja jest niepoprawna. Należy sprawdzić, czy sieć wirtualna jest prawidłowo skonfigurowana.

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

Jeśli komunikat o błędzie zawiera wzmianki "failed to communicate with the workspace's container registry" i używasz sieci wirtualnych, a usługa Azure Container Registry obszaru roboczego jest prywatna i skonfigurowana przy użyciu prywatnego punktu końcowego, musisz włączyć usługę Azure Container Registry , aby umożliwić tworzenie obrazów w sieci wirtualnej.

Błąd kompilacji obrazu ogólnego

Jak wspomniano wcześniej, możesz sprawdzić 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 spowodować błąd. Przypięcie zależności wersji w pliku conda może rozwiązać ten problem.

Zalecamy również lokalne wdrażanie w celu testowania i debugowania modeli lokalnie przed wdrożeniem w chmurze.

BŁĄD: OutOfQuota

Poniższa lista zawiera typowe zasoby, które mogą zabraknąć limitu przydziału podczas korzystania z usług platformy Azure:

Ponadto poniższa lista zawiera typowe zasoby, które mogą zabraknąć limitu przydziału tylko dla punktu końcowego online platformy Kubernetes:

Limit przydziału procesora CPU

Przed wdrożeniem modelu musisz mieć wystarczający limit przydziału zasobów obliczeniowych. Ten limit przydziału określa, ile rdzeni wirtualnych jest dostępnych dla subskrypcji, na obszar roboczy, na jednostkę SKU i na region. Każde wdrożenie odejmuje dostępny limit przydziału i dodaje go z powrotem po usunięciu na podstawie typu jednostki SKU.

Możliwe ograniczenie ryzyka polega na sprawdzeniu, czy istnieją nieużywane wdrożenia, które można usunąć. Możesz też przesłać żądanie zwiększenia limitu przydziału.

Limit przydziału klastra

Ten problem występuje, gdy nie masz wystarczającej ilości przydziału klastra obliczeniowego usługi Azure Machine Edukacja. Ten limit przydziału definiuje łączną liczbę klastrów, które mogą być używane jednocześnie w ramach subskrypcji w celu wdrożenia węzłów procesora CPU lub procesora GPU w chmurze platformy Azure.

Możliwe ograniczenie ryzyka polega na sprawdzeniu, czy istnieją nieużywane wdrożenia, które można usunąć. Możesz też przesłać żądanie zwiększenia limitu przydziału. Upewnij się, że wybrano Machine Learning Service: Cluster Quota typ limitu przydziału dla tego żądania zwiększenia limitu przydziału.

Przydział dysku

Ten problem 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 zmniejszenie rozmiaru obrazu i modelu.

Limit przydziału pamięci

Ten problem występuje, gdy ilość pamięci modelu jest większa 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 limit przydziału roli zostanie osiągnięty, spróbuj usunąć niektóre nieużywane przypisania ról w tej subskrypcji. Wszystkie przypisania ról można sprawdzić w witrynie Azure Portal, przechodząc do menu Kontrola dostępu.

Limit przydziału punktu końcowego

Spróbuj usunąć niektóre nieużywane punkty końcowe w tej subskrypcji. Jeśli wszystkie punkty końcowe są aktywnie używane, możesz spróbować zażądać zwiększenia limitu punktu końcowego. Aby dowiedzieć się więcej na temat limitu punktu końcowego, zobacz Limit przydziału punktów końcowych za pomocą usługi Azure Machine Edukacja punktów końcowych online i punktów końcowych wsadowych.

Limit przydziału platformy Kubernetes

Ten problem występuje, gdy żądany procesor CPU lub pamięć nie jest w stanie zostać dostarczony z powodu braku możliwości zaplanowanych 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 zasób niewystarczający w klastrze, na przykład OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods..., co oznacza, że w klastrze jest zbyt wiele zasobników i za mało zasobów, aby wdrożyć nowy model na podstawie żądania.

Aby rozwiązać ten problem, możesz spróbować rozwiązać następujący problem:

  • W przypadku operacji IT, które utrzymują klaster Kubernetes, możesz spróbować dodać więcej węzłów lub wyczyścić niektóre nieużywane zasobniki w klastrze, aby zwolnić niektóre zasoby.
  • W przypadku inżynierów uczenia maszynowego, którzy wdrażają modele, możesz 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, możesz spróbować zmniejszyć żądanie zasobu.
    • Jeśli używasz instance type metody do definiowania zasobu na potrzeby wdrażania modelu, możesz skontaktować się z działem IT, aby dostosować konfigurację zasobu typu wystąpienia, więcej szczegółów można znaleźć w temacie Jak zarządzać typem wystąpienia kubernetes.

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

Ze względu na brak pojemności usługi Azure Machine Edukacja w regionie usługa nie mogła 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ć score.py element udostępniony w ramach wdrożenia, platforma Azure tworzy kontener zawierający wszystkie zasoby, których score.py potrzebują, i uruchamia skrypt oceniania w tym kontenerze.

Jeśli nie można uruchomić kontenera, oznacza to, że ocena nie może się zdarzyć. Może się okazać, że kontener żąda więcej zasobów niż to, co instance_type może obsługiwać. Jeśli tak, rozważ zaktualizowanie instance_type wdrożenia online.

Aby uzyskać dokładną przyczynę błędu, uruchom polecenie:

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

BŁĄD: BadArgument

Poniższa lista jest przyczyną wystąpienia tego błędu podczas korzystania z zarządzanego punktu końcowego online lub punktu końcowego online platformy Kubernetes:

Poniższa lista jest przyczyną wystąpienia tego błędu tylko w przypadku korzystania z punktu końcowego online platformy Kubernetes:

Subskrypcja nie istnieje

Wprowadzona subskrypcja platformy Azure musi być istniejąca. Ten błąd występuje, gdy nie można odnaleźć subskrypcji platformy Azure, do którego odwołuje się odwołanie. Ten błąd prawdopodobnie wynika z literówki w identyfikatorze subskrypcji. Sprawdź dokładnie, czy identyfikator subskrypcji został poprawnie wpisany i czy jest on obecnie aktywny.

Aby uzyskać więcej informacji na temat subskrypcji platformy Azure, zobacz sekcję wymagań wstępnych.

Błąd autoryzacji

Po aprowizacji zasobu obliczeniowego (podczas tworzenia wdrożenia) platforma Azure próbuje ściągnąć obraz kontenera użytkownika z obszaru roboczego usługi Azure Container Registry (ACR). Próbuje zainstalować model użytkownika i artefakty kodu w kontenerze użytkownika z konta magazynu obszaru roboczego.

Aby wykonać te akcje, platforma Azure używa tożsamości zarządzanych do uzyskiwania dostępu do konta magazynu i rejestru kontenerów.

  • Jeśli utworzono skojarzony punkt końcowy z tożsamością przypisaną przez system, uprawnienie kontroli dostępu na podstawie ról (RBAC) platformy Azure zostanie automatycznie przyznane i nie będą potrzebne żadne dalsze uprawnienia.

  • Jeśli utworzono skojarzony punkt końcowy z tożsamością przypisaną przez użytkownika, tożsamość zarządzana użytkownika musi mieć uprawnienie Czytelnik danych obiektu blob usługi Storage na koncie magazynu dla obszaru roboczego oraz uprawnienie AcrPull w usłudze Azure Container Registry (ACR) dla obszaru roboczego. Upewnij się, że tożsamość przypisana przez użytkownika ma odpowiednie uprawnienia.

Aby uzyskać więcej informacji, zobacz Błąd autoryzacji usługi Container Registry.

Nieprawidłowa specyfikacja funkcji szablonu

Ten błąd występuje, gdy funkcja szablonu została niepoprawnie określona. Napraw zasady lub usuń przypisanie zasad w celu odblokowania. Komunikat o błędzie może zawierać nazwę przypisania zasad i definicję zasad, aby ułatwić debugowanie tego błędu, oraz artykuł Struktura definicji zasad platformy Azure, w którym omówiono porady, aby uniknąć błędów szablonów.

Nie można pobrać obrazu kontenera użytkownika

Możliwe, że 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 usłudze ACR obszaru roboczego.

Jeśli na przykład obraz jest testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest sprawdzany w repozytorium za pomocą az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output tablepolecenia .

Nie można pobrać modelu użytkownika

Możliwe, że 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:

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

Ostrzeżenie

Aby uzyskać informacje o modelu, należy określić wersję lub etykietę.

Możesz również sprawdzić, 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ć tego polecenia, aby sprawdzić, czy istnieje:

    az storage blob exists --account-name foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`
    
  • Jeśli obiekt blob jest obecny, możesz użyć tego polecenia, aby uzyskać dzienniki 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ą nie jest obsługiwany

Ten błąd występuje, gdy próbujesz wdrożyć model MLflow z podejściem wdrażania bez kodu w połączeniu ze starszą metodą izolacji sieciowej dla zarządzanych punktów końcowych online. Tej funkcji sieci prywatnej nie można używać w połączeniu z formatem modelu MLFlow, jeśli używasz starszej metody izolacji sieciowej. Jeśli musisz wdrożyć model MLflow z podejściem wdrażania bez kodu, spróbuj użyć zarządzanej sieci wirtualnej 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, ustawimy wartości domyślne podczas dołączania zasobów obliczeniowych do obszaru roboczego usługi Azure Machine Edukacja. Limity można sprawdzić w witrynie Azure Portal lub za pomocą az ml compute show polecenia .

azureml-fe nie jest gotowy

Składnik frontonu (azureml-fe), który kieruje przychodzące żądania wnioskowania do wdrożonych usług automatycznie skaluje się w razie potrzeby. Jest on instalowany podczas instalacji rozszerzenia k8s.

Ten składnik powinien być w dobrej kondycji w klastrze, co najmniej jednej repliki w dobrej kondycji. Ten komunikat o błędzie jest wyświetlany, jeśli nie jest dostępny po wyzwoleniu punktu końcowego online platformy Kubernetes i utworzenia/żądania aktualizacji wdrożenia.

Sprawdź stan zasobnika i dzienniki, aby rozwiązać ten problem. Możesz również spróbować zaktualizować rozszerzenie k8s zainstalowane w klastrze.

BŁĄD: ResourceNotReady

Aby uruchomić score.py element udostępniony w ramach wdrożenia, platforma Azure tworzy kontener zawierający wszystkie zasoby, których score.py potrzebują, i uruchamia skrypt oceniania w tym kontenerze. Błąd w tym scenariuszu polega na tym, że ten kontener ulega awarii podczas działania, co oznacza, że ocenianie nie może się zdarzyć. Ten błąd występuje, gdy:

  • Wystąpił błąd w pliku score.py. Użyj get-logs polecenia , aby zdiagnozować typowe problemy:
    • Pakiet, który score.py próbuje zaimportować, nie jest uwzględniony w środowisku conda.
    • Błąd składniowy.
    • Błąd w metodzie init() .
  • Jeśli get-logs nie generuje żadnych dzienników, zwykle oznacza to, że uruchomienie kontenera nie powiodło się. Aby debugować ten problem, spróbuj wdrożyć go lokalnie .
  • Sondy gotowości lub aktualności nie są poprawnie skonfigurowane.
  • Inicjowanie kontenera trwa zbyt długo, dzięki czemu sonda gotowości lub aktualności kończy się niepowodzeniem poza progiem niepowodzenia. W takim przypadku dostosuj ustawienia sondy, aby umożliwić dłuższy czas inicjowania kontenera. Możesz też wypróbować większą jednostkę SKU maszyny wirtualnej wśród obsługiwanych jednostek SKU maszyn wirtualnych, co przyspiesza inicjowanie.
  • W środowisku skonfigurowanym kontenera występuje błąd, taki jak brakująca zależność.
  • Po wystąpieniu błędu TypeError: register() takes 3 positional arguments but 4 were given sprawdź zależność między platformą Flask w wersji 2 i azureml-inference-server-http. Aby uzyskać więcej informacji, zobacz Często zadawane pytania dotyczące wnioskowania serwera HTTP.

BŁĄD: ResourceNotFound

Poniższa lista jest przyczyną wystąpienia tego błędu tylko w przypadku korzystania z zarządzanego punktu końcowego online lub punktu końcowego online platformy Kubernetes:

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 ten błąd można zobaczyć, jeśli konto magazynu zostało odwołane, ale nie można go znaleźć w ścieżce, w której została określona. Pamiętaj, aby dokładnie sprawdzić zasoby, które mogły zostać dostarczone przez dokładną ścieżkę lub pisownię ich nazw.

Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z błędami nie znaleziono zasobu.

Błąd autoryzacji rejestru kontenerów

Ten błąd występuje, gdy do wdrożenia został dostarczony obraz należący do prywatnego lub innego niedostępnego rejestru kontenerów. Obecnie nasze interfejsy API 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. Udziel roli rejestru acrPull prywatnego tożsamości systemowej punktu końcowego online.
  2. W definicji środowiska określ adres obrazu prywatnego i instrukcję, aby nie modyfikować (kompilować) obrazu.

Jeśli ograniczenie ryzyka powiedzie się, obraz nie wymaga utworzenia, a końcowy adres obrazu jest podanym adresem obrazu. W czasie wdrażania tożsamość systemu punktu końcowego online pobiera obraz z rejestru prywatnego.

Aby uzyskać więcej informacji diagnostycznych, zobacz How To Use the Workspace Diagnostic API (Jak używać interfejsu API diagnostyki obszaru roboczego).

BŁĄD: OperationCanceled

Poniższa lista jest przyczyną wystąpienia tego błędu podczas korzystania z zarządzanego punktu końcowego online lub punktu końcowego online platformy Kubernetes:

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 operacja została zastąpiona przez inną operację, która ma wyższy priorytet.

Ponów próbę wykonania operacji bez anulowania.

Operacja anulowana oczekiwanie na potwierdzenie blokady

Operacje platformy Azure mają krótki okres oczekiwania po przesłaniu, podczas którego pobierają blokadę, aby upewnić się, że nie napotkamy 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, że otrzymała blokadę, aby kontynuować. Może to oznaczać, że zostało przesłane podobne żądanie zbyt szybko po początkowym żądaniu.

Ponawianie próby wykonania operacji po kilku sekundach do minuty może pozwolić na jego wykonanie bez anulowania.

BŁĄD: SecretsInjectionError

Pobieranie wpisów tajnych i iniekcja podczas tworzenia wdrożenia online używa tożsamości skojarzonej z punktem końcowym online do pobierania wpisów tajnych z połączeń obszaru roboczego i/lub magazynów kluczy. Ten błąd występuje, gdy:

  • Tożsamość punktu końcowego nie ma uprawnień RBAC platformy Azure do odczytywania wpisów tajnych z połączeń obszaru roboczego i/lub magazynów kluczy, mimo że wpisy tajne zostały określone przez definicję wdrożenia jako odwołania (mapowane na zmienne środowiskowe). Pamiętaj, że 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 i/lub magazynach kluczy.

Aby uzyskać więcej informacji, zobacz Wstrzykiwanie wpisów tajnych w punktach końcowych online (wersja zapoznawcza) i Uzyskiwanie dostępu do wpisów tajnych z wdrożenia online przy użyciu iniekcji wpisu tajnego (wersja zapoznawcza).

BŁĄD: InternalServerError

Chociaż robimy wszystko, co w naszej mocy, aby zapewnić stabilną i niezawodną usługę, czasami rzeczy nie idą zgodnie z planem. Jeśli wystąpi ten błąd, oznacza to, że coś nie jest tuż po naszej stronie i musimy go naprawić. Prześlij bilet pomocy technicznej klienta ze wszystkimi powiązanymi informacjami i możemy rozwiązać ten problem.

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

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

Błędy dotyczące crashloopbackoff:

Błędy dotyczące skryptu oceniania:

Inne:

BŁĄD: ACRSecretError

Poniższa lista jest przyczyną wystąpienia tego błędu podczas tworzenia/aktualizowania wdrożeń online platformy Kubernetes:

  • Przypisanie roli nie zostało ukończone. W takim przypadku zaczekaj kilka sekund i spróbuj ponownie później.
  • Rozszerzenie Azure ARC (dla klastra Kubernetes usługi Azure Arc) lub usługi Azure Machine Edukacja (dla usługi AKS) nie jest poprawnie zainstalowane ani skonfigurowane. Spróbuj sprawdzić konfigurację i stan rozszerzenia azure ARC lub Azure Machine Edukacja.
  • Klaster Kubernetes ma nieprawidłową konfigurację sieci, sprawdź serwer proxy, zasady sieciowe lub certyfikat.
    • Jeśli używasz prywatnego klastra usługi AKS, musisz skonfigurować prywatne punkty końcowe dla usługi ACR, konta magazynu, obszaru roboczego w sieci wirtualnej usługi AKS.
  • Upewnij się, że wersja rozszerzenia azure Machine Edukacja jest nowsza niż wersja 1.1.25.

BŁĄD: TokenRefreshFailed

Ten błąd jest spowodowany tym, że rozszerzenie nie może pobrać poświadczeń podmiotu zabezpieczeń z platformy Azure, ponieważ tożsamość klastra Kubernetes nie jest poprawnie ustawiona. Zainstaluj ponownie rozszerzenie usługi Azure Machine Edukacja i spróbuj ponownie.

BŁĄD: GetAADTokenFailed

Ten błąd jest spowodowany tym, że klaster Kubernetes zażąda tokenu usługi Azure AD zakończył się niepowodzeniem lub upłynął limit czasu, sprawdź dostępność sieci, a następnie spróbuj ponownie.

  • Aby sprawdzić wychodzący serwer proxy, możesz postępować zgodnie z instrukcjami Konfigurowanie wymaganego ruchu sieciowego, aby upewnić się, że klaster może nawiązać połączenie z obszarem roboczym.
  • Adres URL punktu końcowego obszaru roboczego można znaleźć w punkcie końcowym online CRD w klastrze.

Jeśli obszar roboczy jest prywatnym obszarem roboczym, który wyłączył dostęp do sieci publicznej, klaster Kubernetes powinien komunikować się tylko z tym prywatnym obszarem roboczym za pośrednictwem łącza prywatnego.

BŁĄD: ACRAuthenticationChallengeFailed

Ten błąd jest spowodowany tym, że klaster Kubernetes nie może nawiązać połączenia z usługą ACR obszaru roboczego w celu wykonania zadania uwierzytelniania. Sprawdź sieć, zwłaszcza dostęp do sieci publicznej usługi ACR, 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 jest spowodowany niepowodzeniem wymiany tokenu ACR klastra Kubernetes, ponieważ token usługi Azure AD nie jest jeszcze autoryzowany. Ponieważ przypisanie roli zajmuje trochę czasu, więc możesz poczekać chwilę, a następnie spróbować ponownie.

Ten błąd może być również spowodowany zbyt dużą liczbą żądań do usługi ACR w tym czasie, powinien to być błąd przejściowy, 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 wykonać następujące czynności:

BŁĄD: ImagePullLoopBackOff

Przyczyną wystąpienia tego błędu podczas tworzenia/aktualizowania wdrożeń online platformy Kubernetes jest to, że nie można pobrać obrazów z rejestru kontenerów, co powoduje niepowodzenie ściągania obrazów.

W takim przypadku można sprawdzić zasady sieci klastra i rejestr kontenerów obszaru roboczego, jeśli klaster może ściągnąć obraz z rejestru kontenerów.

BŁĄD: DeploymentCrashLoopBackOff

Przyczyną wystąpienia tego błędu podczas tworzenia/aktualizowania wdrożeń online platformy Kubernetes jest zainicjowanie kontenera użytkownika. Istnieją dwa możliwe przyczyny tego błędu:

  • Skrypt score.py użytkownika zawiera błąd składniowy lub błąd importowania, a następnie zgłasza wyjątki podczas inicjowania.
  • Albo zasobnik wdrożenia wymaga więcej pamięci niż limit.

Aby wyeliminować ten błąd, najpierw możesz sprawdzić 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 zasobów/typu wystąpienia.

BŁĄD: KubernetesCrashLoopBackOff

Poniższa lista jest przyczyną wystąpienia tego błędu podczas tworzenia/aktualizowania punktów końcowych/wdrożeń online platformy Kubernetes:

  • Co najmniej jeden zasobnik zablokowany w stanie CrashLoopBackoff, możesz sprawdzić, czy dziennik wdrażania istnieje, i sprawdzić, czy w dzienniku znajdują się komunikaty o błędach.
  • Wystąpił błąd i score.py kontener uległ awarii po zainicjowaniu kodu oceny, możesz postępować zgodnie z instrukcjami ERROR: ResourceNotReady .
  • Proces oceniania wymaga więcej pamięci, że limit konfiguracji wdrożenia jest niewystarczający. Możesz spróbować zaktualizować wdrożenie przy użyciu większego limitu pamięci.

BŁĄD: NamespaceNotFound

Przyczyną wystąpienia tego błędu podczas tworzenia/aktualizowania punktów końcowych online platformy Kubernetes jest to, że używana przestrzeń nazw usługi Kubernetes jest niedostępna w klastrze.

Środowisko obliczeniowe kubernetes można sprawdzić w portalu obszaru roboczego i sprawdzić przestrzeń nazw w klastrze Kubernetes. Jeśli przestrzeń nazw nie jest dostępna, możesz odłączyć starsze zasoby obliczeniowe i dołączyć je ponownie, aby utworzyć nową, określając przestrzeń nazw, która już istnieje w klastrze.

BŁĄD: UserScriptInitFailed

Przyczyną wystąpienia tego błędu podczas tworzenia/aktualizowania wdrożeń online platformy Kubernetes jest to, że funkcja init w przekazanym score.py pliku zgłosiła wyjątek.

Możesz sprawdzić dzienniki wdrażania, aby wyświetlić szczegółowy komunikat o wyjątku i naprawić wyjątek.

BŁĄD: UserScriptImportError

Przyczyną wystąpienia tego błędu podczas tworzenia/aktualizowania wdrożeń online platformy Kubernetes jest to, że score.py przekazany plik zaimportował niedostępne pakiety.

Możesz sprawdzić dzienniki wdrażania, aby wyświetlić szczegółowy komunikat o wyjątku i naprawić wyjątek.

BŁĄD: UserScriptFunctionNotFound

Przyczyną tego błędu może wystąpić podczas tworzenia/aktualizowania wdrożeń online platformy Kubernetes jest to, że score.py przekazany plik nie ma funkcji o nazwie init() lub run(). Możesz sprawdzić kod i dodać funkcję.

BŁĄD: EndpointNotFound

Przyczyną tego błędu może wystąpić podczas tworzenia/aktualizowania wdrożeń online platformy Kubernetes, ponieważ system nie może znaleźć zasobu punktu końcowego dla wdrożenia w klastrze. Wdrożenie należy utworzyć w istniejącym punkcie końcowym lub najpierw utworzyć ten punkt końcowy w klastrze.

BŁĄD: EndpointAlreadyExists

Przyczyną wystąpienia tego błędu podczas tworzenia punktu końcowego online platformy Kubernetes jest to, że tworzenie punktu końcowego już istnieje w klastrze.

Nazwa punktu końcowego powinna być unikatowa dla obszaru roboczego i klastra, dlatego w tym przypadku należy utworzyć punkt końcowy o innej nazwie.

BŁĄD: OcenianieFe w złej kondycji

Przyczyną tego błędu może wystąpić podczas tworzenia/aktualizowania punktu końcowego/wdrożenia w trybie online kubernetes jest to, że usługa systemowa uruchomiona w klastrze nie została znaleziona lub jest w złej kondycji.

Aby rozwiązać ten problem, możesz ponownie zainstalować lub zaktualizować rozszerzenie usługi Azure Machine Edukacja w klastrze.

BŁĄD: ValidateScoringFailed

Przyczyną tego błędu może wystąpić podczas tworzenia/aktualizowania wdrożeń online platformy Kubernetes jest to, że walidacja adresu URL żądania oceniania nie powiodła się podczas przetwarzania wdrożenia modelu.

W takim przypadku możesz najpierw sprawdzić adres URL punktu końcowego, a następnie spróbować ponownie wdrożyć wdrożenie.

BŁĄD: InvalidDeploymentSpec

Przyczyną wystąpienia tego błędu podczas tworzenia/aktualizowania wdrożeń online platformy Kubernetes jest to, że specyfikacja wdrożenia jest nieprawidłowa.

W takim przypadku możesz sprawdzić komunikat o błędzie.

  • Upewnij się, że element instance count jest prawidłowy.
  • Jeśli włączono automatyczne skalowanie, upewnij się, że minimum instance count wartości i maximum instance count są prawidłowe.

BŁĄD: PodUnschedulable

Poniższa lista jest przyczyną wystąpienia tego błędu podczas tworzenia/aktualizowania punktów końcowych/wdrożeń online platformy Kubernetes:

  • Nie można zaplanować zasobnika do węzłów z powodu niewystarczającej ilości zasobów w klastrze.
  • Brak dopasowania węzła koligacji/selektora węzłów.

Aby wyeliminować ten błąd, możesz wykonać następujące kroki:

  • Sprawdź definicję node selector użytych instance type węzłów klastra i node label konfigurację.
  • Sprawdź instance type rozmiar jednostki SKU węzła dla klastra usługi AKS lub zasobu węzła dla klastra Arc-Kubernetes.
    • Jeśli klaster jest niedostatecznie zasób, można zmniejszyć wymaganie dotyczące zasobu typu wystąpienia lub użyć innego typu wystąpienia z mniejszym wymaganym zasobem.
  • 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

Przyczyną wystąpienia tego błędu podczas tworzenia/aktualizowania wdrożenia online jest niewystarczający limit pamięci dla wdrożenia. Limit pamięci można ustawić na większą wartość lub użyć większego typu wystąpienia, aby wyeliminować ten błąd.

BŁĄD: WnioskowanieClientCallFailed

Przyczyną tego błędu może wystąpić podczas tworzenia/aktualizowania punktów końcowych/wdrożeń online platformy Kubernetes, ponieważ rozszerzenie k8s klastra Kubernetes nie jest możliwe do nawiązania połączenia.

W takim przypadku możesz odłączyć, a następnie ponownie dołączyć zasoby obliczeniowe.

Uwaga

Aby rozwiązać problemy z błędami przez ponowne dołączanie, upewnij się, że ponownie dołączono dokładnie tę samą konfigurację co wcześniej odłączone zasoby obliczeniowe, takie jak ta sama nazwa obliczeniowa i przestrzeń nazw, w przeciwnym razie mogą wystąpić inne błędy.

Jeśli nadal nie działa, możesz poprosić administratora, który może uzyskać dostęp do klastra, aby kubectl get po -n azureml sprawdzić, czy zasobniki serwera przekaźnika są uruchomione.

Problemy z skalowaniem automatycznym

Jeśli masz problemy z skalowaniem automatycznym, zobacz Rozwiązywanie problemów z autoskalowaniem platformy Azure.

W przypadku punktu końcowego online platformy Kubernetes istnieje router wnioskowania usługi Azure Machine Edukacja, który jest składnikiem frontonu do obsługi skalowania automatycznego dla wszystkich wdrożeń modelu w klastrze Kubernetes, więcej informacji można znaleźć w artykule Autoskalowanie routingu wnioskowania platformy Kubernetes

Typowe błędy użycia modelu

Poniższa lista zawiera typowe błędy użycia modelu wynikające ze stanu operacji punktu końcowego invoke .

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 sieciowe", aby zrozumieć bieżące użycie przepustowości. Aby uzyskać więcej informacji, zobacz Monitorowanie zarządzanych punktów końcowych online.
  • Istnieją dwa przyczepy odpowiedzi zwracane, jeśli limit przepustowości został wymuszony:
    • ms-azureml-bandwidth-request-delay-ms: czas opóźnienia w milisekundach, który trwał na transfer strumienia żądania.
    • ms-azureml-bandwidth-response-delay-ms: czas opóźnienia w milisekundach, który trwał na transfer strumienia odpowiedzi.

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. Są to szczegółowe informacje na temat sposobu mapowania błędów wywołania punktu końcowego i przewidywania 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 podczas korzystania z zarządzanych punktów końcowych online z żądaniami REST:

Kod stanu Fraza przyczyny Dlaczego ten kod może zostać zwrócony
200 OK Model został wykonany pomyślnie w ramach ograniczenia 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 Pojęcie uwierzytelniania punktu końcowego i sposób uwierzytelniania dla punktu końcowego.
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. Możesz też sprawdzić nagłówki ms-azureml-model-error-statuscode odpowiedzi i ms-azureml-model-error-reason uzyskać więcej informacji. Jeśli błąd 424 jest dostarczany z niepowodzeniem sondy aktualności lub gotowości, rozważ dostosowanie ustawień sondy w celu umożliwienia dłuższego czasu na sondowanie aktualności lub gotowości kontenera.
429 Zbyt wiele oczekujących żądań Model jest obecnie coraz więcej żądań, niż może obsłużyć. Usługa Azure Machine Edukacja zaimplementowała system, który umożliwia przetwarzanie maksymalnie równoległe 2 * max_concurrent_requests_per_instance * instance_count requests w danym momencie w celu zagwarantowania bezproblemowej operacji. Inne żądania, które przekraczają 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. Ponadto, jak opisano w definicji YAML dla żądania Ustawienia ważne jest, aby upewnić się, że zmienna środowiskowa WORKER_COUNT jest poprawnie przekazywana.

Jeśli używasz skalowania automatycznego i otrzymujesz ten błąd, oznacza to, że model otrzymuje żądania szybciej niż system może skalować w górę. W takiej sytuacji rozważ ponowne wysyłanie żądań z wykładniczym wycofywaniem, aby dać systemowi czas potrzebny do dostosowania. Można również zwiększyć liczbę wystąpień przy użyciu kodu w celu obliczenia liczby wystąpień. Te kroki, w połączeniu z ustawieniem skalowania automatycznego, pomagają upewnić się, że model jest gotowy do obsługi napływu żądań.
429 Ograniczenie szybkości Liczba żądań na sekundę osiągnęła limity zarządzanych punktów końcowych online.
500 Wewnętrzny błąd serwera. Infrastruktura aprowizowania usługi Azure Machine Edukacja 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 podczas korzystania z punktów końcowych online platformy Kubernetes z żądaniami REST:

Kod stanu Fraza przyczyny Dlaczego ten kod może zostać zwrócony
409 Błąd konfliktu Gdy operacja jest już w toku, każda nowa operacja w tym samym punkcie końcowym online odpowiada z błędem konfliktu 409. Jeśli na przykład operacja tworzenia lub aktualizowania punktu końcowego online jest w toku, a po wyzwoleniu nowej operacji Usuwania zgłasza błąd.
502 Zgłosił wyjątek lub uległ awarii w run() metodzie pliku score.py Jeśli wystąpi błąd w score.pypliku , na przykład zaimportowany pakiet nie istnieje w środowisku conda, błąd składni lub błąd w metodzie init() . Możesz wykonać czynności opisane tutaj , aby debugować plik.
503 Odbieranie dużych skoków liczby żądań na sekundę Autoskalator został zaprojektowany tak, aby obsługiwał stopniowe zmiany obciążenia. Jeśli otrzymujesz duże skoki liczby żądań na sekundę, klienci mogą otrzymać 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. Aby zapobiec kodom stanu 503, możesz wykonać czynności opisane tutaj .
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, możesz wykonać czynności opisane tutaj , aby debugować plik score.py. Kod może być w stanie nieodpowiadczym lub nieskończonej pętli.
500 Wewnętrzny błąd serwera. Infrastruktura aprowizowania usługi Azure Machine Edukacja kończy się niepowodzeniem.

Jak zapobiegać kodom stanu 503

Wdrożenia online platformy Kubernetes obsługują skalowanie automatyczne, które umożliwia dodawanie replik do obsługi dodatkowego obciążenia. Więcej informacji można znaleźć w artykule Azure Machine Edukacja router wnioskowania. Decyzje dotyczące skalowania w górę/w dół są oparte na wykorzystaniu bieżących replik kontenerów.

Istnieją dwie rzeczy, które mogą pomóc zapobiec kodom stanu 503:

Napiwek

Te dwa podejścia mogą być używane pojedynczo lub w połączeniu.

  • Zmień poziom wykorzystania, na którym autoskalowanie tworzy nowe repliki. Wartość docelową wykorzystania można dostosować, ustawiając autoscale_target_utilization wartość na niższą.

    Ważne

    Ta zmiana nie powoduje szybszego tworzenia replik. Zamiast tego są one tworzone przy niższym progu wykorzystania. Zamiast czekać, aż usługa zostanie wykorzystana w 70%, zmiana wartości na 30% powoduje utworzenie replik w przypadku wystąpienia 30% użycia.

    Jeśli punkt końcowy online platformy Kubernetes korzysta już z bieżących maksymalnych replik i nadal widzisz kody stanu 503, zwiększ autoscale_max_replicas wartość, aby zwiększyć maksymalną liczbę replik.

  • Zmień minimalną liczbę replik. Zwiększenie minimalnej liczby replik zapewnia większą pulę do obsługi przychodzących skoków.

    Aby zwiększyć liczbę wystąpień, można obliczyć wymagane repliki zgodnie z tymi kodami.

    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ż nowe minimalne repliki mogą obsłużyć, może zostać ponownie odebrane 503. Na przykład w miarę wzrostu ruchu do punktu końcowego może być konieczne zwiększenie minimalnej liczby replik.

Jak obliczyć liczbę wystąpień

Aby zwiększyć liczbę wystąpień, można obliczyć wymagane repliki przy użyciu następującego kodu:

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)

Zablokowane przez zasady MECHANIZMU CORS

Punkty końcowe online (wersja 2) obecnie nie obsługują natywnie współużytkowania zasobów między źródłami (CORS). Jeśli aplikacja internetowa próbuje wywołać punkt końcowy bez odpowiedniej obsługi żądań wstępnych CORS, zostanie wyświetlony 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.

Zalecamy używanie usługi Azure Functions, bramy aplikacja systemu Azure lub dowolnej usługi jako warstwy tymczasowej do obsługi żądań wstępnych CORS.

Typowe problemy z izolacją sieci

Tworzenie punktu końcowego online kończy się niepowodzeniem z komunikatem V1LegacyMode == true

Obszar roboczy usługi Azure Machine Edukacja można skonfigurować dla v1_legacy_modeprogramu , co wyłącza interfejsy API w wersji 2. Zarządzane punkty końcowe online to funkcja platformy interfejsu API w wersji 2 i nie będzie działać, jeśli v1_legacy_mode jest włączona dla obszaru roboczego.

Ważne

Przed wyłączeniem v1_legacy_modeprogramu sprawdź zespół ds. zabezpieczeń sieci. Być może został on włączony przez zespół ds. zabezpieczeń sieci z jakiegoś powodu.

Aby uzyskać informacje na temat wyłączania v1_legacy_modeprogramu , zobacz Izolacja sieciowa w wersji 2.

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ł sieci usługi Azure Key Vault dla obszaru roboczego. Zastąp <keyvault-name> ciąg nazwą magazynu kluczy:

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

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

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

Jeśli wartość bypass nie AzureServicesjest równa , skorzystaj ze wskazówek w temacie Konfigurowanie ustawień sieci magazynu kluczy, aby ustawić ją na AzureServices.

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

  1. Sprawdź, czy flaga egress-public-network-access jest wyłączona 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> ciąg nazwą usługi Azure Container Registry dla obszaru roboczego:

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

    W dokumencie odpowiedzi sprawdź, czy status pole jest ustawione na Approved. Jeśli nie zostanie zatwierdzona, użyj następującego polecenia, aby go zatwierdzić. Zastąp <private-endpoint-name> ciąg nazwą zwróconą z poprzedniego polecenia:

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

Nie można rozpoznać punktu końcowego oceniania

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

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

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

    Odpowiedź zawiera adres. Ten adres 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 (nazwa domeny), która została określona w klastrze Kubernetes. Jeśli jest to punkt końcowy HTTP, adres IP będzie zawarty w identyfikatorze URI punktu końcowego, który można uzyskać bezpośrednio w interfejsie użytkownika programu Studio. Więcej sposobów uzyskiwania adresu IP punktu końcowego można znaleźć w artykule Secure Kubernetes online endpoint (Zabezpieczanie punktu końcowego usługi Kubernetes w trybie online).

  3. Jeśli nazwa hosta nie jest rozpoznawana przez nslookup polecenie :

    W przypadku zarządzanego punktu końcowego online,

    1. Sprawdź, czy rekord A istnieje w prywatnej strefie DNS dla sieci wirtualnej.

      Aby sprawdzić rekordy, użyj następującego polecenia:

      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ść wnioskowania, usuń prywatny punkt końcowy dla 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 jest skonfigurowany przy użyciu niestandardowego serwera DNS Jak używać obszaru roboczego z niestandardowym serwerem DNS, użyj następującego polecenia, aby sprawdzić, czy rozpoznawanie działa poprawnie z niestandardowego systemu DNS.

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

    W przypadku punktu końcowego online platformy Kubernetes,

    1. Sprawdź konfigurację DNS w klastrze Kubernetes.

    2. Ponadto możesz sprawdzić, czy plik azureml-fe działa zgodnie z oczekiwaniami, użyj następującego polecenia:

      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"
      

      W przypadku protokołu HTTP użyj polecenia

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

    Jeśli protokoły HTTP curl kończą się niepowodzeniem (np. przekroczeniem limitu czasu), ale protokół HTTP działa, sprawdź, czy certyfikat jest prawidłowy.

    Jeśli nie można rozpoznać rekordu A, sprawdź, czy rozpoznawanie działa z usługi Azure DNS(168.63.129.16).

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

    Jeśli to się powiedzie, możesz rozwiązać problemy z usługą przesyłania dalej warunkowego dla łącza prywatnego w niestandardowym systemie DNS.

Nie można ocenić wdrożeń online

  1. Użyj następującego polecenia, aby sprawdzić, czy wdrożenie zostało pomyślnie wdrożone:

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

    Jeśli wdrożenie zakończy się pomyślnie, wartość parametru state będzie wynosić Succeeded.

  2. Jeśli wdrożenie zakończyło się pomyślnie, użyj następującego polecenia, aby sprawdzić, czy ruch jest przypisany do wdrożenia. Zastąp <endpointname> ciąg nazwą punktu końcowego:

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

    Napiwek

    Ten krok nie jest wymagany, jeśli używasz nagłówka azureml-model-deployment w żądaniu do kierowania tego wdrożenia.

    Odpowiedź z tego polecenia powinna zawierać wartość procentową ruchu przypisanego do wdrożeń.

  3. Jeśli przypisania ruchu (lub nagłówek wdrożenia) są ustawione poprawnie, użyj następującego polecenia, aby pobrać dzienniki dla punktu końcowego. Zastąp <endpointname> ciąg nazwą punktu końcowego i <deploymentname> wdrożeniem:

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

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

Rozwiązywanie problemów z serwerem wnioskowania

W tej sekcji udostępniamy podstawowe porady dotyczące rozwiązywania problemów z serwerem HTTP wnioskowania usługi Azure Machine Edukacja.

Podstawowe kroki

Podstawowe kroki rozwiązywania problemów to:

  1. Zbierz informacje o wersji dla środowiska języka Python.
  2. Upewnij się, że wersja pakietu azureml-inference-server-http języka Python określona w pliku środowiska jest zgodna z wersją serwera HTTP wnioskowania usługi AzureML wyświetlaną w dzienniku uruchamiania. Czasami narzędzie do rozpoznawania zależności pip prowadzi do nieoczekiwanych wersji zainstalowanych pakietów.
  3. Jeśli określisz platformę Flask (i jej zależności) w środowisku, usuń je. Zależności obejmują Flask, , Jinja2, itsdangerous, Werkzeug, MarkupSafe, i click. Platforma Flask jest wymieniona jako zależność w pakiecie serwera i najlepiej pozwolić serwerowi go zainstalować. Dzięki temu, gdy serwer obsługuje nowe wersje platformy Flask, otrzymasz je automatycznie.

Wersja serwera

Pakiet azureml-inference-server-http serwera jest publikowany w interfejsie PyPI. Nasz dziennik zmian i wszystkie poprzednie wersje można znaleźć na naszej stronie PyPI. Zaktualizuj do najnowszej wersji, jeśli używasz starszej wersji.

  • 0.4.x: wersja dołączona do obrazów szkoleniowych ≤ 20220601 i w programie azureml-defaults>=1.34,<=1.43. 0.4.13 jest ostatnią stabilną wersją. Jeśli używasz serwera przed wersją 0.4.11, mogą wystąpić problemy z zależnościami platformy Flask, takie jak nie można zaimportować nazwy Markup z programu jinja2. Zalecamy uaktualnienie do 0.4.13 lub 0.8.x (najnowszą wersję), jeśli jest to możliwe.
  • 0.6.x: wersja wstępnie zainstalowana w wnioskowaniu obrazów ≤ 20220516. Najnowsza stabilna wersja to 0.6.1.
  • 0.7.x: pierwsza wersja, która obsługuje platformę Flask 2. Najnowsza stabilna wersja to 0.7.7.
  • 0.8.x: Format dziennika uległ zmianie, a obsługa języka Python 3.6 spadła.

Zależności pakietów

Najbardziej odpowiednie pakiety dla serwera azureml-inference-server-http to następujące pakiety:

  • Kolby
  • opencensus-ext-azure
  • schemat wnioskowania

W przypadku określenia azureml-defaults w środowisku azureml-inference-server-http języka Python pakiet jest zależny i zostanie zainstalowany automatycznie.

Napiwek

Jeśli używasz zestawu Python SDK w wersji 1 i nie określasz azureml-defaults jawnie go w środowisku języka Python, zestaw SDK może dodać pakiet. Jednak zablokuje go do wersji, w ramach których jest włączony zestaw SDK. Jeśli na przykład wersja zestawu SDK to 1.38.0, zostanie dodana azureml-defaults==1.38.0 do wymagań pip środowiska.

Często zadawane pytania

1. Wystąpił następujący błąd podczas uruchamiania serwera:


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

Platforma Flask 2 jest zainstalowana w środowisku języka Python, ale jest uruchomiona wersjaazureml-inference-server-http, która nie obsługuje platformy Flask 2. Obsługa platformy Flask 2 jest dodawana w systemie azureml-inference-server-http>=0.7.0, który jest również w systemie azureml-defaults>=1.44.

  • Jeśli nie używasz tego pakietu w obrazie platformy Docker usługi AzureML, użyj najnowszej azureml-inference-server-http wersji programu lub azureml-defaults.

  • Jeśli używasz tego pakietu z obrazem platformy Docker usługi AzureML, upewnij się, że używasz obrazu wbudowanego lub po lipcu 2022 r. Wersja obrazu jest dostępna w dziennikach kontenera. Powinno być możliwe znalezienie dziennika podobnego do następującego:

    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 | 
    

    Data kompilacji obrazu jest wyświetlana po "Materialization Build", który w powyższym przykładzie to 20220708, czyli 8 lipca 2022 r. Ten obraz jest zgodny z platformą Flask 2. Jeśli w dzienniku kontenera nie widzisz baneru takiego jak ten, obraz jest nieaktualny i powinien zostać zaktualizowany. Jeśli używasz obrazu CUDA i nie możesz znaleźć nowszego obrazu, sprawdź, czy obraz jest przestarzały w usłudze AzureML-Containers. Jeśli tak jest, powinno być możliwe znalezienie zamienników.

  • Jeśli używasz serwera z punktem końcowym online, możesz również znaleźć dzienniki w obszarze "Dzienniki wdrażania" na stronie punktu końcowego online w usłudze Azure Machine Edukacja Studio. Jeśli wdrożysz za pomocą zestawu SDK w wersji 1 i nie określisz jawnie obrazu w konfiguracji wdrożenia, domyślnie będzie używana wersja openmpi4.1.0-ubuntu20.04 zgodna z lokalnym zestawem narzędzi zestawu SDK, który może nie być najnowszą wersją obrazu. Na przykład zestaw SDK 1.43 będzie domyślnie używać openmpi4.1.0-ubuntu20.04:20220616elementu , który jest niezgodny. Upewnij się, że używasz najnowszego zestawu SDK do wdrożenia.

  • Jeśli z jakiegoś powodu nie możesz zaktualizować obrazu, możesz tymczasowo uniknąć problemu przez przypięcie azureml-defaults==1.43 lub azureml-inference-server-http~=0.4.13, co spowoduje zainstalowanie starszego serwera wersji za pomocą Flask 1.0.xpolecenia .

2. Napotkałem moduły ImportError lub ModuleNotFoundError w modułach opencensus, jinja2, MarkupSafelub click podczas uruchamiania, podobnie jak w przypadku następującego komunikatu:

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

Starsze wersje (<= 0.4.10) serwera nie przypiąły zależności platformy Flask do zgodnych wersji. Ten problem został rozwiązany w najnowszej wersji serwera.

Następne kroki