Problembehandlung bei der Bereitstellung und Bewertung von Onlineendpunkten

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

Erfahren Sie, wie Sie gängige Probleme bei der Bereitstellung und Bewertung von Azure Machine Learning-Onlineendpunkten lösen.

Dieses Dokument ist so strukturiert, wie Sie die Problembehandlung durchführen 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.

Im Abschnitt HTTP-Statuscodes wird beschrieben, welche Aufruf- und Vorhersagefehler und HTTP-Statuscodes beim Bewerten von Endpunkten mit REST-Anforderungen zusammengehören.

Voraussetzungen

Lokale Bereitstellung

Bei der lokalen Bereitstellung wird ein Modell in einer lokalen Docker-Umgebung bereitgestellt. 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.

Für die lokale Bereitstellung werden das Erstellen, Aktualisieren und Löschen eines lokalen Endpunkts unterstützt. Darüber hinaus können Sie hierbei Protokolle aufrufen bzw. vom Endpunkt abrufen.

Fügen Sie dem entsprechenden CLI-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

Im Rahmen der lokalen Bereitstellung werden die folgenden Schritte ausgeführt:

  • Docker erstellt entweder ein neues Containerimage oder pullt ein vorhandenes Image aus dem lokalen Docker-Cache. Ein vorhandenes Image wird verwendet, falls für ein Image eine Übereinstimmung mit dem Umgebungsteil der Spezifikationsdatei besteht.
  • Docker startet einen neuen Container mit bereitgestellten lokalen Artefakten, z. B. Modell- und Codedateien.

Weitere Informationen finden Sie unter „Lokales Bereitstellen“ in Bereitstellen und Bewerten eines Machine Learning-Modells.

Tipp

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

Conda-Installation

Im Allgemeinen sind Probleme mit der MLflow-Bereitstellung auf Probleme mit der Installation der in der Datei conda.yaml angegebenen Benutzerumgebung zurückzuführen.

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

  1. Überprüfen Sie die Protokolle für die Conda-Installation. Wenn der Container abgestürzt ist oder sein Start zu lange dauert, wurde wahrscheinlich das Conda-Umgebungsupdate nicht ordnungsgemäß aufgelöst.

  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.

    1. Die Conda-Paketinstallation erfolgt zur Laufzeit. Falls also die SKU-Größe zu klein ist, um alle Pakete in der Umgebungsdatei conda.yaml zu berücksichtigen, stürzt der Container möglicherweise ab.
    2. Eine VM vom Typ „Standard_F4s_v2“ ist eine gute SKU-Anfangsgröße. Je nach den in der Conda-Datei angegebenen Abhängigkeiten sind jedoch möglicherweise größere SKUs erforderlich.
    3. Für einen Kubernetes-Onlineendpunkt muss der Kubernetes-Cluster mindestens 4 vCPU-Kerne und 8 GB Arbeitsspeicher aufweisen.

Abrufen von Containerprotokollen

Sie können keinen direkten Zugriff auf den virtuellen Computer erhalten, auf dem das Modell bereitgestellt wird. Es ist aber möglich, Protokolle aus einigen Containern abzurufen, die auf dem virtuellen Computer ausgeführt werden. Die Menge der Informationen hängt vom Status der Bereitstellung ab. Wenn der angegebene Container betriebsbereit ist und ausgeführt wird, wird die Konsolenausgabe angezeigt. Andernfalls erhalten Sie eine Meldung mit dem Hinweis, es später noch einmal zu versuchen.

Es gibt zwei Arten von Containern, aus denen Sie die Protokolle abrufen können:

  • Rückschlussserver: Protokolle enthalten das Konsolenprotokoll (vom Rückschlussserver), das die Ausgabe der Druck-/Protokollierungsfunktionen aus Ihrem Bewertungsskript (score.py-Code) enthält.
  • Speicherinitialisierer: Protokolle 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.

Verwenden Sie den folgenden CLI-Befehl, um die Protokollausgabe für einen Container anzuzeigen:

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

Fügen Sie diesen Befehlen --resource-group und --workspace-name hinzu, falls Sie diese Parameter noch nicht mit az configure festgelegt haben.

Um zu erfahren, wie Sie diese Parameter festlegen können und ob derzeit Werte festgelegt sind, führen Sie Folgendes aus:

az ml online-deployment get-logs -h

Standardmäßig werden die Protokolle per Pullvorgang vom Rückschlussserver abgerufen.

Hinweis

Stellen Sie sicher, dass Sie bei Verwendung der Python-Protokollierung die richtige Protokolliergrad-Reihenfolge für die Nachrichten nutzen, die in Protokollen veröffentlicht werden sollen. Beispiel: INFO.

Sie können Protokolle auch aus dem Container mit dem Speicherinitialisierer abrufen, indem Sie –-container storage-initializer übergeben.

Fügen Sie den Befehlen --help bzw. --debug hinzu, um weitere Informationen zu erhalten.

Bei einem Kubernetes-Onlineendpunkt können die Administratoren direkt auf den Cluster zugreifen, in dem Sie das Modell bereitstellen. Dadurch können sie das Protokoll in Kubernetes flexibler überprüfen. Beispiel:

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

Anforderungsablaufverfolgung

Es gibt zwei unterstützte Ablaufverfolgungsheader:

  • x-request-id ist für die Serverablaufverfolgung reserviert. Wir überschreiben diesen Header, um sicherzustellen, dass es sich um eine gültige GUID handelt.

    Hinweis

    Wenn Sie ein Supportticket für eine fehlgeschlagene Anforderung erstellen, fügen Sie die ID der fehlgeschlagenen Anforderung an, um die Bearbeitung zu beschleunigen.

  • x-ms-client-request-id ist für Szenarien mit Clientablaufverfolgung verfügbar. Dieser Header wird so bereinigt, dass nur alphanumerische Zeichen, Bindestriche und Unterstriche akzeptiert werden. Außerdem wird er wird er beim Erreichen von 40 Zeichen abgeschnitten.

Häufige Bereitstellungsfehler

Die folgende Liste zeigt die häufigen Bereitstellungsfehlern, die als Teil des Betriebsstatus der Bereitstellung gemeldet werden:

Wenn Sie eine Kubernetes-Onlinebereitstellung erstellen oder aktualisieren, werden häufig Fehler speziell für Kubernetes-Bereitstellungen angezeigt.

FEHLER: ImageBuildFailure

Dieser Fehler wird zurückgegeben, wenn die Umgebung (Docker-Image) erstellt wird. Sie können das Buildprotokoll auf weitere Informationen zu den Fehlern überprüfen. Das Buildprotokoll befindet sich im Standardspeicher für Ihren Azure Machine Learning-Arbeitsbereich. Der genaue Speicherort wird unter Umständen im Fehler zurückgegeben. Beispielsweise "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

Die folgende Liste enthält häufige Fehlerszenarien für den Imagebuild:

Wir empfehlen außerdem, die standardmäßigen Testeinstellungen zu überprüfen, wenn Sie ImageBuild-Timeouts erleben.

Autorisierungsfehler bei der Containerregistrierung

Wenn die Fehlermeldung "container registry authorization failure" erwähnt, bedeutet dies, dass Sie nicht auf die Containerregistrierung mit den aktuellen Anmeldeinformationen zugreifen können. Dieser Fehler kann dadurch verursacht werden, dass die Schlüssel einer Arbeitsbereichsressource nicht synchron sind und die automatische Synchronisierung einige Zeit dauert. Sie können jedoch manuell eine Synchronisierung von Schlüsseln aufrufen. Dadurch wird der Autorisierungsfehler möglicherweise behoben.

Bei Containerregistrierungen, die sich hinter einem virtuellen Netzwerk befinden, kann dieser Fehler auch auftreten, wenn sie falsch eingerichtet wurden. Sie müssen überprüfen, ob das virtuelle Netzwerk ordnungsgemäß eingerichtet worden ist.

Compute-Instanz für die Imageerstellung in einem privaten Arbeitsbereich mit VNet nicht festgelegt

Wenn die Fehlermeldung "failed to communicate with the workspace's container registry" erwähnt und Sie virtuelle Netzwerke verwenden und die Azure Container Registry-Instanz des Arbeitsbereichs privat und mit einem privaten Endpunkt konfiguriert ist, müssen Sie Azure Container Registry aktivieren, um das Erstellen von Images im virtuellen Netzwerk zuzulassen.

Generischer Fehler bei der Imageerstellung

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

Es wird empfohlen, eine lokale Bereitstellung zu verwenden, um Ihre Modelle vor der Bereitstellung in der Cloud lokal zu testen und zu debuggen.

ERROR: Kontingenterschöpft

Die folgende Liste enthält häufige Ressourcen, bei denen die Kontingente bei der Nutzung von Azure-Diensten aufgebraucht werden könnten:

Zusätzlich enthält die folgende Liste die häufigen Ressourcen, für die das Kontingent möglicherweise nur für den Kubernetes-Onlineendpunkt überschritten wird:

CPU-Kontingent

Vor der Bereitstellung eines Modells müssen Sie über ein ausreichendes Computekontingent verfügen. Anhand dieses Kontingents wird 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.

Eine mögliche Lösung ist die Durchführung einer Überprüfung darauf, ob ungenutzte Bereitstellungen vorhanden sind, die Sie löschen können. Alternativ können Sie auch eine Anforderung für eine Kontingenterhöhung übermitteln.

Clusterkontingent

Dieses Problem tritt auf, wenn Sie nicht über ein genügendes Azure Machine Learning Compute-Clusterkontingent verfügen. Dieses Kontingent definiert die Gesamtzahl von Clustern, die pro Abonnement gleichzeitig verwendet werden können, um CPU- oder GPU-Knoten in Azure Cloud bereitzustellen.

Eine mögliche Lösung ist die Durchführung einer Überprüfung darauf, ob ungenutzte Bereitstellungen vorhanden sind, die Sie löschen können. Alternativ können Sie auch eine Anforderung für eine Kontingenterhöhung übermitteln. Stellen Sie sicher, dass Sie für diese Anforderung einer Kontingenterhöhung als Kontingenttyp Machine Learning Service: Cluster Quota auswählen.

Datenträgerkontingent

Dieses Problem tritt auf, wenn die Größe des Modells größer als der verfügbare Speicherplatz ist und das Modell nicht heruntergeladen werden kann. Probieren Sie eine SKU mit mehr Speicherplatz aus, oder verringern Sie die Image- und Modellgröße.

Arbeitsspeicherkontingent

Dieses Problem tritt auf, wenn der Speicherbedarf des Modells größer als der verfügbare Arbeitsspeicher 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 der Grenzwert für die Rollenzuweisung erreicht worden ist, versuchen Sie, einige nicht verwendete Rollenzuweisungen in diesem Abonnement zu löschen. Sie können alle Rollenzuweisungen im Azure-Portal im Menü „Zugriffssteuerung“ überprüfen.

Endpunktkontingent

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

Kubernetes-Kontingent

Dieses Problem tritt auf, wenn die angeforderte CPU oder der angeforderte Arbeitsspeicher bereitgestellt werden kann, weil die Knoten für diese Bereitstellung nicht planbar sind. Beispielsweise können Knoten abgesperrt oder anderweitig nicht verfügbar sein.

Die Fehlermeldung weist in der Regel darauf hin, dass die Ressource im Cluster nicht ausreicht, z. B. OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods..., was bedeutet, dass es zu viele Pods im Cluster gibt und nicht genügend Ressourcen vorhanden sind, um das neue Modell entsprechend Ihrer Anforderung bereitzustellen.

Sie können die folgenden Lösungsschritte ausprobieren, um das Problem zu beheben:

  • Für IT-Operators, die den Kubernetes-Cluster verwalten, können Sie versuchen, weitere Knoten hinzuzufügen oder einige nicht verwendete Pods im Cluster zu löschen, um einige Ressourcen freizugeben.
  • Für Machine Learning-Techniker, die Modelle bereitstellen, können Sie versuchen, die Ressourcenanforderung Ihrer Bereitstellung zu reduzieren:
    • Wenn Sie die Ressourcenanforderung direkt im Abschnitt „Bereitstellungskonfiguration über Ressource“ definieren, können Sie versuchen, die Ressourcenanforderung zu reduzieren.
    • Wenn Sie instance type zum Definieren von Ressourcen für die Modellimplementierung verwenden, können Sie sich an die IT-Operatoren wenden, um die Ressourcenkonfiguration des Instanztyps anzupassen. Weitere Informationen finden Sie unter Verwalten des Kubernetes-Instanztyps.

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 bei der Bereitstellung angegebene Datei score.py auszuführen, wird von Azure ein Container mit allen Ressourcen erstellt, die für score.py benötigt werden, und das Bewertungsskript für den Container ausgeführt.

Wenn Ihr Container nicht gestartet werden konnte, bedeutet dies, dass die Bewertung nicht stattfinden konnte. Es könnte sein, dass der Container mehr Ressourcen anfordert, als instance_type unterstützen kann. In diesem Fall sollten Sie erwägen, das instance_type-Element der Onlinebereitstellung zu aktualisieren.

Führen Sie Folgendes aus, um die genaue Ursache für einen Fehler zu ermitteln:

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

ERROR: Falsches Argument

Die folgende Liste enthält die Gründe, warum dieser Fehler auftreten könnte, wenn Sie entweder einen verwalteten Onlineendpunkt oder einen Kubernetes-Onlineendpunkt verwenden:

Die folgende Liste enthält die Gründe, aus denen dieser Fehler nur bei Verwendung eines Kubernetes-Onlineendpunkts auftreten könnte:

Das Abonnement ist nicht vorhanden.

Das eingegebene Azure-Abonnement muss vorhanden sein. Dieser Fehler tritt auf, wenn wir das Azure-Abonnement, auf das verwiesen wurde, nicht finden können. Dieser Fehler ist wahrscheinlich auf einen Tippfehler in der Abonnement-ID zurückzuführen. Überprüfen Sie erneut, ob die Abonnement-ID ordnungsgemäß eingegeben wurde und ob sie derzeit aktiv ist.

Weitere Informationen zu Azure-Abonnements finden Sie im Abschnitt Voraussetzungen.

Autorisierungsfehler

Nachdem Sie die Computeressource (beim Erstellen einer Bereitstellung) bereitgestellt haben, versucht Azure, das Benutzercontainerimage aus der Azure Container Registry (ACR) des Arbeitsbereichs abzurufen. Es versucht, das Benutzermodell und Codeartefakte aus dem Arbeitsbereichsspeicherkonto in den Benutzercontainer einzubinden.

Um diese Aktionen auszuführen, verwendet Azure verwaltete Identitäten, um auf das Speicherkonto und die Containerregistrierung zuzugreifen.

  • Wenn Sie den zugeordneten Endpunkt mit Systemseitig zugewiesene Identität erstellt haben, wird die Berechtigung für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Azure automatisch gewährt, und es sind keine weiteren Berechtigungen erforderlich.

  • Wenn Sie den zugeordneten Endpunkt mit „Benutzerseitig zugewiesener Identität“ erstellt haben, muss die verwaltete Identität des Benutzers über die Storage-Blobdaten-Leseberechtigung für das Speicherkonto des Arbeitsbereichs und über die AcrPull-Berechtigung für Azure Container Registry (ACR) für den Arbeitsbereich verfügen. Stellen Sie sicher, dass Ihre benutzerseitig zugewiesene Identität über die richtige Berechtigung verfügt.

Weitere Informationen finden Sie unter Autorisierungsfehler bei 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 Namen der Richtlinienzuweisung und die Richtliniendefinition enthalten, die Ihnen beim Debuggen dieses Fehlers helfen, und den Artikel „Azure-Richtliniendefinitionsstruktur“, in dem Tipps zur Vermeidung von Vorlagenfehlern erläutert werden.

Benutzer-Container-Image kann nicht heruntergeladen werden

Es ist möglich, dass der Benutzercontainer nicht gefunden werden konnte. Überprüfen Sie die Containerprotokolle, um weitere Details zu erhalten.

Vergewissern Sie sich, dass das Containerimage auf der ACR-Instanz des Arbeitsbereichs verfügbar ist.

Wenn das Image beispielsweise testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest lautet, sollten Sie das Repository wie folgt überprüfen: az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table.

Das Benutzermodell kann nicht heruntergeladen werden.

Es ist möglich, dass das Modell des Benutzers nicht gefunden werden kann. Überprüfen Sie die Containerprotokolle, um weitere Details zu erhalten.

Stellen Sie sicher, dass Sie das Modell für denselben Arbeitsbereich wie die Bereitstellung registriert haben. So zeigen Sie Details für ein Modell in einem Arbeitsbereich an:

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

Warnung

Sie müssen eine Version oder Bezeichnung angeben, um die Modellinformationen abzurufen.

Sie können auch überprüfen, ob die Blobs im Speicherkonto des Arbeitsbereichs vorhanden sind.

  • Wenn der Blob zum Beispiel https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl ist, können Sie mit diesem Befehl prüfen, ob er existiert:

    az storage blob exists --account-name foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`
    
  • Wenn das Blob vorhanden ist, können Sie diesen Befehl zum Abrufen der Protokolle aus dem Speicherinitialisierer 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

Dieser Fehler tritt auf, wenn Sie versuchen, ein MLflow-Modell mit einem Bereitstellungsansatz ohne Code in Verbindung mit der Legacy-Netzwerkisolationsmethode für verwaltete Onlineendpunktebereitzustellen. Dieses private Netzwerkfeature kann nicht in Verbindung mit einem MLFlow-Modellformat verwendet werden, wenn Sie die Legacy-Netzwerkisolationsmethode verwenden. Wenn Sie ein MLFlow-Modell mit dem Bereitstellungsansatz ohne Code bereitstellen müssen, versuchen Sie, ein vom Arbeitsbereich verwaltetes VNet-zu verwenden.

Ressourcenanforderungen übersteigen die Grenzen

Anforderungen für Ressourcen müssen kleiner oder gleich den Grenzwerten sein. Wenn Sie keine Grenzwerte festlegen, werden Standardwerte festgelegt, wenn Sie Ihre Rechenleistung mit einem Azure Machine Learning-Arbeitsbereich verbinden. 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 automatisch nach Bedarf skaliert. Sie wird während der k8s-extension-Installation installiert.

Diese Komponente sollte im Cluster fehlerfrei sein, mindestens ein gesundes Replikat. Sie erhalten diese Fehlermeldung, falls es nicht verfügbar ist, wenn Sie die Anforderung für die Erstellung/Aktualisierung des Kubernetes-Onlineendpunkts und der Bereitstellung auslösen.

Überprüfen Sie den Podstatus und die Protokolle, um dieses Problem zu beheben. Sie können auch versuchen, die auf dem Cluster installierte k8s-Erweiterung zu aktualisieren.

ERROR: RessourceNichtBereit

Um die bei der Bereitstellung angegebene Datei score.py auszuführen, wird von Azure ein Container mit allen Ressourcen erstellt, die für score.py benötigt werden, und das Bewertungsskript für den Container ausgeführt. Der Fehler in diesem Szenario besteht darin, dass dieser Container bei der Ausführung abstürzt, was bedeutet, dass keine Wertung stattfinden kann. Dieser Fehler tritt in folgenden Fällen auf:

  • score.py enthält einen Fehler. Verwenden Sie get-logs, um häufige Probleme zu diagnostizieren:
    • Ein Paket, das score.py zu importieren versucht, ist nicht in der Conda-Umgebung enthalten.
    • Ein Syntaxfehler.
    • Ein Fehler in der init()-Methode.
  • Wenn mit get-logs keine Protokolle generiert werden, bedeutet dies normalerweise, dass der Container nicht gestartet wurde. Versuchen Sie, die Bereitstellung stattdessen lokal durchzuführen, um dieses Problem zu beheben.
  • 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 eine längere Zeit für die Initialisierung des Containers zu erlauben. Oder probieren Sie eine größere VM-SKU aus den unterstützten VM-SKUs aus, wodurch die Initialisierung beschleunigt wird.
  • Die Einrichtung der Umgebung für den Container enthält einen Fehler, z. B. eine fehlende Abhängigkeit.
  • Wenn Sie den TypeError: register() takes 3 positional arguments but 4 were given-Fehler erhalten, überprüfen Sie die Abhängigkeit zwischen Flask v2 und azureml-inference-server-http. Weitere Informationen finden Sie unter FAQs zum Rückschluss-HTTP-Server.

ERROR: Ressource nicht gefunden

Die folgende Liste enthält die Gründe, weshalb dieser Fehler nur auftreten würde, 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. Diese Fehlermeldung kann beispielsweise angezeigt, wenn auf ein Speicherkonto verwiesen wurde, es aber unter dem angegebenen Pfad nicht gefunden werden kann. Überprüfen Sie die Ressourcen, die Sie möglicherweise zur Verfügung gestellt haben, unbedingt auf den genauen Pfad oder die Schreibweise ihrer Namen.

Weitere Informationen finden Sie unter Beheben von Fehlern des Typs „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 wurde. Zur Zeit können unsere APIs keine privaten Anmeldeinformationen für die Registrierung 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 acrPull-Rolle Ihrer privaten Registrierung der Systemidentität Ihres Onlineendpunkts zu.
  2. Geben Sie in Ihrer Umgebungsdefinition die Adresse Ihres privaten Images und die Anweisung an, das Image nicht zu ändern (zu erstellen).

Wenn die 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-API".

FEHLER: OperationCanceled

Die folgende Liste enthält die Gründe, warum dieser Fehler auftreten könnte, 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-Operationen haben eine bestimmte Prioritätsstufe und werden von der höchsten zur niedrigsten ausgeführt. Dieser Fehler tritt auf, wenn Ihr Vorgang durch einen anderen Vorgang mit höherer Priorität überschrieben wurde.

Durch einen erneuten Versuch kann der Vorgang möglicherweise ohne Abbruch durchgeführt werden.

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

Für Azure-Vorgänge gilt nach der Übermittlung eine kurze Wartezeit, während der sie eine Sperre abrufen, um Racebedingungen zu vermeiden. Dieser Fehler tritt auf, wenn der von Ihnen übermittelte Vorgang mit einem anderen Vorgang übereinstimmt. Und der andere Vorgang wartet derzeit auf die Bestätigung, dass er die Sperre erhalten hat, um fortzufahren. Dies kann darauf hindeuten, dass Sie eine ähnliche Anforderung zu früh nach der anfänglichen Anforderung übermittelt haben.

Wenn Sie den Vorgang nach einer Wartezeit von mehreren Sekunden bis zu einer Minute wiederholen, wird er möglicherweise ohne Abbruch ausgeführt.

FEHLER: SecretsInjectionError

Der Geheimnisabruf und die Geheimniseinschleusung während der Erstellung der Onlinebereitstellung verwenden die Identität, die dem Onlineendpunkt zugeordnet ist, um Geheimnisse aus den Arbeitsbereichsverbindungen und/oder Schlüsseltresoren abzurufen. Dieser Fehler tritt in folgenden Fällen auf:

  • Die Endpunktidentität verfügt nicht über die Azure RBAC-Berechtigung zum Lesen der Geheimnisse aus den Arbeitsbereichsverbindungen und/oder Schlüsseltresoren, obwohl die Geheimnisse von der Bereitstellungsdefinition als Verweise (zugeordnet zu Umgebungsvariablen) angegeben wurden. Denken Sie daran, dass es einige Zeit dauern kann, bis die Änderungen der Rollenzuweisung wirksam werden.
  • Das Format der Geheimnisverweise ist ungültig, oder die angegebenen Geheimnisse sind in den Arbeitsbereichsverbindungen und/oder 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

Obwohl wir unser Bestes tun, um einen stabilen und zuverlässigen Dienst anzubieten, läuft manchmal nicht alles nach Plan. Wenn Sie diese Fehlermeldung erhalten, bedeutet das, dass auf unserer Seite etwas nicht stimmt und wir das Problem beheben müssen. Übermitteln Sie ein Kundensupportticket mit allen zugehörigen Informationen, und wir können das Problem beheben.

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

Fehler in Bezug auf Identität und Authentifizierung:

Fehler in Bezug auf crashloopbackoff:

Fehler in Bezug auf das Bewertungsskript:

Sonstiges:

FEHLER: ACRSecretError

Die folgende Liste enthält die Gründe, weshalb dieser Fehler beim Erstellen oder Aktualisieren der Kubernetes-Onlinebereitstellungen auftreten kann:

  • Die Rollenzuweisung wurde nicht abgeschlossen. Warten Sie in diesem Fall einige Sekunden, und versuchen Sie es später noch mal.
  • Die Azure ARC-Erweiterung (für Azure Arc-Kubernetes-Cluster) oder die Azure Machine Learning-Erweiterung (für AKS) ist nicht ordnungsgemäß installiert oder konfiguriert. Versuchen Sie, die Konfiguration und den Status der Azure ARC- oder Azure Machine Learning-Erweiterung zu überprüfen.
  • Der Kubernetes-Cluster hat eine ungeeignete Netzwerkkonfiguration, überprüfen Sie den Proxy, die Netzwerkrichtlinie oder das Zertifikat.
    • Wenn Sie einen privaten AKS-Cluster verwenden, müssen private Endpunkte für ACR, Speicherkonto und Arbeitsbereich im AKS-VNet eingerichtet werden.
  • Stellen Sie sicher, dass Sie mindestens Version v1.1.25 der Azure Machine Learning-Erweiterung verwenden.

FEHLER: TokenRefreshFailed

Dieser Fehler tritt auf, weil die Erweiterung keine Anmeldeinformationen für den Prinzipal aus Azure abrufen kann, da die Kubernetes-Clusteridentität nicht ordnungsgemäß festgelegt ist. Installieren Sie die Azure Machine Learning-Erweiterung erneut, und versuchen Sie es erneut.

FEHLER: GetAADTokenFailed

Dieser Fehler tritt auf, weil das Azure AD-Token für die Kubernetes-Clusteranforderung fehlgeschlagen ist oder ein Timeout vorlag. Überprüfen Sie den Netzwerkzugriff, und versuchen Sie es dann erneut.

  • Sie können das Szenario Konfigurieren des erforderlichen Netzwerkdatenverkehrs befolgen, um den ausgehenden Proxy zu überprüfen und um sicherzustellen, dass der Cluster eine Verbindung mit dem Arbeitsbereich herstellen kann.
  • Die Arbeitsbereichsendpunkt-URL finden Sie in der Onlineendpunkt-CRD im Cluster.

Wenn es sich bei Ihrem Arbeitsbereich um einen privaten Arbeitsbereich handelt, bei dem der Zugriff auf öffentliche Netzwerke deaktiviert ist, sollte der Kubernetes-Cluster nur über die private Verbindung mit diesem privaten Arbeitsbereich kommunizieren.

  • Sie können überprüfen, ob der Zugriff auf den Arbeitsbereich den öffentlichen Zugriff zulässt. Ein AKS-Cluster kann nicht auf den privaten Arbeitsbereich zugreifen, unabhängig davon, ob er selbst öffentlich oder privat ist.
  • Weitere Informationen finden Sie unter Sichere Azure Kubernetes Service-Rückschlussumgebung.

FEHLER: ACRAuthenticationChallengeFailed

Dieser Fehler tritt auf, weil der Kubernetes-Cluster den ACR-Dienst des Arbeitsbereichs nicht erreichen kann, um eine Authentifizierungsanforderung durchzuführen. Überprüfen Sie Ihr Netzwerk, insbesondere den ACR-Zugriff auf das öffentliche Netzwerk, 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, wenn das ACR-Token des Kubernetes-Clusteraustausches fehlgeschlagen ist, weil das Azure AD-Token noch nicht autorisiert ist. Da die Rollenzuweisung einige Zeit in Anspruch nimmt, können Sie einen Moment warten und es dann erneut versuchen.

Dieser Fehler kann auch auf zu viele Anforderungen an den ACR-Dienst zu diesem Zeitpunkt zurückzuführen sein. Es sollte sich um einen vorübergehenden Fehler handeln. Sie können es später erneut versuchen.

FEHLER: KubernetesUnaccessible

Während der Bereitstellungen des Kubernetes-Modells wird kann der folgende Fehler auftreten:

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

Um diesen Fehler zu beheben, können Sie Folgendes tun:

  • Das AKS-Zertifikat für den Cluster rotieren. Weitere Informationen finden Sie unter Zertifikatsrotation in Azure Kubernetes Service (AKS).
  • Die Aktualisierung auf das neue Zertifikat sollte nach fünf (5) Stunden erfolgen, sodass Sie fünf Stunden warten und es erneut bereitstellen können.

FEHLER: ImagePullLoopBackOff

Dieser Fehler kann beim Erstellen oder Aktualisieren von Kubernetes-Onlinebereitstellungen auftreten, weil die Images nicht aus der Containerregistrierung heruntergeladen werden können. Dies führt zu einem Fehler beim Pullen der Images.

In diesem Fall können Sie für die Netzwerkrichtlinie des Clusters und die Containerregistrierung des Arbeitsbereichs überprüfen, ob der Cluster ein Image aus der Containerregistrierung pullen kann.

FEHLER: DeploymentCrashLoopBackOff

Dieser Fehler kann beim Erstellen oder Aktualisieren von Kubernetes-Onlinebereitstellungen auftreten, weil der Benutzercontainer während der Initialisierung abgestürzt ist. Für diesen Fehler gibt es zwei mögliche Ursachen:

  • Das Benutzerskript score.py weist einen Syntax- oder Importfehler auf und löst dann Ausnahmen beim Initialisieren aus.
  • Oder der Bereitstellungspod benötigt mehr Arbeitsspeicher als sein Limit.

Um diesen Fehler zu beheben, können Sie zunächst die Bereitstellungsprotokolle auf Ausnahmen in Benutzerskripts überprüfen. Wenn der Fehler weiterhin auftritt, versuchen Sie, das Speicherlimit für Ressourcen/Instanztypen zu vergrößern.

FEHLER: KubernetesCrashLoopBackOff

Die folgende Liste enthält die Gründe, weshalb dieser Fehler beim Erstellen oder Aktualisieren der Kubernetes-Onlineendpunkte/Onlinebereitstellungen auftreten kann:

  • Pods bleiben im CrashLoopBackoff-Status hängen. Sie können überprüfen, ob das Bereitstellungsprotokoll vorhanden ist und ob das Protokoll Fehlermeldungen enthält.
  • Es gibt einen Fehler in score.py, und der Container ist abgestürzt, als Ihr Bewertungscode initialisiert wurde. Sie können dem Teil FEHLER: ResourceNotReady folgen.
  • Ihr Bewertungsprozess benötigt mehr Arbeitsspeicher, und der Konfigurationsgrenzwert Ihrer Bereitstellung reicht nicht aus. Sie können versuchen, die Bereitstellung mit einem größeren Arbeitsspeicherlimit zu aktualisieren.

FEHLER: NamespaceNotFound

Dieser Fehler kann beim Erstellen oder Aktualisieren der Kubernetes-Onlineendpunkte auftreten, weil der von Ihrer Kubernetes-Compute-Instanz verwendete Namespace in Ihrem Cluster nicht verfügbar ist.

Sie können die Kubernetes-Compute-Instanz in Ihrem Arbeitsbereichsportal und den Namespace in Ihrem Kubernetes-Cluster überprüfen. Wenn der Namespace nicht verfügbar ist, können Sie die Legacy-Compute-Instanz trennen und erneut anfügen, um eine neue zu erstellen. Geben Sie dabei einen Namespace an, der in Ihrem Cluster bereits vorhanden ist.

FEHLER: UserScriptInitFailed

Dieser Fehler kann beim Erstellen oder Aktualisieren von Kubernetes-Onlinebereitstellungen auftreten, weil die Initialisierungsfunktion in der hochgeladenen score.py-Datei eine Ausnahme ausgelöst hat.

Sie können die Bereitstellungsprotokolle überprüfen, um die Ausnahmemeldung im Detail anzuzeigen und die Ausnahme zu beheben.

FEHLER: UserScriptImportError

Dieser Fehler kann beim Erstellen oder Aktualisieren von Kubernetes-Onlinebereitstellungen auftreten, weil die hochgeladene score.py-Datei nicht verfügbare Pakete importiert hat.

Sie können die Bereitstellungsprotokolle überprüfen, um die Ausnahmemeldung im Detail anzuzeigen und die Ausnahme zu beheben.

FEHLER: UserScriptFunctionNotFound

Dieser Fehler kann beim Erstellen oder Aktualisieren von Kubernetes-Onlinebereitstellungen auftreten, weil die hochgeladene score.py-Datei über keine Funktion mit Namen init() oder run() verfügt. Sie können den Code überprüfen und die Funktion hinzufügen.

FEHLER: EndpointNotFound

Dieser Fehler kann beim Erstellen oder Aktualisieren von Kubernetes-Onlinebereitstellungen auftreten, weil das System die Endpunktressource für die Bereitstellung im Cluster nicht finden kann. Sie müssen die Bereitstellung in einem vorhandenen Endpunkt erstellen oder diesen Endpunkt zuerst in Ihrem Cluster erstellen.

FEHLER: EndpointAlreadyExists

Dieser Fehler kann beim Erstellen eines Kubernetes-Onlineendpunkts auftreten, weil der zu erstellende Endpunkt bereits in Ihrem Cluster vorhanden ist.

Der Endpunktname sollte pro Arbeitsbereich und Cluster eindeutig sein, daher sollten Sie in diesem Fall einen Endpunkt mit einem anderen Namen erstellen.

FEHLER: ScoringFeUnhealthy

Dieser Fehler kann beim Erstellen/Aktualisieren eines Kubernetes-Onlineendpunkts bzw. einer Kubernetes-Onlinebereitstellung auftreten, weil der im Cluster ausgeführte Systemdienst Azureml-fe nicht gefunden wird oder fehlerhaft ist.

Um dieses Problem zu beheben, können Sie die Azure Machine Learning-Erweiterung in Ihrem Cluster erneut installieren oder aktualisieren.

FEHLER: ValidateScoringFailed

Dieser Fehler kann beim Erstellen oder Aktualisieren von Kubernetes-Onlinebereitstellungen auftreten, weil die Überprüfung der Bewertungsanforderungs-URL beim Verarbeiten der Modellbereitstellung nicht erfolgreich war.

In diesem Fall können Sie zunächst die Endpunkt-URL überprüfen und dann versuchen, die Bereitstellung erneut durchzuführen.

FEHLER: InvalidDeploymentSpec

Dieser Fehler kann beim Erstellen oder Aktualisieren von Kubernetes-Onlinebereitstellungen auftreten, weil die Bereitstellungsspezifikation ungültig ist.

In diesem Fall können Sie die Fehlermeldung überprüfen.

  • Stellen Sie sicher, dass instance count gültig ist.
  • Wenn Sie die automatische Skalierung aktiviert haben, vergewissern Sie sich, dass minimum instance count und maximum instance count gültig sind.

FEHLER: PodUnschedulable

Die folgende Liste enthält die Gründe, weshalb dieser Fehler beim Erstellen oder Aktualisieren der Kubernetes-Onlineendpunkte/Onlinebereitstellungen auftreten kann:

  • Pods können aufgrund unzureichender Ressourcen nicht für Knoten geplant werden.
  • Keine Knotenübereinstimmung mit Knotenaffinität/Knotenauswahl

Sie können folgendermaßen vorgehen, um diesen Fehler zu beheben:

  • Überprüfen Sie die node selector-Definition des verwendeten Instanztyps (instance type) und die node label-Konfiguration Ihrer Clusterknoten.
  • Überprüfen Sie instance type und die Größe der Knoten-SKU für den AKS-Cluster oder die Knotenressource für den Arc-Kubernetes-Cluster.
    • Wenn der Cluster nicht über genügend Ressourcen verfügt, können Sie die Ressourcenanforderung für den Instanztyp reduzieren oder einen anderen Instanztyp mit geringeren Ressourcenanforderungen verwenden.
  • Wenn der Cluster über keine Ressource mehr verfügt, um die Anforderung der Bereitstellung zu erfüllen, löschen Sie einige Bereitstellungen, um Ressourcen freizugeben.

FEHLER: PodOutOfMemory

Dieser Fehler kann beim Erstellen oder Aktualisieren einer Onlinebereitstellung auftreten, weil das von Ihnen für die Bereitstellung festgelegte Arbeitsspeicherlimit unzureichend ist. Sie können das Arbeitsspeicherlimit auf einen höheren Wert festlegen oder einen größeren Instanztyp verwenden, um diesen Fehler zu beheben.

FEHLER: InferencingClientCallFailed

Dieser Fehler kann beim Erstellen/Aktualisieren von Kubernetes-Onlineendpunkten oder -Onlinebereitstellungen auftreten, weil die k8s-Erweiterung des Kubernetes-Clusters nicht verbunden werden kann.

In diesem Fall können Sie Ihre Compute-Instanz trennen und dann erneut anfügen.

Hinweis

Damit Sie Fehler durch ein erneutes Anfügen behandeln können, müssen Sie die Compute-Instanz unbedingt mit der gleichen Konfiguration wie zuvor anfügen (d. h. mit dem gleichen Computenamen und Namespace), da andernfalls weitere Fehler auftreten können.

Wenn es immer noch nicht funktioniert, können Sie den Administrator, der auf den Cluster zugreifen kann, bitten, mit kubectl get po -n azureml zu überprüfen, ob die Relayserver-Pods ausgeführt werden.

Probleme mit der automatischen Skalierung

Wenn Sie Probleme mit der automatischen Skalierung haben, finden Sie weitere Informationen unter Problembehandlung für automatische Skalierung in Azure.

Für den Kubernetes-Onlineendpunkt gibt es einen Azure Machine Learning-Rückschlussrouter, bei dem es sich um eine Front-End-Komponente zum Verarbeiten der automatischen Skalierung für alle Modellimplementierungen im Kubernetes-Cluster handelt. Weitere Informationen finden Sie unter Automatische Skalierung des Kubernetes-Rückschlussroutings

Häufige Fehler bei der Modellnutzung

Die folgende Liste enthält die häufig auftretenden Fehler bei der Modellnutzung, die sich aus dem Vorgangsstatus invoke des Endpunkts ergeben.

Probleme mit dem Bandbreitengrenzwert

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

  • Verwenden Sie die Metrik „Netzwerkbytes“, um die aktuelle Bandbreitennutzung nachzuvollziehen. Weitere Informationen finden Sie unter Überwachen verwalteter Onlineendpunkte (Vorschau).
  • Es werden zwei Antworttrailer zurückgegeben, wenn der Bandbreitengrenzwert erzwungen wird:
    • ms-azureml-bandwidth-request-delay-ms: Verzögerungszeit in Millisekunden für die Übertragung des Anforderungsstreams
    • ms-azureml-bandwidth-response-delay-ms: Verzögerungszeit in Millisekunden für die Übertragung des Antwortstreams

HTTP-Statuscodes

Wenn Sie mit REST-Anforderungen auf Onlineendpunkte zugreifen, entsprechen die zurückgegebenen Statuscodes den Standardvorgaben für HTTP-Statuscodes. Dies sind ausführliche Informationen dazu, welche HTTP-Statuscodes für welche Aufruf- und Vorhersagefehler für Endpunkte gelten.

Allgemeine Fehlercodes für verwaltete Onlineendpunkte

Die folgende Tabelle enthält allgemeine Fehlercodes bei der Nutzung von verwalteten Onlineendpunkten mit REST-Anforderungen:

Statuscode Ursachentext Grund für den Code
200 OK Die Ausführung Ihres Modells war erfolgreich, und der Grenzwert für die Latenz wurde eingehalten.
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 Konzept der Endpunktauthentifizierung und Gewusst wie: Authentifizieren von Endpunkten.
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 Testeinstellungen anpassen, um eine längere 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. Azure Machine Learning hat ein System implementiert, das die parallele Verarbeitung von maximal 2 * max_concurrent_requests_per_instance * instance_count requests zu einem bestimmten Zeitpunkt erlaubt, um einen reibungslosen Betrieb zu gewährleisten. Andere Anforderungen, welche dieses Maximum überschreiten, werden abgelehnt. Sie können Ihre Modellimplementierungskonfiguration in den Abschnitten request_settings und scale_settings überprüfen, um diese Einstellungen zu verifizieren und anzupassen. Zusätzlich ist es wichtig, sicherzustellen, dass die Umgebungsvariable WORKER_COUNT ordnungsgemäß übergeben wird, wie in der YAML-Definition für RequestSettings beschrieben.

Wenn Sie die automatische Skalierung verwenden und diesen Fehler erhalten, bedeutet dies, dass Ihr Modell Anforderungen schneller erhält, als das System hochskalieren kann. Erwägen Sie in dieser Situation, Anforderungen mit einem exponentiellen Backoff erneut zu senden, um dem System die Zeit zu geben, die es zum Anpassen benötigt. Sie könnten auch die Anzahl der Instanzen erhöhen, indem Sie den Code zum Berechnen der Anzahl der Instanzen verwenden. Diese Schritte in Kombination mit dem Festlegen der automatischen Skalierung helfen sicherzustellen, dass Ihr Modell bereit ist, den Zustrom von Anforderungen zu verarbeiten.
429 Ratenbegrenzung Die Anzahl der Anforderungen pro Sekunde erreichte den Grenzwert von verwalteten Onlineendpunkten.
500 Interner Serverfehler Die von Azure Machine Learning bereitgestellte Infrastruktur ist fehlerhaft.

Allgemeine Fehlercodes für Kubernetes-Onlineendpunkte

Die folgende Tabelle enthält allgemeine Fehlercodes bei der Nutzung von Kubernetes-Onlineendpunkten mit REST-Anforderungen:

Statuscode Ursachentext Grund für den Code
409 Konfliktfehler Wenn ein Vorgang bereits ausgeführt wird, antwortet jeder neue Vorgang auf demselben Onlineendpunkt mit einem 409-Konfliktfehler. Wenn beispielsweise ein Erstellungs- oder Aktualisierungsvorgang für einen Onlineendpunkt ausgeführt wird und Sie einen neuen Löschvorgang auslösen, wird ein Fehler ausgelöst.
502 Hat eine Ausnahme ausgelöst oder ist in der run()-Methode der „score.py“-Datei abgestürzt. Wenn ein Fehler in score.py vorliegt, wenn beispielsweise ein importiertes Paket in der Conda-Umgebung nicht existiert, ein Syntaxfehler oder ein Fehler in der init()-Methode. Sie können dieser Anleitung folgen, um die Datei zu debuggen.
503 Empfangen großer 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. Sie können dieser Anleitung folgen, um 503-Statuscodes zu verhindern.
504 Timeout der Anforderung Der Statuscode 504 gibt an, dass für die Anforderung ein Timeout aufgetreten ist. Das Standardtimeout beträgt 5 Sekunden. Sie können das Timeout erhöhen oder versuchen, den Endpunkt zu beschleunigen, indem Sie unnötige Aufrufe in „score.py“ entfernen. Wenn das Problem durch diese Aktionen nicht behoben wird, können Sie dieser Anleitung folgen, um die „score.py“-Datei zu debuggen. Der Code kann sich in einem nicht reaktionsfähigen Zustand oder in einer Endlosschleife befinden.
500 Interner Serverfehler Die von Azure Machine Learning bereitgestellte Infrastruktur ist fehlerhaft.

Verhindern von 503-Statuscodes

Kubernetes-Onlinebereitstellungen unterstützen die automatische Skalierung, wodurch Replikate hinzugefügt werden können, um eine zusätzliche Last zu unterstützen. Weitere Informationen finden Sie unter Azure Machine Learning-Rückschlussrouter. Skalierungsentscheidungen werden auf der Grundlage der Auslastung der aktuellen Containerreplikate getroffen.

Es gibt zwei Möglichkeiten, die beim Verhindern des Statuscodes 503 helfen können:

Tipp

Diese beiden Ansätze können einzeln oder in Kombination verwendet werden.

  • Ändern Sie den Auslastungsgrad für die Erstellung neuer Replikate durch die automatische Skalierung. Sie können den Auslastungsgrad anpassen, indem Sie einen niedrigeren Wert für autoscale_target_utilization festlegen.

    Wichtig

    Durch diese Änderung werden Replikate nicht schneller erstellt. Stattdessen werden sie mit einem niedrigeren Schwellenwert für die Auslastung erstellt. Anstatt abzuwarten, bis der Dienst zu 70 % ausgelastet ist, werden Replikate schon bei 30 % Auslastung erstellt, wenn Sie den Wert in 30 % ändern.

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

  • Ändern Sie die Mindestanzahl der Replikate. Indem Sie die Mindestanzahl der Replikate erhöhen, wird ein größerer Pool für die Verarbeitung eingehender Spitzen bereitgestellt.

    Um die Anzahl der Instanzen zu erhöhen, könnten Sie mit diesen Codes die erforderlichen Replikate 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 Anforderungsspitzen eingehen, die die neue Mindestanzahl von Replikaten überschreiten, erhalten Sie möglicherweise wieder den Statuscode 503. Wenn sich beispielsweise der Datenverkehr Ihres Endpunkts erhöht, müssen Sie vielleicht die Mindestanzahl von Replikaten erhöhen.

Berechnen der Anzahl der Instanzen

Um die Anzahl der Instanzen zu erhöhen, können Sie mit dem folgenden Code die erforderlichen Replikate 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)

Durch CORS-Richtlinie blockiert

Onlineendpunkte (v2) unterstützen derzeit CORS (Cross-Origin Resource Sharing, ursprungsübergreifende Ressourcenfreigabe) nicht nativ. Wenn Ihre Webanwendung versucht, den Endpunkt ohne ordnungsgemäße Behandlung der CORS-Preflight-Anforderungen aufzurufen, wird die folgende Fehlermeldung angezeigt:

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.

Es wird empfohlen, Azure Functions, Azure Application Gateway oder einen beliebigen Dienst als Zwischenschicht zu verwenden, um CORS-Preflight-Anforderungen zu verarbeiten.

Häufige Probleme bei der Netzwerkisolation

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

Der Azure Machine Learning-Arbeitsbereich kann für v1_legacy_mode konfiguriert werden, 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.

Wichtig

Sprechen Sie sich mit Ihrem Netzwerksicherheitsteam ab, ehe Sie v1_legacy_mode deaktivieren. Möglicherweise wurde die Einstellung aus einem bestimmten Grund von Ihrem Netzwerksicherheitsteam aktiviert.

Informationen zum Deaktivieren von v1_legacy_modefinden Sie unter Netzwerkisolation mit v2-API.

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 dieses Befehls ähnelt dem folgenden JSON-Dokument:

{
    "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 deaktiviert wurde. 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 Container Registry-Instanz 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 Antwortdokument, ob das Feld status auf Approved festgelegt ist. Falls der Status nicht „Approved“ lautet, verwenden Sie den folgenden Befehl, um die Verbindung zu genehmigen. Ersetzen Sie <private-endpoint-name> durch den vom vorherigen 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:

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

    Die Antwort enthält eine Adresse. Diese Adresse sollte in dem vom virtuellen Netzwerk bereitgestellten Bereich liegen.

    Hinweis

    Für den Kubernetes-Onlineendpunkt sollte der Hostname des Endpunkts der CName (Domänenname) sein, der in Ihrem Kubernetes-Cluster angegeben wurde. Wenn es sich um einen HTTP-Endpunkt handelt, ist die IP-Adresse im Endpunkt-URI enthalten, den Sie direkt auf der Studio-Benutzeroberfläche abrufen können. Weitere Möglichkeiten zum Abrufen der IP-Adresse des Endpunkts finden Sie unter Schützen eines Kubernetes-Onlineendpunkts.

  3. Wenn der Hostname durch den Befehl nslookup nicht aufgelöst wird:

    Für einen verwalteten Onlineendpunkt:

    1. Überprüfen Sie, ob in der privaten DNS-Zone für das virtuelle Netzwerk ein A-Eintrag vorhanden ist.

      Verwenden Sie zum Überprüfen der Einträge den folgenden Befehl:

      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 mit einem benutzerdefinierten DNS eingerichtet wird Verwenden Ihres Arbeitsbereichs mit einem benutzerdefinierten DNS-Server, verwenden Sie den folgenden Befehl, um zu überprüfen, ob die Auflösung über benutzerdefiniertes DNS ordnungsgemäß funktioniert.

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

    Für einen Kubernetes-Onlineendpunkt:

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

    2. Darüber hinaus können Sie überprüfen, ob azureml-fe wie erwartet funktioniert. Verwenden Sie hierzu den folgenden Befehl:

      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

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

    Wenn curl HTTPS fehlschlägt (z. B. Timeout), aber HTTP funktioniert, überprüfen Sie, ob das Zertifikat gültig ist.

    Wenn die Auflösung nicht in einen Datensatz ausgeführt werden kann, überprüfen Sie, ob die Auflösung über Azure DNS (168.63.129.16) funktioniert.

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

    Wenn dies erfolgreich ist, können Sie die Probleme mit der bedingten Weiterleitung für die private Verbindung im benutzerdefinierten DNS beheben.

Onlinebereitstellungen können nicht bewertet werden

  1. Überprüfen Sie mit dem folgenden Befehl, ob die Bereitstellung erfolgreich durchgeführt wurde:

    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
    

    Tipp

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

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

  3. Wenn die Datenverkehrszuweisungen (oder der Bereitstellungsheader) ordnungsgemäß festgelegt wurden, 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> 
    

    Überprüfen Sie in den Protokollen, ob ein Problem bei der Ausführung des Bewertungscodes aufgetreten ist, wenn Sie eine Anforderung an die Bereitstellung übermitteln.

Problembehandlung beim Rückschlussserver

In diesem Abschnitt finden Sie grundlegende Tipps zur Problembehandlung für den HTTP-Rückschlussserver für Azure Machine Learning.

Grundlegende Schritte

Die grundlegenden Schritte zur Problembehandlung lauten:

  1. Sammeln Sie Versionsinformationen Ihrer Python-Umgebung.
  2. Stellen Sie sicher, dass die in der Umgebungsdatei angegebene Version des Python-Pakets azureml-inference-server-http der Version des HTTP-Rückschlussservers für Azure ML entspricht, die im Startprotokoll angezeigt wird. Manchmal führt der PIP-Abhängigkeitskonfliktlöser zu unerwarteten Versionen der installierten Pakete.
  3. Wenn Sie Flask (oder Abhängigkeiten davon) in Ihrer Umgebung angegeben haben, entfernen Sie den Eintrag. Zu den Abhängigkeiten gehören Flask, Jinja2, itsdangerous, Werkzeug, MarkupSafe und click. Flask wird im Serverpaket als Abhängigkeit aufgeführt, und am besten wird die Installation dem Server überlassen. Auf diese Weise erhalten Sie neue Flask-Versionen automatisch, wenn der Server diese unterstützt.

Serverversion

Das Serverpaket azureml-inference-server-http wird in PyPI veröffentlicht. Unser Änderungsprotokoll sowie alle vorherigen Versionen finden Sie auf unserer PyPI-Seite. Aktualisieren Sie auf die neueste Version, wenn Sie eine frühere verwenden.

  • 0.4.x: die Version, die in Trainingsimages bis 20220601 und in azureml-defaults>=1.34,<=1.43 gebündelt ist. Version 0.4.13 ist die letzte stabile Version. Wenn Sie den Server vor Version 0.4.11 verwenden, werden möglicherweise Flask-Abhängigkeitsprobleme angezeigt, z. B. „Der Name ‚Markup‘ kann nicht aus ‚jinja2‘ importiert werden“. Es wird empfohlen, nach Möglichkeit ein Upgrade auf 0.4.13 oder 0.8.x (die neueste Version) durchzuführen.
  • 0.6.x: die in Rückschlussimages bis 20220516 vorinstallierte Version. Die aktuelle stabile Version ist 0.6.1.
  • 0.7.x: die erste Version, die Flask 2 unterstützt. Die aktuelle stabile Version ist 0.7.7.
  • 0.8.x: Das Protokollformat wurde geändert, und die Unterstützung für Python 3.6 wurde eingestellt.

Paketabhängigkeiten

Die wichtigsten Pakete für den Server azureml-inference-server-http sind die folgenden:

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

Wenn Sie in Ihrer Python-Umgebung azureml-defaults angegeben haben, ist das Paket azureml-inference-server-http eine Abhängigkeit und 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 für Sie hinzu. Es ist dann jedoch an die Version gebunden, in der sich das SDK befindet. Wenn die SDK-Version beispielsweise 1.38.0 lautet, wird den PIP-Anforderungen der Umgebung azureml-defaults==1.38.0 hinzugefügt.

Häufig gestellte Fragen

1. Beim Serverstart ist der folgende Fehler aufgetreten:


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

Sie haben Flask 2 in Ihrer Python-Umgebung installiert, führen jedoch einen Server mit der Version azureml-inference-server-http aus, die Flask 2 nicht unterstützt. Unterstützung für Flask 2 wird in azureml-inference-server-http>=0.7.0, was auch in azureml-defaults>=1.44 enthalten ist.

  • Wenn Sie dieses Paket nicht in einem AzureML-Docker-Image verwenden, verwenden Sie die neueste Version von azureml-inference-server-http oder azureml-defaults.

  • Wenn Sie dieses Paket mit einem AzureML-Docker-Image verwenden, stellen Sie sicher, dass Sie ein Image verwenden, das ab Juli 2022 aufgebaut wurde. Die Imageversion ist in den Containerprotokollen verfügbar. Sie sollten ein ähnliches Protokoll wie dieses finden können:

    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 | 
    

    Das Builddatum des Images wird nach „Materialization Build“, was im obigen Beispiel 20220708 oder 8. Juli 2022 ist. Dieses Bild ist mit Flask 2 kompatibel. Wenn in Ihrem Containerprotokoll kein Banner angezeigt wird, ist Ihr Image veraltet und sollte aktualisiert werden. Wenn Sie ein CUDA-Image verwenden und kein neueres Image finden können, überprüfen Sie, ob Ihr Image in Azure ML-Containern veraltet ist. In diesem Fall sollten Sie geeigneten Ersatz finden können.

  • Wenn Sie einen Server mit einem Onlineendpunkt verwenden, finden Sie die Protokolle auch unter „Bereitstellungsprotokolle“ auf der Online-Endpunktseite in Azure Machine Learning Studio. Wenn Sie mit SDK v1 bereitstellen und in Ihrer Bereitstellungskonfiguration kein Image explizit angeben, wird per Standard eine Version von openmpi4.1.0-ubuntu20.04 verwendet, die Ihrem lokalen SDK-Toolset entspricht, was eventuell nicht die aktuellste Version des Images ist. Beispielsweise wird SDK 1.43 standardmäßig openmpi4.1.0-ubuntu20.04:20220616 verwenden, was nicht kompatibel ist. Stellen Sie sicher, dass Sie das neueste SDK für Ihre Bereitstellung verwenden.

  • Wenn Sie aus irgendeinem Grund das Image nicht aktualisieren können, können Sie das Problem vorübergehend vermeiden, indem Sie azureml-defaults==1.43 oder azureml-inference-server-http~=0.4.13 anheften. was den Server der älteren Version mit Flask 1.0.x installiert.

2. Die Fehler ImportError oder ModuleNotFoundError sind auf den Modulen opencensus, jinja2, MarkupSafe oder click während des Startvorgangs wie folgt aufgetreten:

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

Ältere Versionen (<= 0.4.10) des Servers haben die Abhängigkeit von Flask nicht an kompatible Versionen angeheftet. Dies wurde in der neuesten Version des Servers behoben.

Nächste Schritte