Freigeben über

Problembehandlung für die Bereitstellung und Bewertung von Onlineendpunkten

  • Artikel

GILT FÜR:Azure CLI ML-Erweiterung v2 (aktuell)Python SDK azure-ai-ml v2 (aktuell)

Dieser Artikel beschreibt, wie Sie häufige Probleme bei der Bereitstellung und Bewertung von Azure Machine Learning-Onlineendpunkten behandeln und auflösen.

Die Dokumentstruktur spiegelt die Art und Weise wider, wie Sie die Problembehandlung angehen sollten:

  1. Verwenden Sie die lokale Bereitstellung, um Ihre Modelle vor der Bereitstellung in der Cloud zu testen und zu debuggen.
  2. Verwenden Sie Containerprotokolle zum Debuggen von Problemen.
  3. Machen Sie sich mit häufigen Bereitstellungsfehlern, die ggf. auftreten können, und deren Behebung vertraut.

Der Abschnitt HTTP-Statuscodes erläutert, wie Aufruf- und Vorhersagefehler den HTTP-Statuscodes zugeordnet werden, wenn Sie Endpunkte mit REST-Anforderungen bewerten.

Voraussetzungen

Anforderungsablaufverfolgung

Es gibt zwei unterstützte Ablaufverfolgungsheader:

  • x-request-id ist für die Serverablaufverfolgung reserviert. Azure Machine Learning überschreibt diesen Header, um sicherzustellen, dass es sich um eine gültige GUID handelt. Wenn Sie ein Supportticket für eine fehlgeschlagene Anforderung erstellen, fügen Sie die ID der fehlgeschlagenen Anforderung an, um die Bearbeitung zu beschleunigen. Alternativ können Sie den Namen der Region und den Endpunktnamen angeben.

  • x-ms-client-request-id ist für Szenarien mit Clientablaufverfolgung verfügbar. Dieser Header akzeptiert nur alphanumerische Zeichen, Bindestriche und Unterstriche, und er wird auf ein Maximum von 40 Zeichen abgeschnitten.

Lokale Bereitstellung

Lokale Bereitstellung bedeutet, ein Modell in einer lokalen Docker-Umgebung bereitzustellen. Die lokale Bereitstellung unterstützt das Erstellen, Aktualisieren und Löschen eines lokalen Endpunkts und ermöglicht Ihnen, Protokolle vom Endpunkt aufzurufen und abzurufen. Die lokale Bereitstellung ist für Test- und Debugvorgänge vor der Bereitstellung in der Cloud nützlich.

Tipp

Sie können auch das Python-Paket von Azure Machine Learning für HTTP-Rückschlussserver verwenden, um Ihr Bewertungsskript lokal zu debuggen. Das Debuggen mit dem Rückschlussserver hilft beim Debuggen des Bewertungsskripts vor der Bereitstellung auf lokalen Endpunkten, sodass Sie beim Debuggen nicht von der Konfiguration der Bereitstellungscontainer abhängig sind.

Sie können lokal mit Azure CLI oder dem Python-SDK bereitstellen. Azure Machine Learning Studio unterstützt keine lokale Bereitstellung oder lokale Endpunkte.

Fügen Sie dem entsprechenden Befehl --local hinzu, um die lokale Bereitstellung zu verwenden.

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

Die folgenden Schritte treten während der lokalen Bereitstellung auf:

  1. Docker erstellt entweder ein neues Containerimage oder pullt ein vorhandenes Image aus dem lokalen Docker-Cache. Docker verwendet ein vorhandenes Image, wenn eines mit dem Umgebungsteil der Spezifikationsdatei übereinstimmt.
  2. Docker startet den neuen Container mit eingebundenen lokalen Artefakten, z. B. Modell- und Codedateien.

Weitere Informationen finden Sie unter Lokales Bereitstellen und Debuggen mithilfe eines lokalen Endpunkts.

Tipp

Sie können Visual Studio Code verwenden, um Ihre Endpunkte lokal zu testen und zu debuggen. Weitere Informationen finden Sie unter Lokales Debuggen von Onlineendpunkten in Visual Studio Code.

Abrufen von Containerprotokollen

Sie können keinen direkten Zugriff auf eine VM (einen virtuellen Computer) erhalten, auf der ein Modell bereitgestellt wird, aber Sie können Protokolle aus einigen Containern abrufen, die auf der VM ausgeführt werden. Die Menge der Informationen hängt vom Status der Bereitstellung ab. Wenn der angegebene Container ausgeführt wird, wird seine Konsolenausgabe angezeigt. Andernfalls erhalten Sie eine Meldung mit dem Hinweis, es später erneut zu versuchen.

Sie können Protokolle aus den folgenden Containertypen abrufen:

  • Das Konsolenprotokoll des Rückschlussservers enthält die Ausgabe von Druck- und Protokollierungsfunktionen aus Ihrem Bewertungsskriptcode score.py.
  • Speicherinitialisierungsprotokolle enthalten Informationen dazu, ob das Herunterladen der Code- und Modelldaten in den Container erfolgreich war. Der Container wird ausgeführt, bevor die Ausführung des Containers des Rückschlussservers gestartet wird.

Für Kubernetes-Onlineendpunkte können Administratoren direkt auf den Cluster zugreifen, in dem Sie das Modell bereitstellen und die Protokolle in Kubernetes überprüfen. Zum Beispiel:

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

Hinweis

Stellen Sie sicher, dass Sie bei Verwendung der Python-Protokollierung den richtigen Protokolliergrad, z. B. INFO, für die Nachrichten verwenden, die in Protokollen veröffentlicht werden sollen.

Anzeigen der Protokollausgabe aus Containern

Um die Protokollausgabe für einen Container anzuzeigen, verwenden Sie den folgenden Befehl:

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

Oder

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

Standardmäßig werden Protokolle per Pull vom Rückschlussserver abgerufen. Sie können Protokolle auch aus dem Speicherinitialisierungscontainer abrufen, indem Sie –-container storage-initializer übergeben.

Fügen Sie die Befehle --resource-group und --workspace-name hinzu, wenn Sie diese Parameter noch nicht über az configure festgelegt haben. Um Informationen zum Festlegen dieser Parameter anzuzeigen, oder wenn Sie zurzeit Werte festgelegt haben, führen Sie den folgenden Befehl aus:

az ml online-deployment get-logs -h

Um weitere Informationen anzuzeigen, fügen Sie --help oder --debug zu den Befehlen hinzu.

Häufige Bereitstellungsfehler

Der Bereitstellungsvorgangsstatus kann die folgenden häufigen Bereitstellungsfehler melden:

Wenn Sie eine Kubernetes-Onlinebereitstellung erstellen oder aktualisieren, lesen Sie auch Häufige Fehler spezifisch für Kubernetes-Bereitstellungen.

FEHLER: ImageBuildFailure

Dieser Fehler wird zurückgegeben, wenn die Docker-Imageumgebung erstellt wird. Sie können das Buildprotokoll auf weitere Informationen zum Fehler überprüfen. Das Buildprotokoll befindet sich im Standardspeicher für Ihren Azure Machine Learning-Arbeitsbereich.

Der genaue Speicherort wird möglicherweise als Teil des Fehlers zurückgegeben, z. B. "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

Die folgenden Abschnitte beschreiben häufige Fehlerszenarien beim Imagebuild:

Azure Container Registry-Autorisierungsfehler

Eine Fehlermeldung erwähnt "container registry authorization failure", wenn Sie mit den aktuellen Anmeldeinformationen nicht auf die Containerregistrierung zugreifen können. Die Desynchronisierung von Schlüsseln der Arbeitsbereichsressource kann diesen Fehler verursachen, und es dauert einige Zeit, bis die automatische Synchronisierung erfolgt. Sie können jedoch die Schlüsselsynchronisierung mit az ml workspace sync-keys manuell aufrufen, was den Autorisierungsfehler möglicherweise behebt.

Bei Containerregistrierungen, die sich hinter einem virtuellen Netzwerk befinden, kann dieser Fehler auch auftreten, wenn sie falsch eingerichtet wurden. Bestätigen Sie, dass das virtuelle Netzwerk ordnungsgemäß eingerichtet ist.

Compute für die Imageerstellung in einem privaten Arbeitsbereich mit virtuellem Netzwerk nicht festgelegt

Wenn die Fehlermeldung "failed to communicate with the workspace's container registry" erwähnt und Sie ein virtuelles Netzwerk verwenden und die Containerregistrierung des Arbeitsbereichs privat und mit einem privaten Endpunkt konfiguriert ist, müssen Sie im virtuellen Netzwerk der Container Registry erlauben, Images zu erstellen.

Timeout bei Imagebuilds

Zeitüberschreitungen bei der Imageerstellung sind häufig darauf zurückzuführen, dass ein Image zu groß ist, um die Erstellung innerhalb des Zeitfensters für die Bereitstellungserstellung abschließen zu können. Überprüfen Sie Ihre Protokolle der Imageerstellung an dem Speicherort, den der Fehler angibt. Die Protokolle werden an dem Punkt abgeschnitten, an dem das Timeout im Imagebuild aufgetreten ist.

Um dieses Problem aufzulösen, erstellen Sie Ihr Image separat, damit es während der Bereitstellungserstellung nur abgerufen werden muss. Überprüfen Sie auch die standardmäßigen Testeinstellungen, wenn Sie ImageBuild-Zeitüberschreitungen haben.

Generischer Fehler bei der Imageerstellung

Überprüfen das Buildprotokoll auf weitere Informationen zum Fehler. Wenn kein offensichtlicher Fehler im Buildprotokoll gefunden wird und die letzte Zeile Installing pip dependencies: ...working... lautet, könnte eine Abhängigkeit den Fehler verursachen. Das Anheften von Versionsabhängigkeiten in Ihrer conda-Datei kann dieses Problem beheben.

Versuchen Sie, Ihre Modelle vor der Bereitstellung in der Cloud lokal bereitzustellen, um sie zu testen und zu debuggen.

ERROR: Kontingenterschöpft

Bei der Verwendung von Azure-Diensten können die Kontingente für die folgenden Ressourcen erschöpft werden:

Nur für Kubernetes-Onlineendpunkte: Die Kubernetes-Ressource könnte ebenfalls erschöpft werden.

CPU-Kontingent

Sie müssen über genügend Compute-Kontingent verfügen, um ein Modell bereitzustellen. Das CPU-Kontingent definiert, wie viele virtuelle Kerne pro Abonnement, Arbeitsbereich, SKU und Region verfügbar sind. Bei jeder Bereitstellung wird das verfügbare Kontingent reduziert und je nach Typ der SKU nach dem Löschen wieder erhöht.

Sie können überprüfen, ob nicht verwendete Bereitstellungen vorhanden sind, die Sie löschen können, oder Sie können eine Anforderung für eine Kontingenterhöhung senden.

Clusterkontingent

Der Fehler OutOfQuota tritt auf, wenn Sie nicht über ein genügendes Kontingent für den Azure Machine Learning-Computecluster verfügen. Das Kontingent definiert die Gesamtanzahl der Cluster pro Abonnement, die Sie gleichzeitig zum Bereitstellen von CPU- oder GPU-Knoten in der Azure-Cloud verwenden können.

Datenträgerkontingent

Der Fehler OutOfQuota tritt auf, wenn die Größe des Modells größer als der verfügbare Speicherplatz ist und das Modell nicht heruntergeladen werden kann. Versuchen Sie, eine SKU mit mehr Speicherplatz zu verwenden, oder verringern Sie die Image- und Modellgröße.

Arbeitsspeicherkontingent

Der Fehler OutOfQuota tritt auf, wenn der Speicherbedarf des Modells größer als der verfügbarer Speicherplatz ist. Probieren Sie eine SKU mit mehr Arbeitsspeicher aus.

Quote für die Rollenzuweisung

Wenn Sie einen verwalteten Onlineendpunkt erstellen, ist eine Rollenzuweisung erforderlich, damit die verwaltete Identität auf Arbeitsbereichsressourcen zugreifen kann. Wenn Sie den Grenzwert für die Rollenzuweisung erreichen, versuchen Sie, einige nicht verwendete Rollenzuweisungen in diesem Abonnement zu löschen. Sie können alle Rollenzuweisungen überprüfen, indem Sie im Azure-Portal die Option Zugriffssteuerung für Ihr Azure-Abonnement auswählen.

Endpunktkontingent

Versuchen Sie, einige nicht verwendete Endpunkte in diesem Abonnement zu löschen. Wenn alle Ihre Endpunkte aktiv verwendet werden, versuchen Sie, eine Erhöhung des Endpunktgrenzwerts anzufordern. Weitere Informationen zum Endpunktgrenzwert finden Sie unter Endpunktkontingent bei Azure Machine Learning-Onlineendpunkten und -Batchendpunkten.

Kubernetes-Kontingent

Der Fehler OutOfQuota tritt auf, wenn die angeforderte CPU oder der angeforderte Arbeitsspeicher nicht bereitgestellt werden können, da Knoten für diese Bereitstellung nicht geplant werden können. Beispielsweise können Knoten abgesperrt oder anderweitig nicht verfügbar sein.

Die Fehlermeldung deutet in der Regel auf den Ressourcenmangel im Cluster hin, z. B. OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Diese Meldung bedeutet, dass es zu viele Pods im Cluster und nicht genügend Ressourcen gibt, um das neue Modell basierend auf Ihrer Anforderung bereitzustellen.

Versuchen Sie die folgenden Abhilfemaßnahmen, um dieses Problem zu beheben:

  • IT-Operatoren, die den Kubernetes-Cluster verwalten, können versuchen, mehr Knoten hinzuzufügen oder einige nicht verwendete Pods im Cluster zu löschen, um einige Ressourcen freizugeben.

  • Ingenieure für maschinelles Lernen, die Modelle bereitstellen, können versuchen, die Ressourcenanforderung für die Bereitstellung zu reduzieren.

    • Wenn Sie die Ressourcenanforderung direkt in der Bereitstellungskonfiguration über den Abschnitt „Ressource“ definieren, versuchen Sie, die Ressourcenanforderung zu reduzieren.
    • Wenn Sie instance_type verwenden, um die Ressource für die Modellimplementierung zu definieren, wenden Sie sich an den IT-Operator, um die Ressourcenkonfiguration des Instanztyps anzupassen. Weitere Informationen finden Sie unter Erstellen und Verwalten von Instanztypen.

Regionsweite VM-Kapazität

Aufgrund mangelnder Azure Machine Learning-Kapazität in der Region konnte der Dienst die angegebene VM-Größe nicht bereitstellen. Versuchen Sie es später erneut, oder stellen Sie in einer anderen Region bereit.

Anderes Kontingent

Um die Datei score.py auszuführen, die Sie als Teil der Bereitstellung bereitstellen, erstellt Azure einen Container, der alle Ressourcen enthält, welche score.py benötigt. Azure Machine Learning führt dann das Bewertungsskript für diesen Container aus. Wenn Ihr Container nicht starten kann, kann die Bewertung nicht erfolgen. Der Container fordert möglicherweise mehr Ressourcen an, als der instance_type unterstützen kann. Erwägen Sie, den instance_type der Onlinebereitstellung zu aktualisieren.

Um den genauen Grund für den Fehler zu erhalten, führen Sie die folgende Aktion aus.

Führen Sie den folgenden Befehl aus:

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

ERROR: Falsches Argument

Möglicherweise erhalten Sie diesen Fehler aus den folgenden Gründen, wenn Sie entweder verwaltete Onlineendpunkte oder Kubernetes-Onlineendpunkte verwenden:

Möglicherweise erhalten Sie diesen Fehler auch aus den folgenden Gründen, wenn Sie nur Kubernetes-Onlineendpunkte verwenden:

Das Abonnement ist nicht vorhanden

Das referenzierte Azure-Abonnement muss vorhanden und aktiv sein. Dieser Fehler tritt auf, wenn Azure die von Ihnen eingegebene Abonnement-ID nicht finden kann. Der Fehler kann auf einen Tippfehler in der Abonnement-ID zurückzuführen sein. Überprüfen Sie erneut, ob die Abonnement-ID korrekt eingegeben wurde, und ob sie derzeit aktiv ist.

Autorisierungsfehler

Nachdem Sie die Computeressource beim Erstellen einer Bereitstellung bereitgestellt haben, pullt Azure das Benutzercontainerimage aus der Arbeitsbereichscontainerregistrierung und bindet das Benutzermodell und Codeartefakte aus dem Arbeitsbereichsspeicherkonto in den Benutzercontainer ein. Azure verwendet verwaltete Identitäten, um auf das Speicherkonto und die Containerregistrierung zuzugreifen.

Wenn Sie den zugeordneten Endpunkt mit einer benutzerseitig zugewiesene Identität erstellen, muss die verwaltete Identität des Benutzers über die Berechtigung Speicherblob-Datenleser für das Arbeitsbereichsspeicherkonto verfügen und die Berechtigung AcrPull für Azure Container Registry (ACR) für die Arbeitsbereichscontainerregistrierung. Stellen Sie sicher, dass Ihre benutzerseitig zugewiesene Identität über die richtige Berechtigung verfügt.

Wenn Sie den zugeordneten Endpunkt mit einer systemseitig zugewiesenen Identität erstellen, wird die Berechtigung für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Azure automatisch gewährt, und es sind keine weiteren Berechtigungen erforderlich. Weitere Informationen finden Sie unter Autorisierungsfehler bei der Containerregistrierung.

Ungültige Vorlagenfunktionsspezifikation

Dieser Fehler tritt auf, wenn eine Vorlagenfunktion nicht richtig angegeben wurde. Beheben Sie entweder die Richtlinie, oder entfernen Sie die Richtlinienzuweisung, um die Blockierung aufzuheben. Die Fehlermeldung kann den Richtlinienzuweisungsnamen und die Richtliniendefinition enthalten, um Ihnen beim Debuggen dieses Fehlers zu helfen. Tipps zum Vermeiden von Vorlagenfehlern finden Sie in unter Azure Policy-Definitionsstruktur.

Benutzer-Container-Image kann nicht heruntergeladen werden

Der Benutzercontainer wurde möglicherweise nicht gefunden. Überprüfen Sie die Containerprotokolle, um weitere Details zu erhalten.

Stellen Sie sicher, dass das Containerimage in der Arbeitsbereichscontainerregistrierung verfügbar ist. Wenn das Image beispielsweise testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest ist, können Sie den folgenden Befehl verwenden, um das Repository zu überprüfen:

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

Das Benutzermodell kann nicht heruntergeladen werden.

Das Benutzermodell wurde möglicherweise nicht gefunden. Überprüfen Sie die Containerprotokolle, um weitere Details zu erhalten. Vergewissern Sie sich, dass Sie das Modell für denselben Arbeitsbereich registriert haben wie die Bereitstellung.

Um Details für ein Modell in einem Arbeitsbereich anzuzeigen, führen Sie die folgende Aktion aus. Sie müssen eine Version oder Bezeichnung angeben, um die Modellinformationen abzurufen.

Führen Sie den folgenden Befehl aus:

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

Überprüfen Sie ebenfalls, ob die Blobs im Arbeitsbereichsspeicherkonto vorhanden sind. Wenn der Blob beispielsweise https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl ist, können Sie den folgenden Befehl verwenden, um zu überprüfen, ob der Blob vorhanden ist:

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

Wenn der Blob vorhanden ist, können Sie diesen Befehl zum Abrufen der Protokolle aus der Speicherinitialisierung verwenden:

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

MLflow-Modellformat mit privatem Netzwerk wird nicht unterstützt

Sie können das Feature für private Netzwerke nicht mit einem MLflow-Modellformat verwenden, wenn Sie die Legacy-Netzwerkisolationsmethode für verwaltete Onlineendpunkte verwenden. Wenn Sie ein MLflow-Modell mit dem No-Code-Bereitstellungsansatz bereitstellen müssen, versuchen Sie, ein vom Arbeitsbereich verwaltetes virtuelles Netzwerk zu verwenden.

Ressourcenanforderungen übersteigen die Grenzen

Anforderungen für Ressourcen müssen kleiner oder gleich den Grenzwerten sein. Wenn Sie keine Grenzwerte festlegen, legt Azure Machine Learning Standardwerte fest, wenn Sie Ihre Compute-Instanz an einen Arbeitsbereich anfügen. Sie können die Grenzwerte im Azure-Portal oder mit dem Befehl az ml compute show überprüfen.

Azureml-fe nicht bereit

Die Front-End-Komponente azureml-fe, die eingehende Rückschlussanforderungen an bereitgestellte Dienste weiterleitet, wird während der Installation von k8s-extension installiert und bei Bedarf automatisch skaliert. Diese Komponente sollte mindestens ein fehlerfreies Replikat auf dem Cluster aufweisen.

Sie erhalten diesen Fehler, wenn die Komponente nicht verfügbar ist, wenn Sie einen Kubernetes-Onlineendpunkt, eine Bereitstellungserstellung oder eine Aktualisierungsanforderung auslösen. Überprüfen Sie den Pod-Status und die Protokolle, um dieses Problem zu beheben. Sie können auch versuchen, die auf dem Cluster installierte k8s-extension zu aktualisieren.

ERROR: RessourceNichtBereit

Um die von Ihnen als Teil der Bereitstellung angegebene Datei score.py auszuführen, erstellt Azure einen Container, der alle von score.py benötigten Ressourcen enthält, und führt das Bewertungsskript für diesen Container aus. Der Fehler in diesem Szenario ist, dass dieser Container beim Ausführen abstürzt, sodass keine Bewertung erfolgen kann. Dieser Fehler kann aufgrund einer der folgenden Bedingungen auftreten:

  • Es gibt einen Fehler in score.py. Verwenden Sie get-logs, um häufige Probleme zu diagnostizieren, wie z. B.:

    • Ein Paket, das score.py zu importieren versucht, das nicht in der Conda-Umgebung enthalten ist
    • Ein Syntaxfehler.
    • Ein Fehler in der init()-Methode.

    Wenn get-logs keine Protokolle erstellt, bedeutet dies in der Regel, dass der Container nicht gestartet werden konnte. Um dieses Problem zu beheben, versuchen Sie, lokal bereitzustellen.

  • Bereitschafts- oder Livetests sind nicht richtig eingerichtet.

  • Die Containerinitialisierung dauert zu lange, sodass der Bereitschafts- oder Livetest über den Fehlerschwellenwert hinaus fehlschlägt. Passen Sie in diesem Fall die Testeinstellungen an, um mehre Zeit für die Initialisierung des Containers zu erlauben. Oder versuchen Sie eine größere unterstützte VM-SKU, was die Initialisierung beschleunigt.

  • Es gibt einen Fehler bei der Einrichtung der Containerumgebung, z. B. eine fehlende Abhängigkeit.

    Wenn Sie den Fehler TypeError: register() takes 3 positional arguments but 4 were given erhalten, überprüfen Sie die Abhängigkeit zwischen Flask v2 und azureml-inference-server-http. Weitere Informationen finden Sie unter Problembehandlung bei HTTP-Serverproblemen.

ERROR: Ressource nicht gefunden

Möglicherweise erhalten Sie diesen Fehler aus den folgenden Gründen, wenn Sie entweder einen verwalteten Onlineendpunkt oder einen Kubernetes-Onlineendpunkt verwenden:

Resource Manager kann eine Ressource nicht finden

Dieser Fehler tritt auf, wenn der Azure Resource Manager eine benötigte Ressource nicht finden kann. Sie können diesen Fehler beispielsweise erhalten, wenn ein Speicherkonto unter dem angegebenen Pfad nicht gefunden werden kann. Überprüfen Sie die Pfad- oder Namensspezifikationen erneut auf Genauigkeit und Rechtschreibung. Weitere Informationen finden Sie unter Auflösen von Fehlern für „Ressource nicht gefunden“.

Autorisierungsfehler bei Containerregistrierung

Dieser Fehler tritt auf, wenn ein Image, das zu einer privaten oder anderweitig unzugänglichen Containerregistrierung gehört, für die Bereitstellung angegeben wird. Azure Machine Learning-APIs können keine privaten Registrierungsanmeldeinformationen akzeptieren.

Um diesen Fehler zu entschärfen, stellen Sie entweder sicher, dass die Containerregistrierung nicht privat ist, oder führen Sie die folgenden Schritte aus:

  1. Weisen Sie die Rolle acrPull Ihrer privaten Registrierung der Systemidentität Ihres Onlineendpunkts zu.
  2. Geben Sie in Ihrer Umgebungsdefinition die Adresse Ihres privaten Images an, und geben Sie die Anweisung, das Image nicht zu ändern oder zu erstellen.

Wenn diese Risikominderung erfolgreich ist, erfordert das Image keine Erstellung, und die endgültige Imageadresse ist die angegebene Imageadresse. Zum Zeitpunkt der Bereitstellung pullt die Systemidentität Ihres Onlineendpunkts das Image aus der privaten Registrierung.

Weitere Diagnoseinformationen finden Sie unter Verwenden der Arbeitsbereichsdiagnose.

ERROR: WorkspaceManagedNetworkNotReady

Dieser Fehler tritt auf, wenn Sie versuchen, eine Onlinebereitstellung zu erstellen, die ein vom Arbeitsbereich verwaltetes virtuelles Netzwerk aktiviert, aber das verwaltete virtuelle Netzwerk ist noch nicht bereitgestellt. Stellen Sie das vom Arbeitsbereich verwaltete virtuelle Netzwerk bereit, bevor Sie eine Onlinebereitstellung erstellen.

Um das vom Arbeitsbereich verwaltete virtuelle Netzwerk manuell bereitzustellen, befolgen Sie die Anweisungen unter Manuelles Bereitstellen eines verwalteten VNet. Sie können dann mit dem Erstellen von Onlinebereitstellungen beginnen. Weitere Informationen finden Sie unter Netzwerkisolation mit verwaltetem Onlineendpunkt und Sichern Ihrer verwalteten Onlineendpunkte mit Netzwerkisolation.

FEHLER: OperationCanceled

Möglicherweise erhalten Sie diesen Fehler aus den folgenden Gründen, wenn Sie entweder einen verwalteten Onlineendpunkt oder einen Kubernetes-Onlineendpunkt verwenden:

Der Vorgang wurde durch einen anderen Vorgang mit höherer Priorität abgebrochen.

Azure-Vorgänge haben eine bestimmte Prioritätsstufe und werden von der höchsten zur niedrigsten ausgeführt. Dieser Fehler tritt auf, wenn ein anderer Vorgang mit einer höherer Priorität Ihren Vorgang überschreibt. Wenn Sie den Vorgang wiederholen, kann er möglicherweise ohne Abbruch ausgeführt werden.

Der Vorgang wurde beim Warten auf eine Sperrbestätigung abgebrochen.

Für Azure-Vorgänge gibt es nach der Übermittlung eine kurze Wartezeit, während der sie eine Sperre abrufen, um sicherzustellen, dass keine Racebedingungen auftreten. Dieser Fehler tritt auf, wenn der von Ihnen übermittelte Vorgang mit einem anderen Vorgang übereinstimmt. Der andere Vorgang wartet derzeit auf die Bestätigung, dass er die Sperre erhalten hat, bevor er weiterfährt.

Möglicherweise haben Sie eine ähnliche Anforderung zu früh nach der ursprünglichen Anforderung übermittelt. Wenn Sie den Vorgang nach einer Wartezeit von bis zu einer Minute wiederholen, kann er möglicherweise ohne Abbruch ausgeführt werden.

FEHLER: SecretsInjectionError

Abruf und Einschleusung von Geheimnissen während der Erstellung der Onlinebereitstellung verwenden die Identität, die dem Onlineendpunkt zugeordnet ist, um Geheimnisse aus den Arbeitsbereichsverbindungen oder Schlüsseltresoren abzurufen. Dieses Problem tritt aus einem der folgenden Gründe auf:

  • Die Endpunktidentität verfügt nicht über die Azure RBAC-Berechtigung zum Lesen der Geheimnisse aus den Arbeitsbereichsverbindungen oder den Schlüsseltresoren, obwohl die Bereitstellungsdefinition die Geheimnisse als den Umgebungsvariablen zugeordnete Verweise angegeben hat. Bei der Rollenzuweisung kann es einige Zeit dauern, bis die Änderungen wirksam werden.

  • Das Format der Geheimnisverweise ist ungültig, oder die angegebenen Geheimnisse sind in den Arbeitsbereichsverbindungen oder den Schlüsseltresoren nicht vorhanden.

Weitere Informationen finden Sie unter Geheimniseinschleusung in Onlineendpunkten (Vorschau) und Zugreifen auf Geheimnisse aus der Onlinebereitstellung mithilfe von Geheimniseinschleusung (Vorschau).

ERROR: InternerServerFehler

Dieser Fehler bedeutet, dass beim Azure Machine Learning Service ein Fehler aufgetreten ist, der behoben werden muss. Übermitteln Sie ein Kundendienstticket mit allen Informationen, die zum Beheben des Problems erforderlich sind.

Häufige Fehler, die speziell in Kubernetes-Bereitstellungen auftreten

Identitäts- und Authentifizierungsfehler:

Crashloopbackoff-Fehler:

Bewertungsskriptfehler:

Sonstige Fehler:

FEHLER: ACRSecretError

Wenn Sie Kubernetes-Onlinebereitstellungen erstellen oder aktualisieren, erhalten Sie diesen Fehler möglicherweise aus einem der folgenden Gründe angezeigt:

  • Die Rollenzuweisung ist nicht abgeschlossen. Warten Sie einige Sekunden, und versuchen Sie es noch mal.

  • Der Azure Arc-fähige Kubernetes-Cluster oder die Azure Machine Learning-Erweiterung für AKS sind nicht ordnungsgemäß installiert oder konfiguriert. Überprüfen Sie die Konfiguration und den Status des Azure Arc-fähigen Kubernetes oder der Azure Machine Learning-Erweiterung.

  • Der Kubernetes-Cluster verfügt über eine ungeeignete Netzwerkkonfiguration. Überprüfen Sie den Proxy, die Netzwerkrichtlinie oder das Zertifikat.

  • Ihr privater AKS-Cluster verfügt nicht über die richtigen Endpunkte. Stellen Sie sicher, dass Sie private Endpunkte für die Container Registry, das Speicherkonto und den Arbeitsbereich im virtuellen AKS-Netzwerk einrichten.

  • Die Version Ihrer Azure Machine Learning-Erweiterung ist v1.1.25 oder niedriger. Stellen Sie sicher, dass die Version Ihrer Erweiterung größer als v1.1.25 ist.

FEHLER: TokenRefreshFailed

Dieser Fehler tritt auf, weil die Kubernetes-Clusteridentität nicht richtig festgelegt ist, weshalb die Erweiterung keine Prinzipalanmeldeinformationen aus Azure abrufen kann. Installieren Sie die Azure Machine Learning-Erweiterung erneut, und versuchen Sie es erneut.

FEHLER: GetAADTokenFailed

Dieser Fehler tritt auf, weil die Kubernetes-Clusteranforderung für das Microsoft Entra ID-Token fehlgeschlagen ist oder ein Timeout aufgetreten ist. Überprüfen Sie Ihren Netzwerkzugriff, und versuchen Sie es dann erneut.

  • Befolgen Sie die Anweisungen unter Kubernetes-Compute verwenden, um den ausgehenden Proxy zu überprüfen und sicherzustellen, dass der Cluster eine Verbindung mit dem Arbeitsbereich herstellen kann. Sie können die Endpunkt-URL des Arbeitsbereichs im Cluster in der benutzerdefinierten Ressourcendefinition (Custom Resource Definition, CRD) des Onlineendpunkts finden.

  • Überprüfen Sie, ob der Arbeitsbereich öffentlichen Zugriff zulässt. Wenn ein privater Arbeitsbereich den Zugriff auf öffentliche Netzwerke deaktiviert, kann der Kubernetes-Cluster nur über eine private Verbindung mit diesem Arbeitsbereich kommunizieren, unabhängig davon, ob der AKS-Cluster selbst öffentlich oder privat ist. Weitere Informationen finden Sie unter Was ist eine sichere AKS-Rückschlussumgebung.

FEHLER: ACRAuthenticationChallengeFailed

Dieser Fehler tritt auf, da der Kubernetes-Cluster den Container Registry-Dienst des Arbeitsbereichs nicht erreichen kann, um eine Authentifizierungsherausforderung durchzuführen. Überprüfen Sie Ihr Netzwerk, insbesondere den öffentlichen Netzwerkzugriff der Container Registry, und versuchen Sie es dann erneut. Sie können die Schritte zur Problembehandlung in GetAADTokenFailed ausführen, um das Netzwerk zu überprüfen.

FEHLER: ACRTokenExchangeFailed

Dieser Fehler tritt auf, da das Microsoft Entra ID-Token noch nicht autorisiert ist, sodass das Austausch des Container Registry-Tokens für den Kubernetes-Cluster fehlschlägt. Die Rollenzuweisung dauert einige Zeit, warten Sie also eine Minute und versuchen Sie es dann erneut.

Dieser Fehler kann auch auf zu viele gleichzeitige Anforderungen an den Container Registry-Dienst zurückzuführen sein. Dieser Fehler sollte vorübergehend sein, und Sie können es später erneut versuchen.

FEHLER: KubernetesUnaccessible

Während der Kubernetes-Modellimplementierung erhalten Sie möglicherweise den folgenden Fehler:

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

Um diesen Fehler zu mindern, können Sie das AKS-Zertifikat für den Cluster rotieren. Das neue Zertifikat sollte nach 5 Stunden aktualisiert sein, sodass Sie 5 Stunden warten und es erneut bereitstellen können. Weitere Informationen finden Sie unter Zertifikatsrotation in Azure Kubernetes Service (AKS).

FEHLER: ImagePullLoopBackOff

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Kubernetes-Onlinebereitstellungen erstellen oder aktualisieren, da Sie die Images nicht aus der Containerregistrierung herunterladen können, was zu einem Fehler beim Pullen der Images führt. Überprüfen Sie die Netzwerkrichtlinie des Clusters und die Containerregistrierung des Arbeitsbereichs, um zu sehen, ob der Cluster ein Image aus der Containerregistrierung pullen kann.

FEHLER: DeploymentCrashLoopBackOff

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Kubernetes-Onlinebereitstellungen erstellen oder aktualisieren, da der Benutzercontainer bei der Initialisierung abstürzte. Für diesen Fehler gibt es zwei mögliche Ursachen:

  • Das Benutzerskript score.py weist einen Syntaxfehler oder Importfehler auf, der Ausnahmen bei der Initialisierung auslöst.
  • Der Bereitstellungspod benötigt mehr Speicher als sein Grenzwert.

Um diesen Fehler zu mindern, überprüfen Sie zunächst die Bereitstellungsprotokolle auf Ausnahmen in Benutzerskripts. Wenn der Fehler weiterhin auftritt, versuchen Sie, den Speichergrenzwert des Ressourcen-/Instanztyps zu vergrößern.

FEHLER: KubernetesCrashLoopBackOff

Möglicherweise erhalten Sie diesen Fehler aus einem der folgenden Gründe, wenn Sie Kubernetes-Onlineendpunkte oder Bereitstellungen erstellen oder aktualisieren:

  • Mindestens ein Pod bleibt im CrashLoopBackoff-Status hängen. Überprüfen Sie, ob das Bereitstellungsprotokoll vorhanden ist und ob es Fehlermeldungen enthält.
  • Es gibt einen Fehler in score.py und der Container stürzte ab, als er Ihren Bewertungscode initialisierte. Folgen Sie den Anweisungen unter ERROR: ResourceNotReady.
  • Ihr Bewertungsprozess benötigt mehr Speicher als der Grenzwert Ihrer Bereitstellungskonfiguration zulässt. Sie können versuchen, die Bereitstellung mit einem größeren Speichergrenzwert zu aktualisieren.

FEHLER: NamespaceNotFound

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Kubernetes-Onlineendpunkte erstellen oder aktualisieren, da der verwendete Namespace, den Ihr Kubernetes-Compute verwendet, in Ihrem Cluster nicht verfügbar ist. Überprüfen Sie die Kubernetes-Compute-Instanz in Ihrem Arbeitsbereichsportal und den Namespace in Ihrem Kubernetes-Cluster. Wenn der Namespace nicht verfügbar ist, trennen Sie die Legacy-Compute-Instanz und fügen sie erneut an, um eine neue zu erstellen. Geben Sie dabei einen Namespace an, der in Ihrem Cluster bereits vorhanden ist.

FEHLER: UserScriptInitFailed

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Kubernetes-Onlinebereitstellungen erstellen oder aktualisieren, da die Funktion init in Ihrer hochgeladenen Datei score.py eine Ausnahme ausgelöste. Überprüfen Sie die Bereitstellungsprotokolle, um die Ausnahmemeldung im Detail anzuzeigen und die Ausnahme zu korrigieren.

FEHLER: UserScriptImportError

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Kubernetes-Onlinebereitstellungen erstellen oder aktualisieren, da die von Ihnen hochgeladene Datei score.py nicht verfügbare Pakete importiert. Überprüfen Sie die Bereitstellungsprotokolle, um die Ausnahmemeldung im Detail anzuzeigen und die Ausnahme zu korrigieren.

FEHLER: UserScriptFunctionNotFound

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Kubernetes-Onlinebereitstellungen erstellen oder aktualisieren, da die von Ihnen hochgeladene Datei score.py keine Funktion namens init() oder run() aufweist. Überprüfen Sie Ihren Code und fügen Sie die Funktion hinzu.

FEHLER: EndpointNotFound

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Kubernetes-Onlinebereitstellungen erstellen oder aktualisieren, da das System die Endpunktressource für die Bereitstellung im Cluster nicht finden kann. Erstellen Sie eine Bereitstellung in einem vorhandenen Endpunkt, oder erstellen Sie den Endpunkt zuerst in Ihrem Cluster.

FEHLER: EndpointAlreadyExists

Möglicherweise erhalten Sie diesen Fehler, wenn Sie einen Kubernetes-Onlineendpunkt erstellen, da der Endpunkt bereits in Ihrem Cluster vorhanden ist. Der Endpunktname sollte pro Arbeitsbereich und pro Cluster eindeutig sein, erstellen Sie deshalb einen Endpunkt mit einem anderen Namen.

FEHLER: ScoringFeUnhealthy

Möglicherweise erhalten Sie diesen Fehler, wenn Sie einen Kubernetes-Onlineendpunkt oder eine Bereitstellung erstellen oder aktualisieren, da der Systemdienst azureml-fe, der im Cluster ausgeführt wird, nicht gefunden wird oder nicht fehlerfrei ist. Um dieses Problem zu mindern, installieren oder aktualisieren Sie die Azure Machine Learning-Erweiterung in Ihrem Cluster erneut.

FEHLER: ValidateScoringFailed

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Kubernetes-Onlinebereitstellungen erstellen oder aktualisieren, da die Überprüfung der Bewertungsanforderung-URL beim Verarbeiten des Modells fehlgeschlagen ist. Überprüfen Sie die Endpunkt-URL, und versuchen Sie dann die Bereitstellung erneut.

FEHLER: InvalidDeploymentSpec

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Kubernetes-Onlinebereitstellungen erstellen oder aktualisieren, da die Bereitstellungsspezifikation ungültig ist. Überprüfen Sie die Fehlermeldung, um sicherzustellen, dass die instance count gültig ist. Wenn Sie die Autoskalierung aktiviert haben, stellen Sie sicher, dass minimum instance count und maximum instance count beide gültig sind.

FEHLER: PodUnschedulable

Möglicherweise erhalten Sie diesen Fehler aus einem der folgenden Gründe, wenn Sie Kubernetes-Onlineendpunkte oder Bereitstellungen erstellen oder aktualisieren:

  • Das System kann den Pod aufgrund unzureichender Ressourcen in Ihrem Cluster nicht für die Knoten planen.
  • Kein Knoten entspricht der Auswahl für die Knotenaffinität.

Um diesen Fehler zu mindern, folgen Sie diesen Schritten:

  1. Überprüfen Sie die node selector-Definition des von Ihnen verwendeten instance_type und die node label-Konfiguration Ihrer Clusterknoten.
  2. Überprüfen Sie den instance_type und die SKU-Größe des Knotens für den AKS-Cluster oder die Knotenressource für den Azure Arc-fähigen Kubernetes-Cluster.
  3. Wenn dem Cluster zu wenig Ressourcen zugewiesen sind, reduzieren Sie die Ressourcenanforderung für den Instanztyp, oder verwenden Sie einen anderen Instanztyp mit geringeren Ressourcenanforderungen.
  4. Wenn der Cluster über keine Ressourcen mehr verfügt, um die Anforderung der Bereitstellung zu erfüllen, löschen Sie einige Bereitstellungen, um Ressourcen freizugeben.

FEHLER: PodOutOfMemory

Möglicherweise erhalten Sie diesen Fehler, wenn Sie eine Onlinebereitstellung erstellen oder aktualisieren, da der von Ihnen für die Bereitstellung festgelegte Speichergrenzwert nicht ausreicht. Um diesen Fehler zu mindern, können Sie den Speichergrenzwert auf einen höheren Wert festlegen oder einen größeren Instanztyp verwenden.

FEHLER: InferencingClientCallFailed

Möglicherweise erhalten Sie diesen Fehler, wenn Sie Kubernetes-Onlineendpunkte oder -Bereitstellungen erstellen oder aktualisieren, da die k8s-extension des Kubernetes-Clusters nicht verbunden werden kann. Trennen Sie in diesem Fall Ihre Compute-Instanz und fügen sie dann erneut an.

Um Fehler beim erneuten Anfügen zu beheben, stellen Sie sicher, dass Sie mit der gleichen Konfiguration wie die getrennten Compute-Instanz neu anfügen, z. B. der Computename und der Namespace, um andere Fehler zu vermeiden. Wenn es immer noch nicht funktioniert, bitten Sie einen Administrator mit Zugriff auf den Cluster, kubectl get po -n azureml zu verwenden, um zu überprüfen, ob die Relayserverpods ausgeführt werden.

Probleme beim Modellverbrauch

Häufige Fehler beim Modellverbrauch, die sich aus dem Endpunktvorgangsstatus invoke ergeben, umfassen Bandbreitengrenzwertprobleme, CORS-Richtlinie und verschiedene HTTP-Statuscodes.

Probleme mit dem Bandbreitengrenzwert

Bei verwalteten Onlineendpunkten gelten Bandbreitengrenzwerte für jeden Endpunkt. Sie können die Grenzwertkonfiguration unter Grenzwerte für Onlineendpunkte finden. Wenn Ihr Bandbreitenverbrauch den Grenzwert überschreitet, ist Ihre Anforderung verzögert.

Verwenden Sie zum Überwachen der Bandbreitenverzögerung die Metrik Netzwerkbytes, um den aktuellen Bandbreitenverbrauch zu verstehen. Weitere Informationen finden Sie unter Überwachen verwalteter Onlineendpunkte (Vorschau).

Zwei Antworttrailer werden zurückgegeben, wenn der Bandbreitengrenzwert erzwungen wird:

  • ms-azureml-bandwidth-request-delay-ms ist die Verzögerungszeit in Millisekunden bei der Übertragung des Anforderungsstreams.
  • ms-azureml-bandwidth-response-delay-ms ist die Verzögerungszeit in Millisekunden bei der Übertragung des Antwortstreams.

Durch CORS-Richtlinie blockiert

V2-Onlineendpunkte unterstützen derzeit CORS (Cross-Origin Resource Sharing) nicht nativ. Wenn Ihre Webanwendung versucht, den Endpunkt ohne ordnungsgemäße Behandlung der CORS-Preflight-Anforderungen aufzurufen, können Sie die folgende Fehlermeldung erhalten:

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.

Sie können Azure Functions, Azure Application Gateway oder einen anderen Dienst als Zwischenschicht zu verwenden, um CORS-Preflight-Anforderungen zu verarbeiten.

HTTP-Statuscodes

Wenn Sie mit REST-Anforderungen auf Onlineendpunkte zugreifen, entsprechen die zurückgegebenen Statuscodes den Standardvorgaben für HTTP-Statuscodes. Die folgenden Abschnitten erläutern, wie Endpunktaufrufe und Vorhersagefehler den HTTP-Statuscodes zugeordnet werden.

Allgemeine Fehlercodes für verwaltete Onlineendpunkte

Die folgende Tabelle enthält häufige Fehlercodes, wenn REST-Anforderungen verwaltete Onlineendpunkte verbrauchen:

Statuscode Ursache Beschreibung
200 OK Ihr Modell wurde erfolgreich innerhalb der von Ihnen festgelegten Latenzgrenzwerte ausgeführt.
401 Nicht autorisiert Sie verfügen nicht über die Berechtigung für die Durchführung der angeforderten Aktion, z. B. einer Bewertung, oder Ihr Token ist abgelaufen oder hat das falsche Format. Weitere Informationen finden Sie unter Authentifizierung für verwaltete Onlineendpunkte und Authentifizieren von Clients für Onlineendpunkte.
404 Nicht gefunden Der Endpunkt hat keine gültige Bereitstellung mit positiver Gewichtung.
408 Anforderungszeitlimit Die Modellausführung hat mehr Zeit benötigt, als in der Konfiguration Ihrer Modellbereitstellung in request_timeout_ms unter request_settings als Zeitlimit angegeben ist.
424 Modellfehler Wenn von Ihrem Modellcontainer eine andere Antwort als „200“ zurückgegeben wird, gibt Azure „424“ zurück. Überprüfen Sie die Model Status Code-Dimension unter der Requests Per Minute-Metrik im Azure Monitor Metric Explorer Ihres Endpunkts. Oder siehe die Antwortheader ms-azureml-model-error-statuscode und ms-azureml-model-error-reason, um weitere Informationen zu erhalten. Wenn 424 mit einem Fehler der Live- oder Bereitschaftstests kommt, sollten Sie die ProbeSettings (Testeinstellungen) anpassen, um mehr Zeit zum Testen des Livestatus oder der Bereitschaft des Containers zu erlauben.
429 Too many pending requests (Zu viele ausstehende Anforderungen) Ihr Modell erhält derzeit mehr Anforderungen, als es verarbeiten kann. Um einen reibungslosen Betrieb zu gewährleisten, erlaubt Azure Machine Learning zu einem bestimmten Zeitpunkt maximal 2 * max_concurrent_requests_per_instance * instance_count requests Anforderungen parallel zu verarbeiten. Anforderungen, welche dieses Maximum überschreiten, werden abgelehnt.

Sie können ihre Modellimplementierungskonfiguration unter den Abschnitten request_settings und scale_settings überprüfen, um sie zu überprüfen und anzupassen. Stellen Sie außerdem sicher, dass die Umgebungsvariable WORKER_COUNT ordnungsgemäß übergeben wird, wie in RequestSettings (Anforderungseinstellungen) beschrieben.

Wenn Sie bei Verwendung der Autoskalierung diesen Fehler erhalten, erhält Ihr Modell Anforderungen schneller, als das System hochskalieren kann. Erwägen Sie das erneute Senden von Anforderungen mit einem exponentiellen Backoff, um dem System Zeit zur Anpassung zu geben. Sie könnten auch die Anzahl der Instanzen erhöhen, indem Sie den Code zum Berechnen der Anzahl der Instanzen verwenden. Kombinieren Sie diese Schritte mit dem Festlegen der Autoskalierung, um sicherzustellen, dass Ihr Modell bereit ist, den Zustrom von Anforderungen zu verarbeiten.
429 Ratenbegrenzung Die Anzahl der Anforderungen pro Sekunde erreichte die Grenzwerte der verwalteten Onlineendpunkte.
500 Interner Serverfehler Die von Azure Machine Learning bereitgestellte Infrastruktur ist fehlerhaft.

Häufige Fehlercodes für Kubernetes-Onlineendpunkte

Die folgende Tabelle enthält häufige Fehlercodes, wenn REST-Anforderungen Kubernetes-Onlineendpunkten verbrauchen:

Statuscode Error Beschreibung
409 Konfliktfehler Wenn ein Vorgang bereits ausgeführt wird, antwortet jeder neue Vorgang auf demselben Onlineendpunkt mit einem Fehler „409 Konflikt“. Wenn beispielsweise ein Erstellungs- oder Aktualisierungsvorgang für einen Onlineendpunkt ausgeführt wird, gibt das Auslösen eines neuen Löschvorgangs einen Fehler aus.
502 Ausnahme oder Absturz in der run()-Methode der score.py-Datei Wenn in score.py ein Fehler vorhanden ist, z. B. ein in der Conda-Umgebung nicht vorhandenes importiertes Paket, ein Syntaxfehler oder ein Fehler in derinit()-Methode, finden Sie unter ERROR: ResourceNotReady (Ressource nicht bereit) Informationen zum Debuggen der Datei.
503 Große Spitzen bei Anforderungen pro Sekunde Die Autoskalierung wurde für die Behandlung gradueller Änderungen der Auslastung konzipiert. Wenn große Spitzen bei den Anforderungen pro Sekunde auftreten, erhalten Clients möglicherweise den HTTP-Statuscode 503. Obwohl das Autoscaling schnell reagiert, benötigt AKS viel Zeit, um weitere Container zu erstellen. Lesen Sie Verhindern von 503-Statuscodefehlern.
504 Timeout der Anforderung Ein Statuscode 504 gibt an, dass für die Anforderung eine Zeitüberschreitung aufgetreten ist. Die Standardeinstellung für die Zeitüberschreitung beträgt 5 Sekunden. Sie können den Zeitüberschreitungswert erhöhen oder versuchen, den Endpunkt zu beschleunigen, indem Sie score.py anpassen, um unnötige Aufrufe zu entfernen. Wenn das Problem durch diese Aktionen nicht behoben wird, befindet sich der Code möglicherweise in einem nicht reagierenden Zustand oder in einer Endlosschleife. Folgen Sie den Anweisungen in ERROR: ResourceNotReady (Ressource nicht bereit) zum Debuggen der score.py-Datei.
500 Interner Serverfehler Die von Azure Machine Learning bereitgestellte Infrastruktur ist fehlerhaft.

So verhindern Sie 503-Statuscodes

Kubernetes-Onlinebereitstellungen unterstützen die Autoskalierung, wodurch Replikate hinzugefügt werden können, um zusätzliche Last zu unterstützen. Weitere Informationen finden Sie unter Azure Machine Learning-Rückschlussrouter. Der Entscheid zum Hoch- oder Herunterskalieren basiert auf der Auslastung der aktuellen Containerreplikate.

Zwei Aktionen können dabei helfen, 503-Statuscodefehler zu vermeiden: Ändern der Auslastungsebene zum Erstellen neuer Replikate oder Ändern der Mindestanzahl von Replikaten. Sie können diese Ansätze einzeln oder in Kombination verwenden.

  • Ändern Sie das Auslastungsziel, bei dem die Autoskalierung neue Replikate erstellt, indem Sie den Wert autoscale_target_utilization auf einen niedrigeren Wert festlegen. Diese Änderung führt nicht dazu, dass Replikate schneller erstellt werden, sondern bei einem niedrigeren Auslastungsschwellenwert. Wenn der Wert beispielsweise auf 30 % geändert wird, werden Replikate erstellt, wenn die Auslastung bei 30 % liegt, anstatt zu warten, bis der Dienst zu 70 % ausgelastet ist.

  • Ändern Sie die Mindestanzahl von Replikaten, um einen größeren Pool bereitzustellen, der die eingehenden Spitzen verarbeiten kann.

Berechnen der Anzahl der Instanzen

Um die Anzahl der Instanzen zu erhöhen, können Sie die erforderlichen Replikate wie folgt berechnen:

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)

Hinweis

Wenn Sie Anforderungsspitzen erhalten, die größer sind, als die neue Mindestanzahl von Replikaten verarbeiten kann, erhalten Sie möglicherweise wieder den Statuscode 503. Wenn sich beispielsweise der Datenverkehr zu Ihrem Endpunkts erhöht, müssen Sie möglicherweise die Mindestanzahl von Replikaten erhöhen.

Wenn der Kubernetes-Onlineendpunkt bereits die aktuelle maximale Anzahl von Replikaten verwendet und Sie immer noch 503-Statuscodes erhalten, erhöhen Sie den autoscale_max_replicas-Wert, um die maximale Anzahl von Replikaten zu erhöhen.

Probleme bei der Netzwerkisolation

Dieser Abschnitt enthält Informationen zu häufigen Netzwerkisolationsproblemen.

Fehler bei der Erstellung des Onlineendpunkts mit der Meldung „V1LegacyMode == true“

Sie können den Azure Machine Learning-Arbeitsbereich für v1_legacy_mode konfigurieren, wodurch v2-APIs deaktiviert werden. Verwaltete Onlineendpunkte sind ein Feature der v2-API-Plattform und funktionieren nicht, wenn v1_legacy_mode für den Arbeitsbereich aktiviert ist.

Informationen zum Deaktivieren von v1_legacy_mode finden Sie unter Netzwerkisolation mit v2.

Wichtig

Wenden Sie sich an Ihr Netzwerksicherheitsteam, bevor Sie v1_legacy_mode deaktivieren, da das Team den Modus möglicherweise aus einem guten Grund aktivierte.

Fehler beim Erstellen eines Onlineendpunkts mit schlüsselbasierter Authentifizierung

Verwenden Sie den folgenden Befehl, um die Azure Key Vault-Netzwerkregeln für Ihren Arbeitsbereich aufzulisten. Ersetzen Sie <keyvault-name> durch den Namen Ihres Schlüsseltresors:

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

Die Antwort für diesen Befehl ähnelt dem folgenden JSON-Code:

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

Wenn der Wert von bypass nicht AzureServices lautet, folgen Sie der Anleitung unter Konfigurieren von Netzwerkeinstellungen für den Schlüsseltresor, um ihn auf AzureServices festzulegen.

Fehler zum Imagedownload bei Onlinebereitstellungen

Hinweis

Dieses Problem tritt auf, wenn Sie die Legacy-Netzwerkisolationsmethode für verwaltete Onlineendpunkte verwenden, bei der Azure Machine Learning ein verwaltetes, virtuelles Netzwerk für jede Bereitstellung unter einem Endpunkt erstellt.

  1. Überprüfen Sie, ob das Flag egress-public-network-access für die Bereitstellung disabled ist. Wenn dieses Flag aktiviert ist und die Sichtbarkeit der Containerregistrierung auf „privat“ festgelegt ist, dann ist dieser Fehler zu erwarten.

  2. Verwenden Sie den folgenden Befehl, um den Status der privaten Endpunktverbindung zu überprüfen. Ersetzen Sie <registry-name> durch den Namen der Azure-Containerregistrierung für Ihren Arbeitsbereich:

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

    Überprüfen Sie im Antwortcode, ob das Feld status auf Approved festgelegt ist. Wenn nicht, verwenden Sie den folgenden Befehl, um es zu genehmigen. Ersetzen Sie <private-endpoint-name> durch den vom vorstehenden Befehl zurückgegebenen Namen.

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

Bewertungsendpunkt kann nicht aufgelöst werden

  1. Stellen Sie sicher, dass der Client, der die Bewertungsanforderung sendet, ein virtuelles Netzwerk ist, das auf den Azure Machine Learning-Arbeitsbereich zugreifen kann.

  2. Verwenden Sie den Befehl nslookup für den Endpunkthostnamen, um Informationen zur IP-Adresse abzurufen, beispielsweise:

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

    Die Antwort enthält eine Adresse, die sich im vom virtuellen Netzwerk bereitgestellten Bereich befinden sollte.

    Hinweis

    • Für den Kubernetes-Onlineendpunkt sollte der Endpunktostname der CName (Domänenname) sein, der in Ihrem Kubernetes-Cluster angegeben ist.
    • Wenn der Endpunkt „HTTP“ ist, ist die IP-Adresse im Endpunkt-URI enthalten, den Sie von der Studio-Benutzeroberfläche abrufen können.
    • Sie können weitere Möglichkeiten zum Abrufen der IP-Adresse des Endpunkts unter Schützen eines Kubernetes-Onlineendpunkts finden.

  3. Wenn der Befehl nslookup den Hostnamen nicht auflöst, führen Sie die folgenden Aktionen aus:

Verwaltete Onlineendpunkte

  1. Verwenden Sie den folgenden Befehl, um zu überprüfen, ob ein A-Datensatz in der privaten DNS (Domänennamenserver)-Zone für das virtuelle Netzwerk vorhanden ist.

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

    Die Ergebnisse sollten einen Eintrag ähnlich wie *.<GUID>.inference.<region> enthalten.

  2. Wenn kein Rückschlusswert zurückgegeben wird, löschen Sie den privaten Endpunkt für den Arbeitsbereich, und erstellen Sie ihn anschließend neu. Weitere Informationen finden Sie unter Konfigurieren eines privaten Endpunkts.

  3. Wenn der Arbeitsbereich mit einem privaten Endpunkt einen benutzerdefinierten DNS-Server verwendet, führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Auflösung von benutzerdefiniertem DNS ordnungsgemäß funktioniert.

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

Kubernetes-Onlineendpunkte

  1. Überprüfen Sie die DNS-Konfiguration im Kubernetes-Cluster.

  2. Überprüfen Sie auch, ob azureml-fe wie erwartet funktioniert, indem Sie den folgenden Befehl verwenden:

    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"

    Verwenden Sie für HTTP den folgenden Befehl:

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

  3. Wenn „curl HTTPs„ fehlschlägt oder eine Zeitüberschreitung auftritt, HTTP aber funktioniert, überprüfen Sie, ob das Zertifikat gültig ist.

  4. Wenn der vorstehende Prozess nicht in den A-Datensatz aufgelöst werden kann, überprüfen Sie, ob die Auflösung von Azure DNS (168.63.129.16) funktioniert.

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

  5. Wenn der vorstehende Befehl erfolgreich ist, führen Sie die Problembehandlung für die bedingte Weiterleitung für die private Verbindung im benutzerdefinierten DNS aus.

Onlinebereitstellungen können nicht bewertet werden

  1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Bereitstellung erfolgreich war:

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

    Wenn die Bereitstellung erfolgreich abgeschlossen wurde, weist state den Wert Succeeded auf.

  2. Überprüfen Sie bei einer erfolgreichen Bereitstellung mit dem folgenden Befehl, ob der Datenverkehr der Bereitstellung zugewiesen ist. Ersetzen Sie <endpointname> durch den Namen Ihres Endpunkts.

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

    Die Antwort dieses Befehls sollte den Prozentsatz des Datenverkehrs auflisten, der Bereitstellungen zugeordnet ist.

    Tipp

    Dieser Schritt ist nicht notwendig, wenn Sie den azureml-model-deployment-Header in Ihrer Anforderung verwenden, um diese Bereitstellung als Ziel zu definieren.

  3. Wenn die Datenverkehrszuweisungen oder der Bereitstellungsheader ordnungsgemäß festgelegt sind, verwenden Sie den folgenden Befehl, um die Protokolle für den Endpunkt abzurufen. Ersetzen Sie <endpointname> durch den Namen des Endpunkts und <deploymentname> durch die Bereitstellung.

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

  4. Überprüfen Sie die Protokolle, um zu sehen, ob es ein Problem bei der Ausführung des Bewertungscodes gibt, wenn Sie eine Anforderung an die Bereitstellung übermitteln.

Probleme beim Rückschlussserver

Dieser Abschnitt bietet grundlegende Tipps zur Problembehandlung für den HTTP-Rückschlussserver für Azure Machine Learning.

Installierte Pakete prüfen

Führen Sie die folgenden Schritte aus, um Probleme mit installierten Paketen zu beheben.

  1. Sammeln Sie Informationen zu installierten Paketen und Versionen für Ihre Python-Umgebung.

  2. Bestätigen Sie, dass die in der Umgebungsdatei angegebene Version des Python-Pakets azureml-inference-server-http der Version des HTTP-Rückschlussservers für Azure Machine Learning entspricht, die im Startprotokoll angezeigt wird.

    In einigen Fällen installiert der PIP-Abhängigkeitskonfliktlöser unerwartete Paketversionen. Möglicherweise müssen Sie pip ausführen, um installierte Pakete und Versionen zu korrigieren.

  3. Wenn Sie Flask oder zugehörige Abhängigkeiten in Ihrer Umgebung angegeben haben, entfernen Sie diese Elemente.

    • Zu den abhängigen Paketen zählen flask, jinja2, itsdangerous, werkzeug, markupsafe und click.
    • flask wird als Abhängigkeit im Serverpaket aufgeführt. Der beste Ansatz besteht darin, dem Rückschlussserver die Installation des Pakets flask zu ermöglichen.
    • Wenn der Rückschlussserver für die Unterstützung neuer Flask-Versionen konfiguriert ist, empfängt der Server die Paketupdates automatisch, sobald diese verfügbar sind.

Überprüfen der Serverversion

Das Serverpaket azureml-inference-server-http wird in PyPI veröffentlicht. Auf der PyPI-Seite werden das Änderungsprotokoll und alle vorherigen Versionen aufgeführt.

Wenn Sie eine frühere Paketversion verwenden, aktualisieren Sie Ihre Konfiguration auf die aktuelle Version. In der folgenden Tabelle sind stabile Versionen, häufige Probleme und empfohlene Anpassungen zusammengefasst:

Paketversion Beschreibung Problem Lösung
0.4.x Gebündelt in Trainingsimages bis 20220601 und den azureml-defaults-Paketversionen .1.34 bis 1.43. Die aktuelle stabile Version ist 0.4.13. Bei Serverversionen vor 0.4.11 treten möglicherweise Flask-Abhängigkeitsprobleme wie z. B. "can't import name Markup from jinja2" auf. Aktualisieren Sie nach Möglichkeit auf Version 0.4.13 oder 0.8.x, die aktuelle Version.
0.6.x Vorinstalliert in Rückschlussimages bis 20220516. Die aktuelle stabile Version ist 0.6.1. – –
0.7.x Unterstützt Flask 2. Die aktuelle stabile Version ist 0.7.7. – –
0.8.x Das Protokollformat wurde geändert. Der Support für Python 3.6 wurde eingestellt. – –

Überprüfen der Paketabhängigkeiten

Die wichtigsten abhängigen Pakete für das Serverpaket azureml-inference-server-http sind:

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

Wenn Sie in Ihrer Python-Umgebung das Paket azureml-defaults angegeben haben, ist das Paket azureml-inference-server-http ein abhängiges Paket. Die Abhängigkeit wird automatisch installiert.

Tipp

Wenn Sie das Python SDK v1 verwenden und in Ihrer Python-Umgebung nicht explizit azureml-defaults angeben, fügt das SDK das Paket möglicherweise automatisch hinzu. Die Paketversion ist jedoch relativ zur SDK-Version gesperrt. Wenn die SDK-Version 1.38.0 lautet, wird den PIP-Anforderungen der Umgebung beispielsweise der Eintrag azureml-defaults==1.38.0 hinzugefügt.

TypeError während des Serverstarts

Möglicherweise tritt beim Serverstart der folgende TypeError auf:

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

Dieser Fehler tritt auf, wenn Flask 2 in Ihrer Python-Umgebung installiert ist, aber Ihre Version des Pakets azureml-inference-server-http Flask 2 nicht unterstützt. Unterstützung für Flask 2 ist in Version 0.7.0 und höher des Pakets azureml-inference-server-http sowie in Version 1.44 und höher des Pakets azureml-defaults verfügbar.

  • Wenn Sie das Flask 2-Paket nicht in einem Azure Machine Learning-Docker-Image verwenden, verwenden Sie die aktuelle Version des Pakets azureml-inference-server-http oder azureml-defaults.

  • Wenn Sie das Flask 2-Paket in einem Azure Machine Learning-Docker-Image verwenden, stellen Sie sicher, dass die Version für die Imageerstellung Juli 2022 oder neuer ist.

    Sie können die Imageversion in den Containerprotokollen finden. Zum Beispiel:

    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 |

    Das Builddatum des Images wird nach der Notation Materialization Build angezeigt. Im vorherigen Beispiel ist die Imageversion 20220708 oder der 8. Juli 2022. Das Image in diesem Beispiel ist mit Flask 2 kompatibel.

    Wenn in Ihrem Containerprotokoll keine Meldung dieser Art angezeigt wird, ist Ihr Image veraltet und sollte aktualisiert werden. Wenn Sie ein CUDA (Compute Unified Device Architecture)-Image verwenden und kein neueres Image finden, überprüfen Sie unter AzureML-Containers, ob Ihr Image veraltet ist. Dort finden Sie designierte Ersatzimages für veraltete Images.

    Wenn Sie einen Server mit einem Onlineendpunkt verwenden, können Sie die Protokolle auch unter Protokolle auf der Seite Endpunkte in Azure Machine Learning Studio finden.

Wenn Sie SDK v1 für die Bereitstellung verwenden und in Ihrer Bereitstellungskonfiguration nicht explizit ein Image angeben, wendet der Server das Paket openmpi4.1.0-ubuntu20.04 mit einer Version an, die Ihrem lokalen SDK-Toolset entspricht. Die installierte Version ist jedoch möglicherweise nicht die aktuelle verfügbare Version des Images.

Für die SDK-Version 1.43 installiert der Server standardmäßig die Paketversion openmpi4.1.0-ubuntu20.04:20220616, die jedoch nicht mit SDK 1.43 kompatibel ist. Stellen Sie sicher, dass Sie das neueste SDK für Ihre Bereitstellung verwenden.

Wenn Sie das Image nicht aktualisieren können, können Sie das Problem vorübergehend umgehen, indem Sie die Einträge azureml-defaults==1.43 oder azureml-inference-server-http~=0.4.13 in Ihrer Umgebungsdatei anheften. Diese Einträge weisen den Server an, die ältere Version mit flask 1.0.x zu installieren.

ImportError oder ModuleNotFoundError während des Serverstarts

Während dem Serverstart kann ein Fehler vom Typ ImportError oder ModuleNotFoundError für bestimmte Modulen wie opencensus, jinja2, markupsafe oder click auftreten. Das folgende Beispiel zeigt die Fehlermeldung:

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

Die Import- und Modulfehler treten auf, wenn Sie die Version 0.4.10 oder frühere Versionen des Servers verwenden, welche die Flask-Abhängigkeit nicht an eine kompatible Version anheften. Um das Problem zu verhindern, installieren Sie eine neuere Version des Servers.

Andere häufige Probleme

Andere häufige Probleme bei Onlineendpunkten beziehen sich auf die Conda-Installation und die Autoskalierung.

Probleme bei der Conda-Installation

Probleme mit der MLflow-Bereitstellung sind in der Regel auf Probleme bei der Installation der in der Datei conda.yml angegebenen Benutzerumgebung zurückzuführen.

Probieren Sie zum Debuggen von Conda-Installationsproblemen die folgenden Schritte aus:

  1. Überprüfen Sie die Conda-Installationsprotokolle. Wenn der Container abstürzte oder sein Start zu lange dauerte, konnte das Conda-Umgebungsupdate wahrscheinlich nicht ordnungsgemäß aufgelöst werden.
  2. Installieren Sie die mlflow-Conda-Datei lokal mit dem Befehl conda env create -n userenv -f <CONDA_ENV_FILENAME>.
  3. Wenn lokal Fehler auftreten, versuchen Sie vor der erneuten Bereitstellung, die Conda-Umgebung aufzulösen und eine funktionale Umgebung zu erstellen.
  4. Wenn der Container abstürzt, auch wenn er lokal aufgelöst wird, ist die für die Bereitstellung verwendete SKU-Größe unter Umständen zu klein.
    • Die Conda-Paketinstallation erfolgt zur Laufzeit. Wenn also die SKU-Größe zu klein ist, um alle Pakete in der Umgebungsdatei conda.yml zu berücksichtigen, kann der Container abstürzen.
    • Eine VM des Typs Standard_F4s_v2 ist eine gute SKU-Startgröße, aber je nach den Abhängigkeiten, die in der Conda-Datei angegeben sind, benötigen Sie möglicherweise größere VMs.
    • Für Kubernetes-Onlineendpunkte muss der Kubernetes-Cluster mindestens vier vCPU-Kerne und 8 GB Arbeitsspeicher aufweisen.

Probleme mit der automatischen Skalierung

Wenn Probleme mit der Autoskalierung auftreten, lesen Sie Problembehandlung der Azure Monitor-Autoskalierung.

Für Kubernetes-Onlineendpunkte ist der Azure Machine Learning-Rückschlussrouter eine Front-End-Komponente, welche die Autoskalierung für alle Modellimplementierungen im Kubernetes-Cluster verarbeitet. Weitere Informationen finden Sie unter Autoskalierung des Kubernetes-Rückschlussroutings.

Zugehöriger Inhalt