Risoluzione dei problemi relativi alla distribuzione e all'assegnazione dei punteggi agli endpoint online

  • Articolo

SI APPLICA A:estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)Python SDK azure-ai-ml v2 (corrente)

Informazioni su come risolvere i problemi comuni nella distribuzione e nell'assegnazione dei punteggi degli endpoint online di Azure Machine Learning.

Questo documento è strutturato nel modo in cui è consigliabile affrontare la risoluzione dei problemi:

  1. Usare la distribuzione locale per testare ed eseguire il debug dei modelli in locale prima della distribuzione nel cloud.
  2. Usare i log dei contenitori per facilitare il debug dei problemi.
  3. Comprendere gli errori di distribuzione comuni che potrebbero verificarsi e come risolverli.

La sezione Codici di stato HTTP illustra il mapping degli errori di chiamata e stima ai codici di stato HTTP durante l'assegnazione dei punteggi agli endpoint con richieste REST.

Prerequisiti

Distribuire in locale

La distribuzione locale consiste nel distribuire un modello in un ambiente Docker locale. La distribuzione locale è utile per il test e il debug prima della distribuzione nel cloud.

Suggerimento

È anche possibile usare il pacchetto Python del server HTTP di inferenza di Azure Machine Learning per eseguire il debug dello script di assegnazione dei punteggi in locale. Il debug con il server di inferenza consente di eseguire il debug dello script di assegnazione dei punteggi prima della distribuzione negli endpoint locali in modo che sia possibile eseguire il debug senza influire sulle configurazioni del contenitore di distribuzione.

La distribuzione locale supporta la creazione, l'aggiornamento e l'eliminazione di endpoint locali e consente di richiamare e ottenere log dagli endpoint.

Per usare la distribuzione locale, aggiungere --local al comando dell'interfaccia della riga di comando appropriato:

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

Come parte della distribuzione locale, eseguire i passaggi seguenti:

  • Docker compila una nuova immagine del contenitore o esegue il pull di un'immagine esistente dalla cache Docker locale. Se è presente un'immagine esistente che corrisponde alla parte dell'ambiente del file di specifica, viene usata un'immagine esistente.
  • Docker avvia un nuovo contenitore con artefatti locali montati, ad esempio file di modello e di codice.

Per altre informazioni, vedere Distribuire localmente in Distribuire e assegnare punteggi a un modello di Machine Learning.

Suggerimento

Usare Visual Studio Code per testare ed eseguire il debug degli endpoint in locale. Per altre informazioni, vedere Eseguire il debug degli endpoint online in locale in Visual Studio Code.

Installazione di Conda

In genere, i problemi relativi alla distribuzione di MLflow derivano dai problemi relativi all'installazione dell'ambiente utente specificato nel conda.yaml file.

Per eseguire il debug dei problemi di installazione di Conda, seguire questa procedura:

  1. Controllare i log per l'installazione di conda. Se il contenitore si arresta in modo anomalo o richiede troppo tempo per l'avvio, è probabile che l'aggiornamento dell'ambiente conda non sia riuscito a risolvere correttamente.

  2. Installare il file conda mlflow in locale con il comando conda env create -n userenv -f <CONDA_ENV_FILENAME>.

  3. Se sono presenti errori in locale, provare a risolvere l'ambiente conda e a crearne uno funzionale prima della ridistribuzione.

  4. Se il contenitore si arresta in modo anomalo anche se viene risolto in locale, le dimensioni dello SKU usate per la distribuzione potrebbero essere troppo piccole.

    1. L'installazione del pacchetto Conda viene eseguita in fase di esecuzione, quindi se le dimensioni dello SKU sono troppo piccole per contenere tutti i pacchetti descritti in dettaglio nel conda.yaml file di ambiente, il contenitore potrebbe arrestarsi in modo anomalo.
    2. Una macchina virtuale Standard_F4s_v2 è una buona dimensione iniziale dello SKU, ma potrebbero essere necessarie dimensioni maggiori a seconda delle dipendenze specificate nel file conda.
    3. Per l'endpoint online kubernetes, il cluster Kubernetes deve avere almeno 4 core vCPU e 8 GB di memoria.

Ottenere i log dei contenitori

Non è possibile ottenere l'accesso diretto alla macchina virtuale in cui viene distribuito il modello. Tuttavia, è possibile ottenere i log da alcuni dei contenitori in esecuzione nella macchina virtuale. La quantità di informazioni che si ottiene dipende dallo stato di provisioning della distribuzione. Se il contenitore specificato è operativo, viene visualizzato l'output della console; in caso contrario, viene visualizzato un messaggio per riprovare più tardi.

Esistono due tipi di contenitori da cui è possibile ottenere i log:

  • Server di inferenza: i log includono il log della console (dal server di inferenza) che contiene l'output delle funzioni di stampa/registrazione dallo script di assegnazione dei punteggi (codice score.py).
  • Inizializzatore di archiviazione: i log contengono informazioni che specificano se il codice e i dati del modello sono stati scaricati correttamente nel contenitore. Il contenitore viene eseguito prima dell'avvio dell'esecuzione del contenitore del server di inferenza.

Per visualizzare l'output del log da un contenitore, usare il comando dell'interfaccia della riga di comando seguente:

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

or

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

Aggiungere --resource-group e --workspace-name a questi comandi se questi parametri non sono già stati impostati tramite az configure.

Per visualizzare informazioni su come impostare questi parametri e se sono stati impostati valori, eseguire:

az ml online-deployment get-logs -h

Per impostazione predefinita, i log vengono estratti dal server di inferenza.

Nota

Se si usa la registrazione python, assicurarsi di usare l'ordine di livello di registrazione corretto per la pubblicazione dei messaggi nei log. Ad esempio, INFO.

È anche possibile ottenere i log dal contenitore dell'inizializzatore di archiviazione passando –-container storage-initializer.

Aggiungere --help e/o --debug ai comandi per visualizzare altre informazioni.

Per l'endpoint online kubernetes, gli amministratori sono in grado di accedere direttamente al cluster in cui si distribuisce il modello, che è più flessibile per controllare il log in Kubernetes. Ad esempio:

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

Traccia delle richieste

Esistono due intestazioni di traccia supportate:

  • x-request-id è riservato per la traccia del server. Si esegue l'override di questa intestazione per assicurarsi che sia un GUID valido.

    Nota

    Quando si crea un ticket di supporto per una richiesta non riuscita, allegare l'ID richiesta non riuscita per accelerare l'indagine.

  • x-ms-client-request-id è disponibile per gli scenari di traccia client. Questa intestazione viene sanificata per accettare solo caratteri alfanumerici, trattini e caratteri di sottolineatura e viene troncata a un massimo di 40 caratteri.

Errori di distribuzione comuni

L'elenco seguente è costituito da errori di distribuzione comuni segnalati come parte dello stato dell'operazione di distribuzione:

Se si sta creando o aggiornando una distribuzione online di Kubernetes, è possibile visualizzare errori comuni specifici per le distribuzioni kubernetes.

ERRORE: ImageBuildFailure

Questo errore viene restituito quando viene compilato l'ambiente (immagine Docker). È possibile controllare il log di compilazione per altre informazioni sugli errori. Il log di compilazione si trova nella risorsa di archiviazione predefinita per l'area di lavoro di Azure Machine Learning. La posizione esatta potrebbe essere restituita come parte dell'errore. Ad esempio: "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

L'elenco seguente contiene scenari comuni di errore di compilazione delle immagini:

È anche consigliabile esaminare le impostazioni predefinite del probe se sono presenti timeout di ImageBuild.

Errore di autorizzazione del registro contenitori

Se il messaggio di errore indica che non è possibile accedere al registro contenitori "container registry authorization failure" con le credenziali correnti. La desynchronizzazione delle chiavi di una risorsa dell'area di lavoro può causare questo errore e la sincronizzazione automatica richiede tempo. Tuttavia, è possibile chiamare manualmente per una sincronizzazione delle chiavi, che potrebbe risolvere l'errore di autorizzazione.

Anche i registri contenitori che si trovano dietro una rete virtuale possono riscontrare questo errore se la configurazione non è corretta. È necessario verificare che la rete virtuale sia configurata correttamente.

Calcolo di compilazione immagine non impostato in un'area di lavoro privata con rete virtuale

Se il messaggio di errore indica "failed to communicate with the workspace's container registry" e si usano reti virtuali e il Registro Azure Container dell'area di lavoro è privato e configurato con un endpoint privato, è necessario abilitare Registro Azure Container per consentire la creazione di immagini nella rete virtuale.

Errore di compilazione dell'immagine generica

Come indicato in precedenza, è possibile controllare il log di compilazione per altre informazioni sull'errore. Se non viene rilevato alcun errore ovvio nel log di compilazione e l'ultima riga è Installing pip dependencies: ...working..., una dipendenza potrebbe causare l'errore. L'aggiunta delle dipendenze della versione nel file conda può risolvere questo problema.

È anche consigliabile eseguire la distribuzione in locale per testare ed eseguire il debug dei modelli in locale prima di eseguire la distribuzione nel cloud.

ERRORE: OutOfQuota

L'elenco seguente è costituito da risorse comuni che potrebbero esaurire la quota quando si usano i servizi di Azure:

Inoltre, l'elenco seguente è costituito da risorse comuni che potrebbero esaurire la quota solo per l'endpoint online Kubernetes:

CPU Quota

Prima di distribuire un modello, è necessario avere una quota di calcolo sufficiente. Questa quota definisce la quantità di core virtuali disponibili per ogni sottoscrizione, per area di lavoro, per SKU e per area. Ogni distribuzione sottrae dalla quota disponibile e la aggiunge nuovamente dopo l'eliminazione, in base al tipo di SKU.

Una possibile mitigazione consiste nel verificare se sono presenti distribuzioni inutilizzate che è possibile eliminare. In alternativa, è possibile inviare una richiesta di aumento della quota.

Quota cluster

Questo problema si verifica quando la quota del cluster di calcolo di Azure Machine Learning non è sufficiente. Questa quota definisce il numero totale di cluster che potrebbero essere in uso contemporaneamente per sottoscrizione per distribuire nodi CPU o GPU nel cloud di Azure.

Una possibile mitigazione consiste nel verificare se sono presenti distribuzioni inutilizzate che è possibile eliminare. In alternativa, è possibile inviare una richiesta di aumento della quota. Assicurarsi di selezionare Machine Learning Service: Cluster Quota come tipo di quota per questa richiesta di aumento della quota.

Quota disco

Questo problema si verifica quando le dimensioni del modello sono maggiori dello spazio disponibile su disco e il modello non può essere scaricato. Provare uno SKU con più spazio su disco o ridurre le dimensioni dell'immagine e del modello.

Quota di memoria

Questo problema si verifica quando il footprint di memoria del modello è maggiore della memoria disponibile. Provare uno SKU con più memoria.

Quota di assegnazione di ruolo

Quando si crea un endpoint online gestito, l'assegnazione di ruolo è necessaria per l'identità gestita per accedere alle risorse dell'area di lavoro. Se viene raggiunto il limite di assegnazione di ruolo, provare a eliminare alcune assegnazioni di ruolo inutilizzate in questa sottoscrizione. È possibile controllare tutte le assegnazioni di ruolo nel portale di Azure passando al menu Controllo di accesso.

Quota endpoint

Provare a eliminare alcuni endpoint inutilizzati in questa sottoscrizione. Se tutti gli endpoint sono attivamente in uso, è possibile provare a richiedere un aumento del limite di endpoint. Per altre informazioni sul limite di endpoint, vedere Quota degli endpoint con endpoint online e endpoint batch di Azure Machine Learning.

Quota kubernetes

Questo problema si verifica quando la CPU o la memoria richiesta non è in grado di essere fornita a causa di nodi non pianificabili per questa distribuzione. Ad esempio, i nodi possono essere delimitati o altrimenti non disponibili.

Il messaggio di errore indica in genere la risorsa insufficiente nel cluster, ad esempio , OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods...il che significa che nel cluster sono presenti troppi pod e risorse non sufficienti per distribuire il nuovo modello in base alla richiesta.

Per risolvere questo problema, è possibile provare la mitigazione seguente:

  • Per le operazioni IT che gestiscono il cluster Kubernetes, è possibile provare ad aggiungere altri nodi o cancellare alcuni pod inutilizzati nel cluster per rilasciare alcune risorse.
  • Per i tecnici di Machine Learning che distribuiscono i modelli, è possibile provare a ridurre la richiesta di risorse della distribuzione:
    • Se si definisce direttamente la richiesta di risorsa nella configurazione della distribuzione tramite la sezione della risorsa, è possibile provare a ridurre la richiesta di risorsa.
    • Se si usa instance type per definire la risorsa per la distribuzione del modello, è possibile contattare le operazioni IT per modificare la configurazione della risorsa del tipo di istanza. Per altri dettagli, vedere Come gestire il tipo di istanza di Kubernetes.

Capacità di macchine virtuali a livello di area

A causa della mancanza di capacità di Azure Machine Learning nell'area, il servizio non è riuscito a effettuare il provisioning delle dimensioni della macchina virtuale specificate. Riprovare più tardi o provare a eseguire la distribuzione in un'area diversa.

Altra quota

Per eseguire l'oggetto score.py fornito come parte della distribuzione, Azure crea un contenitore che include tutte le risorse score.py necessarie ed esegue lo script di assegnazione dei punteggi in tale contenitore.

Se non è stato possibile avviare il contenitore, significa che non è stato possibile assegnare punteggi. Potrebbe essere che il contenitore richieda più risorse di quelle instance_type che possono supportare. In tal caso, prendere in considerazione l'aggiornamento instance_type della distribuzione online.

Per ottenere il motivo esatto di un errore, eseguire:

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

ERRORE: BadArgument

L'elenco seguente è un motivo per cui è possibile che si verifichi questo errore quando si usa l'endpoint online gestito o l'endpoint online Kubernetes:

L'elenco seguente è un motivo per cui è possibile che si verifichi questo errore solo quando si usa l'endpoint online Kubernetes:

La sottoscrizione non esiste

La sottoscrizione di Azure immessa deve essere esistente. Questo errore si verifica quando non è possibile trovare la sottoscrizione di Azure a cui si fa riferimento. Questo errore è probabilmente dovuto a un errore di digitazioni nell'ID sottoscrizione. Verificare che l'ID sottoscrizione sia stato digitato correttamente e che sia attualmente attivo.

Per altre informazioni sulle sottoscrizioni di Azure, vedere la sezione prerequisiti.

Errore di autorizzazione

Dopo aver effettuato il provisioning della risorsa di calcolo (durante la creazione di una distribuzione), Azure tenta di eseguire il pull dell'immagine del contenitore utente dall'area di lavoro Registro Azure Container (Registro Azure Container). Tenta di montare il modello utente e gli artefatti di codice nel contenitore utente dall'account di archiviazione dell'area di lavoro.

Per eseguire queste azioni, Azure usa le identità gestite per accedere all'account di archiviazione e al registro contenitori.

  • Se è stato creato l'endpoint associato all'identità assegnata dal sistema, viene concessa automaticamente l'autorizzazione controllo degli accessi in base al ruolo di Azure e non sono necessarie altre autorizzazioni.

  • Se è stato creato l'endpoint associato all'identità assegnata dall'utente, l'identità gestita dell'utente deve disporre dell'autorizzazione Archiviazione lettore di dati BLOB per l'account di archiviazione per l'area di lavoro e l'autorizzazione AcrPull per il Registro Azure Container (ACR) per l'area di lavoro. Assicurarsi che l'identità assegnata dall'utente disponga dell'autorizzazione corretta.

Per altre informazioni, vedere Errore di autorizzazione del Registro Container.

Specifica della funzione modello non valida

Questo errore si verifica quando una funzione modello è stata specificata in modo non corretto. Correggere il criterio o rimuovere l'assegnazione dei criteri per sbloccare. Il messaggio di errore può includere il nome dell'assegnazione dei criteri e la definizione dei criteri per facilitare il debug di questo errore e l'articolo sulla struttura della definizione dei criteri di Azure, che illustra i suggerimenti per evitare errori del modello.

Non è possibile scaricare l'immagine del contenitore utente

È possibile che il contenitore utente non sia stato trovato. Controllare i log dei contenitori per ottenere altri dettagli.

Assicurarsi che l'immagine del contenitore sia disponibile nel Registro Azure Container.

Ad esempio, se l'immagine controlla testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest il repository con az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table.

Non è possibile scaricare il modello dell'utente

È possibile che il modello dell'utente non sia stato trovato. Controllare i log dei contenitori per ottenere altri dettagli.

Assicurarsi di aver registrato il modello nella stessa area di lavoro della distribuzione. Per visualizzare i dettagli di un modello in un'area di lavoro:

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

Avviso

È necessario specificare la versione o l'etichetta per ottenere le informazioni del modello.

È anche possibile verificare se i BLOB sono presenti nell'account di archiviazione dell'area di lavoro.

  • Ad esempio, se il BLOB è https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl, è possibile usare questo comando per verificare se esiste:

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

  • Se il BLOB è presente, è possibile usare questo comando per ottenere i log dall'inizializzatore di archiviazione:

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

Il formato del modello MLFlow con rete privata non è supportato

Questo errore si verifica quando si tenta di distribuire un modello MLflow con un approccio di distribuzione senza codice insieme al metodo di isolamento della rete legacy per gli endpoint online gestiti. Questa funzionalità di rete privata non può essere usata insieme a un formato di modello MLFlow se si usa il metodo di isolamento della rete legacy . Se è necessario distribuire un modello MLflow con l'approccio di distribuzione senza codice, provare a usare la rete virtuale gestita dell'area di lavoro.

Richieste di risorse superiori ai limiti

Le richieste di risorse devono essere minori o uguali ai limiti. Se non si impostano limiti, i valori predefiniti vengono impostati quando si collega il calcolo a un'area di lavoro di Azure Machine Learning. È possibile controllare i limiti nel portale di Azure o usando il az ml compute show comando .

azureml-fe non pronto

Il componente front-end (azureml-fe) che instrada le richieste di inferenza in ingresso ai servizi distribuiti viene ridimensionato automaticamente in base alle esigenze. Viene installato durante l'installazione dell'estensione k8s.

Questo componente deve essere integro nel cluster, almeno una replica integra. Questo messaggio di errore viene visualizzato se non è disponibile quando si attiva l'endpoint online kubernetes e la richiesta di creazione/aggiornamento della distribuzione.

Controllare lo stato e i log del pod per risolvere questo problema, è anche possibile provare ad aggiornare l'estensione k8s installata nel cluster.

ERRORE: ResourceNotReady

Per eseguire l'oggetto score.py fornito come parte della distribuzione, Azure crea un contenitore che include tutte le risorse score.py necessarie ed esegue lo script di assegnazione dei punteggi in tale contenitore. L'errore in questo scenario è che questo contenitore si arresta in modo anomalo durante l'esecuzione, il che significa che l'assegnazione dei punteggi non può verificarsi. Questo errore si verifica quando:

  • Si è verificato un errore in score.py. Usare get-logs per diagnosticare i problemi comuni:
    • Un pacchetto che score.py tenta di importare non è incluso nell'ambiente conda.
    • Errore di sintassi.
    • Errore nel init() metodo .
  • Se get-logs non produce alcun log, in genere significa che l'avvio del contenitore non è riuscito. Per eseguire il debug di questo problema, provare invece a distribuire localmente .
  • I probe di idoneità o di attività non sono configurati correttamente.
  • L'inizializzazione del contenitore richiede troppo tempo in modo che il probe di idoneità o di attività non riesca oltre la soglia di errore. In questo caso, modificare le impostazioni del probe per consentire un tempo più lungo per inizializzare il contenitore. In alternativa, provare uno SKU di vm di dimensioni maggiori tra gli SKU di macchine virtuali supportati, che accelera l'inizializzazione.
  • Si è verificato un errore nell'ambiente configurato del contenitore, ad esempio una dipendenza mancante.
  • Quando viene visualizzato l'errore TypeError: register() takes 3 positional arguments but 4 were given , controllare la dipendenza tra flask v2 e azureml-inference-server-http. Per altre informazioni, vedere Domande frequenti per il server HTTP di inferenza.

ERRORE: ResourceNotFound

L'elenco seguente è un motivo per cui è possibile riscontrare questo errore solo quando si usa l'endpoint online gestito o l'endpoint online Kubernetes:

Resource Manager non riesce a trovare una risorsa

Questo errore si verifica quando Azure Resource Manager non riesce a trovare una risorsa necessaria. Ad esempio, è possibile ricevere questo errore se è stato fatto riferimento a un account di archiviazione, ma non è possibile trovarlo nel percorso in cui è stato specificato. Assicurarsi di controllare due volte le risorse che potrebbero essere state fornite da un percorso esatto o dall'ortografia dei nomi.

Per altre informazioni, vedere Risolvere gli errori di risorsa non trovata.

Errore di autorizzazione del registro contenitori

Questo errore si verifica quando è stata fornita un'immagine appartenente a un registro contenitori privato o altrimenti inaccessibile per la distribuzione. Al momento, le API non possono accettare credenziali del Registro di sistema privato.

Per attenuare questo errore, assicurarsi che il registro contenitori non sia privato o seguire questa procedura:

  1. Concedere il ruolo del acrPull registro privato all'identità di sistema dell'endpoint online.
  2. Nella definizione dell'ambiente specificare l'indirizzo dell'immagine privata e l'istruzione per non modificare (compilare) l'immagine.

Se la mitigazione ha esito positivo, l'immagine non richiede la compilazione e l'indirizzo dell'immagine finale è l'indirizzo dell'immagine specificato. In fase di distribuzione, l'identità di sistema dell'endpoint online esegue il pull dell'immagine dal registro privato.

Per altre informazioni di diagnostica, vedere Come usare l'API diagnostica dell'area di lavoro.

ERRORE: OperationCanceled

L'elenco seguente è un motivo per cui è possibile che si verifichi questo errore quando si usa l'endpoint online gestito o l'endpoint online Kubernetes:

Operazione annullata da un'altra operazione con priorità più alta

Le operazioni di Azure hanno un determinato livello di priorità e vengono eseguite dal più alto al più basso. Questo errore si verifica quando l'operazione è stata sostituita da un'altra operazione con priorità più alta.

Il nuovo tentativo dell'operazione potrebbe consentire l'esecuzione senza annullamento.

Operazione annullata in attesa di conferma del blocco

Le operazioni di Azure hanno un breve periodo di attesa dopo l'invio durante il quale recuperano un blocco per assicurarsi che non si eseguano condizioni di race condition. Questo errore si verifica quando l'operazione inviata è uguale a un'altra operazione. L'altra operazione è attualmente in attesa di conferma della ricezione del blocco. Potrebbe indicare che è stata inviata una richiesta simile troppo presto dopo la richiesta iniziale.

La ripetizione dell'operazione dopo l'attesa di alcuni secondi fino a un minuto potrebbe consentire l'esecuzione senza annullamento.

ERRORE: SecretsDeviceectionError

Il recupero e l'inserimento di segreti durante la creazione della distribuzione online usano l'identità associata all'endpoint online per recuperare i segreti dalle connessioni all'area di lavoro e/o dagli insiemi di credenziali delle chiavi. Questo errore si verifica quando:

  • L'identità dell'endpoint non dispone dell'autorizzazione controllo degli accessi in base al ruolo di Azure per leggere i segreti dalle connessioni all'area di lavoro e/o dagli insiemi di credenziali delle chiavi, anche se i segreti sono stati specificati dalla definizione di distribuzione come riferimenti (mappati alle variabili di ambiente). Tenere presente che l'assegnazione di ruolo può richiedere tempo per rendere effettive le modifiche.
  • Il formato dei riferimenti al segreto non è valido oppure i segreti specificati non esistono nelle connessioni dell'area di lavoro e/o negli insiemi di credenziali delle chiavi.

Per altre informazioni, vedere Inserimento di segreti negli endpoint online (anteprima) e Accesso ai segreti dalla distribuzione online tramite l'inserimento di segreti (anteprima).

ERRORE: InternalServerError

Anche se facciamo il nostro meglio per fornire un servizio stabile e affidabile, a volte le cose non vanno secondo il piano. Se viene visualizzato questo errore, significa che qualcosa non è corretto sul lato e dobbiamo correggerlo. Inviare un ticket di supporto clienti con tutte le informazioni correlate ed è possibile risolvere il problema.

Errori comuni specifici delle distribuzioni kubernetes

Errori relativi all'identità e all'autenticazione:

Errori relativi a crashloopbackoff:

Errori relativi allo script di assegnazione dei punteggi:

Altri:

ERRORE: ACRSecretError

L'elenco seguente è un motivo per cui è possibile riscontrare questo errore durante la creazione/l'aggiornamento delle distribuzioni online di Kubernetes:

  • L'assegnazione di ruolo non è stata completata. In questo caso, attendere alcuni secondi e riprovare più tardi.
  • L'estensione Azure ARC (per il cluster Azure Arc Kubernetes) o l'estensione Azure Machine Learning (Per il servizio Azure Kubernetes) non è installata o configurata correttamente. Provare a controllare la configurazione e lo stato dell'estensione Azure ARC o Azure Machine Learning.
  • Il cluster Kubernetes ha una configurazione di rete non corretta, controllare il proxy, i criteri di rete o il certificato.
    • Se si usa un cluster del servizio Azure Kubernetes privato, è necessario configurare endpoint privati per Registro Azure Container, account di archiviazione e area di lavoro nella rete virtuale del servizio Azure Kubernetes.
  • Assicurarsi che la versione dell'estensione Azure Machine Learning sia successiva alla versione 1.1.25.

ERRORE: TokenRefreshFailed

Questo errore è dovuto al fatto che l'estensione non riesce a ottenere le credenziali principali da Azure perché l'identità del cluster Kubernetes non è impostata correttamente. Reinstallare l'estensione Azure Machine Learning e riprovare.

ERRORE: GetAADTokenFailed

Questo errore è dovuto al fatto che la richiesta del token di Azure AD del cluster Kubernetes non è riuscita o si è verificato il timeout, controllare l'accessibilità di rete e riprovare.

  • È possibile seguire configurare il traffico di rete necessario per controllare il proxy in uscita, assicurarsi che il cluster possa connettersi all'area di lavoro.
  • L'URL dell'endpoint dell'area di lavoro è disponibile nell'endpoint online CRD nel cluster.

Se l'area di lavoro è un'area di lavoro privata, che ha disabilitato l'accesso alla rete pubblica, il cluster Kubernetes deve comunicare solo con l'area di lavoro privata tramite il collegamento privato.

  • È possibile verificare se l'accesso all'area di lavoro consente l'accesso pubblico, indipendentemente dal fatto che un cluster del servizio Azure Kubernetes sia pubblico o privato, non può accedere all'area di lavoro privata.
  • Per altre informazioni, vedere Proteggere servizio Azure Kubernetes ambiente di inferenza

ERRORE: ACRAuthenticationChallengeFailed

Questo errore è dovuto al fatto che il cluster Kubernetes non riesce a raggiungere il servizio Registro Azure Container dell'area di lavoro per eseguire una richiesta di autenticazione. Controllare la rete, in particolare l'accesso alla rete pubblica del Registro Azure Container, quindi riprovare.

È possibile seguire i passaggi per la risoluzione dei problemi in GetAADTokenFailed per controllare la rete.

ERRORE: ACRTokenExchangeFailed

Questo errore è dovuto al fatto che il token del record di controllo di accesso di Exchange del cluster Kubernetes non è riuscito perché il token di Azure AD non è ancora autorizzato. Poiché l'assegnazione di ruolo richiede tempo, è possibile attendere un attimo e riprovare.

Questo errore potrebbe anche essere dovuto a troppe richieste al servizio Registro Azure Container in quel momento, dovrebbe essere un errore temporaneo, è possibile riprovare più tardi.

ERRORE: KubernetesUnaccessible

È possibile che venga visualizzato l'errore seguente durante le distribuzioni del modello Kubernetes:

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

Per attenuare questo errore, è possibile:

ERRORE: ImagePullLoopBackOff

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online di Kubernetes è dovuto al fatto che non è possibile scaricare le immagini dal registro contenitori, causando l'errore di pull delle immagini.

In questo caso, è possibile controllare i criteri di rete del cluster e il registro contenitori dell'area di lavoro se il cluster può eseguire il pull dell'immagine dal registro contenitori.

ERRORE: DeploymentCrashLoopBackOff

Il motivo per cui si potrebbe riscontrare questo errore durante la creazione/aggiornamento delle distribuzioni online di Kubernetes è l'inizializzazione arrestata in modo anomalo del contenitore utente. Esistono due possibili motivi per questo errore:

  • Lo script score.py utente presenta un errore di sintassi o un errore di importazione, quindi genera eccezioni durante l'inizializzazione.
  • In alternativa, il pod di distribuzione richiede più memoria del limite.

Per attenuare questo errore, è prima possibile controllare i log di distribuzione per eventuali eccezioni negli script utente. Se l'errore persiste, provare a estendere il limite di memoria del tipo di istanza/risorse.

ERRORE: KubernetesCrashLoopBackOff

L'elenco seguente è un motivo per cui è possibile riscontrare questo errore durante la creazione/l'aggiornamento degli endpoint/distribuzioni online di Kubernetes:

  • Uno o più pod bloccati nello stato CrashLoopBackoff, è possibile verificare se il log di distribuzione esiste e verificare se sono presenti messaggi di errore nel log.
  • Si verifica un errore in score.py e il contenitore si arresta in modo anomalo quando si inserisce il codice del punteggio, è possibile seguire la parte ERROR: ResourceNotReady .
  • Il processo di assegnazione dei punteggi richiede una quantità maggiore di memoria insufficiente per il limite di configurazione della distribuzione. È possibile provare ad aggiornare la distribuzione con un limite di memoria maggiore.

ERRORE: NamespaceNotFound

Questo errore può verificarsi quando si creano/aggiornano gli endpoint online kubernetes perché lo spazio dei nomi usato dal calcolo Kubernetes non è disponibile nel cluster.

È possibile controllare il calcolo Kubernetes nel portale dell'area di lavoro e controllare lo spazio dei nomi nel cluster Kubernetes. Se lo spazio dei nomi non è disponibile, è possibile scollegare il calcolo legacy e ricollegarlo per crearne uno nuovo, specificando uno spazio dei nomi già esistente nel cluster.

ERRORE: UserScriptInitFailed

Il motivo per cui si potrebbe riscontrare questo errore durante la creazione/aggiornamento delle distribuzioni online di Kubernetes è dovuto alla funzione init nel file caricato score.py che ha generato un'eccezione.

È possibile controllare i log di distribuzione per visualizzare il messaggio di eccezione in dettaglio e correggere l'eccezione.

ERRORE: UserScriptImportError

Il motivo per cui si potrebbe riscontrare questo errore durante la creazione o l'aggiornamento delle distribuzioni online di Kubernetes è dovuto al fatto che il score.py file caricato ha importato pacchetti non disponibili.

È possibile controllare i log di distribuzione per visualizzare il messaggio di eccezione in dettaglio e correggere l'eccezione.

ERRORE: UserScriptFunctionNotFound

Il motivo per cui si potrebbe riscontrare questo errore durante la creazione o l'aggiornamento delle distribuzioni online di Kubernetes è dovuto al fatto che il score.py file caricato non ha una funzione denominata init() o run(). È possibile controllare il codice e aggiungere la funzione .

ERRORE: EndpointNotFound

Il motivo per cui si potrebbe riscontrare questo errore durante la creazione/aggiornamento delle distribuzioni online di Kubernetes è dovuto al fatto che il sistema non riesce a trovare la risorsa endpoint per la distribuzione nel cluster. È necessario creare la distribuzione in un endpoint esistente o creare questo endpoint prima nel cluster.

ERRORE: EndpointAlreadyExists

Il motivo per cui potrebbe verificarsi questo errore durante la creazione di un endpoint online Kubernetes è dovuto al fatto che l'endpoint di creazione esiste già nel cluster.

Il nome dell'endpoint deve essere univoco per area di lavoro e per ogni cluster, quindi in questo caso è necessario creare un endpoint con un altro nome.

ERRORE: ScoringFeUnhealthy

Il motivo per cui si potrebbe riscontrare questo errore durante la creazione o l'aggiornamento di un endpoint/distribuzione online di Kubernetes è dovuto al fatto che Azureml-fe è il servizio di sistema in esecuzione nel cluster non viene trovato o non integro.

Per risolvere questo problema, è possibile reinstallare o aggiornare l'estensione Azure Machine Learning nel cluster.

ERRORE: ValidateScoringFailed

Il motivo per cui si potrebbe riscontrare questo errore durante la creazione/aggiornamento delle distribuzioni online di Kubernetes è dovuto al fatto che la convalida dell'URL della richiesta di assegnazione dei punteggi non è riuscita durante l'elaborazione del modello di distribuzione.

In questo caso, è prima possibile controllare l'URL dell'endpoint e quindi provare a ridistribuire la distribuzione.

ERRORE: InvalidDeploymentSpec

Il motivo per cui si potrebbe riscontrare questo errore durante la creazione/aggiornamento delle distribuzioni online di Kubernetes è dovuto al fatto che la specifica di distribuzione non è valida.

In questo caso, è possibile controllare il messaggio di errore.

  • Assicurarsi che sia instance count valido.
  • Se è stata abilitata la scalabilità automatica, assicurarsi che minimum instance count e maximum instance count siano entrambi validi.

ERRORE: PodUnschedulable

L'elenco seguente è un motivo per cui è possibile riscontrare questo errore durante la creazione/l'aggiornamento degli endpoint/distribuzioni online di Kubernetes:

  • Non è possibile pianificare il pod nei nodi, a causa di risorse insufficienti nel cluster.
  • Nessuna affinità nodo/selettore del nodo.

Per attenuare questo errore, è possibile seguire questa procedura:

  • Controllare la node selector definizione dell'oggetto instance type usato e node label la configurazione dei nodi del cluster.
  • Controllare instance type le dimensioni dello SKU del nodo per il cluster del servizio Azure Kubernetes o la risorsa del nodo per il cluster Arc-Kubernetes.
    • Se il cluster è sotto-risorsa, è possibile ridurre il requisito della risorsa del tipo di istanza o usare un altro tipo di istanza con una risorsa più piccola necessaria.
  • Se il cluster non ha più risorse per soddisfare il requisito della distribuzione, eliminare alcune distribuzioni per rilasciare le risorse.

ERRORE: PodOutOfMemory

Il motivo per cui si potrebbe riscontrare questo errore quando si crea o si aggiorna la distribuzione online è il limite di memoria che si assegna per la distribuzione non è sufficiente. È possibile impostare il limite di memoria su un valore maggiore o usare un tipo di istanza più grande per attenuare questo errore.

ERRORE: InferencingClientCallFailed

Questo errore può verificarsi quando si creano/aggiornano endpoint/distribuzioni online kubernetes perché l'estensione k8s del cluster Kubernetes non è connettibile.

In questo caso, è possibile scollegare e quindi ricollegare il calcolo.

Nota

Per risolvere gli errori ricollegando gli errori, assicurarsi di ricollegarsi con la stessa configurazione delle risorse di calcolo scollegate in precedenza, ad esempio lo stesso nome di calcolo e lo stesso spazio dei nomi, altrimenti potrebbero verificarsi altri errori.

Se non funziona ancora, è possibile chiedere all'amministratore che può accedere al cluster da usare kubectl get po -n azureml per verificare se i pod del server di inoltro sono in esecuzione.

Problemi di scalabilità automatica

Se si verificano problemi con la scalabilità automatica, vedere Risoluzione dei problemi di scalabilità automatica di Azure.

Per l'endpoint online kubernetes, è disponibile un router di inferenza di Azure Machine Learning che è un componente front-end per gestire la scalabilità automatica per tutte le distribuzioni di modelli nel cluster Kubernetes. Per altre informazioni , vedere Scalabilità automatica del routing dell'inferenza kubernetes

Errori comuni relativi all'utilizzo di modelli

L'elenco seguente è costituito da errori comuni di utilizzo del modello risultanti dallo stato dell'operazione dell'endpoint invoke .

Problemi relativi al limite della larghezza di banda

Gli endpoint online gestiti hanno limiti di larghezza di banda per ogni endpoint. La configurazione del limite è disponibile nei limiti per gli endpoint online. Se l'utilizzo della larghezza di banda supera il limite, la richiesta viene ritardata. Per monitorare il ritardo della larghezza di banda:

  • Usare la metrica "Byte di rete" per comprendere l'utilizzo corrente della larghezza di banda. Per altre informazioni, vedere Monitorare gli endpoint online gestiti.
  • Se viene applicato il limite di larghezza di banda applicato, vengono restituiti due trailer di risposta:
    • ms-azureml-bandwidth-request-delay-ms: tempo di ritardo in millisecondi necessario per il trasferimento del flusso di richiesta.
    • ms-azureml-bandwidth-response-delay-ms: tempo di ritardo in millisecondi necessario per il trasferimento del flusso di risposta.

Codici di stato HTTP

Quando si accede agli endpoint online con richieste REST, i codici di stato restituiti rispettano gli standard per i codici di stato HTTP. Questi sono dettagli sul mapping degli errori di chiamata e stima degli endpoint ai codici di stato HTTP.

Codici di errore comuni per gli endpoint online gestiti

La tabella seguente contiene codici di errore comuni quando si utilizzano endpoint online gestiti con richieste REST:

Codice di stato Frase motivo Perché questo codice potrebbe essere restituito
200 OK Il modello è stato eseguito correttamente, all'interno del limite di latenza.
401 Non autorizzata Non si dispone dell'autorizzazione necessaria per eseguire l'azione richiesta, ad esempio il punteggio o il token è scaduto o nel formato errato. Per altre informazioni, vedere Concetto di autenticazione degli endpoint e come eseguire l'autenticazione per l'endpoint.
404 Non trovato L'endpoint non ha una distribuzione valida con peso positivo.
408 Timeout richiesta L'esecuzione del modello ha richiesto più tempo rispetto al timeout fornito nella request_timeout_msrequest_settings configurazione della distribuzione del modello.
424 Errore del modello Se il contenitore di modelli restituisce una risposta non 200, Azure restituisce un valore 424. Controllare la Model Status Code dimensione nella Requests Per Minute metrica in Esplora metriche di Monitoraggio di Azure dell'endpoint. In alternativa, controllare le intestazioni della ms-azureml-model-error-statuscode risposta e ms-azureml-model-error-reason per altre informazioni. Se 424 presenta problemi di liveness o probe di idoneità, valutare la possibilità di modificare le impostazioni del probe per consentire tempi più lunghi per il probe della durata o della conformità del contenitore.
429 Troppe richieste in sospeso Il modello sta attualmente ricevendo più richieste di quanto possa gestire. Azure Machine Learning ha implementato un sistema che consente di elaborare in parallelo un massimo di 2 * max_concurrent_requests_per_instance * instance_count requests in qualsiasi momento per garantire un funzionamento senza problemi. Altre richieste che superano questo valore massimo vengono rifiutate. È possibile esaminare la configurazione della distribuzione del modello nelle sezioni request_settings e scale_settings per verificare e modificare queste impostazioni. Inoltre, come descritto nella definizione YAML per Request Impostazioni, è importante assicurarsi che la variabile WORKER_COUNT di ambiente venga passata correttamente.

Se si usa la scalabilità automatica e si riceve questo errore, significa che il modello sta ricevendo richieste più rapidamente rispetto al sistema in grado di aumentare le prestazioni. In questo caso, prendere in considerazione la possibilità di inviare di nuovo le richieste con un backoff esponenziale per fornire al sistema il tempo necessario per modificarle. È anche possibile aumentare il numero di istanze usando il codice per calcolare il numero di istanze. Questi passaggi, combinati con l'impostazione della scalabilità automatica, consentono di assicurarsi che il modello sia pronto per gestire l'afflusso di richieste.
429 Velocità limitata Il numero di richieste al secondo ha raggiunto i limiti degli endpoint online gestiti.
500 Errore interno del server L'infrastruttura con provisioning di Azure Machine Learning ha esito negativo.

Codici di errore comuni per gli endpoint online kubernetes

La tabella seguente contiene codici di errore comuni quando si usano endpoint online Kubernetes con richieste REST:

Codice di stato Frase motivo Perché questo codice potrebbe essere restituito
409 errore di conflitto Quando un'operazione è già in corso, qualsiasi nuova operazione sullo stesso endpoint online risponde con un errore di conflitto 409. Ad esempio, se l'operazione di creazione o aggiornamento dell'endpoint online è in corso e se si attiva una nuova operazione di eliminazione, viene generato un errore.
502 È stata generata un'eccezione o si è verificato un arresto anomalo nel run() metodo del file score.py Quando si verifica un errore in score.py, ad esempio un pacchetto importato non esiste nell'ambiente conda, un errore di sintassi o un errore nel init() metodo . È possibile seguire qui per eseguire il debug del file.
503 Ricevere picchi elevati nelle richieste al secondo Il ridimensionamento automatico è progettato per gestire le modifiche graduali nel carico. Se si ricevono picchi elevati di richieste al secondo, i client potrebbero ricevere un codice di stato HTTP 503. Anche se il ridimensionamento automatico reagisce rapidamente, il servizio Azure Kubernetes richiede molto tempo per creare più contenitori. È possibile seguire qui per impedire 503 codici di stato.
504 Timeout della richiesta Un codice di stato 504 indica che la richiesta è scaduta. L'impostazione di timeout predefinita è di 5 secondi. È possibile aumentare il timeout o provare a velocizzare l'endpoint modificando il score.py per rimuovere le chiamate non necessarie. Se queste azioni non consentono di risolvere il problema, è possibile seguire questa procedura per eseguire il debug del file di score.py. Il codice potrebbe trovarsi in uno stato non reattivo o in un ciclo infinito.
500 Errore interno del server L'infrastruttura con provisioning di Azure Machine Learning ha esito negativo.

Come prevenire i codici di stato 503

Le distribuzioni online di Kubernetes supportano la scalabilità automatica, che consente l'aggiunta di repliche per supportare il caricamento aggiuntivo, altre informazioni sono disponibili nel router di inferenza di Azure Machine Learning. Le decisioni per aumentare o ridurre le prestazioni sono basate sull'utilizzo delle repliche dei contenitori correnti.

Esistono due elementi che consentono di prevenire codici di stato 503:

Suggerimento

Questi due approcci possono essere usati singolarmente o in combinazione.

  • Modificare il livello di utilizzo a cui il ridimensionamento automatico crea nuove repliche. È possibile regolare la destinazione di utilizzo impostando autoscale_target_utilization su un valore inferiore.

    Importante

    Questa modifica non comporta la creazione di repliche più velocemente. Vengono invece create con una soglia di utilizzo inferiore. Anziché attendere fino al 70% di utilizzo del servizio, la modifica del valore su 30% comporta la creazione di repliche quando si verifica l'utilizzo al 30%.

    Se l'endpoint online Kubernetes usa già le repliche massime correnti e vengono visualizzati ancora 503 codici di stato, aumentare il autoscale_max_replicas valore per aumentare il numero massimo di repliche.

  • Modificare il numero minimo di repliche. L'aumento delle repliche minime offre un pool più grande per gestire i picchi in ingresso.

    Per aumentare il numero di istanze, è possibile calcolare le repliche necessarie seguendo questi codici.

    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)

    Nota

    Se si ricevono picchi di richieste maggiori delle nuove repliche minime gestibili, è possibile ricevere nuovamente 503. Ad esempio, man mano che aumenta il traffico verso l'endpoint, potrebbe essere necessario aumentare le repliche minime.

Come calcolare il numero di istanze

Per aumentare il numero di istanze, è possibile calcolare le repliche necessarie usando il codice seguente:

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)

Bloccato dai criteri CORS

Gli endpoint online (v2) attualmente non supportano la condivisione di risorse tra le origini (CORS) in modo nativo. Se l'applicazione Web tenta di richiamare l'endpoint senza gestire correttamente le richieste preliminari CORS, è possibile visualizzare il messaggio di errore seguente:

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.

È consigliabile usare Funzioni di Azure, app Azure lication Gateway o qualsiasi servizio come livello intermedio per gestire le richieste preliminari CORS.

Problemi comuni di isolamento della rete

La creazione dell'endpoint online ha esito negativo con un messaggio V1LegacyMode == true

L'area di lavoro di Azure Machine Learning può essere configurata per v1_legacy_mode, che disabilita le API v2. Gli endpoint online gestiti sono una funzionalità della piattaforma API v2 e non funzioneranno se v1_legacy_mode è abilitato per l'area di lavoro.

Importante

Rivolgersi al team di sicurezza di rete prima di disabilitare v1_legacy_mode. Potrebbe essere stato abilitato dal team di sicurezza di rete per un motivo.

Per informazioni su come disabilitare v1_legacy_mode, vedere Isolamento di rete con v2.

La creazione dell'endpoint online con l'autenticazione basata su chiavi ha esito negativo

Usare il comando seguente per elencare le regole di rete di Azure Key Vault per l'area di lavoro. Sostituire <keyvault-name> con il nome dell'insieme di credenziali delle chiavi:

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

La risposta per questo comando è simile al documento JSON seguente:

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

Se il valore di non AzureServicesè , usare le indicazioni riportate in Configurare le impostazioni di rete dell'insieme di bypass credenziali delle chiavi per impostarlo su AzureServices.

Le distribuzioni online hanno esito negativo con un errore di download dell'immagine

Nota

Questo problema si applica quando si usa il metodo di isolamento di rete legacy per gli endpoint online gestiti, in cui Azure Machine Learning crea una rete virtuale gestita per ogni distribuzione in un endpoint.

  1. Controllare se il egress-public-network-access flag è disabilitato per la distribuzione. Se questo flag è abilitato e la visibilità del registro contenitori è privata, è previsto questo errore.

  2. Usare il comando seguente per controllare lo stato della connessione all'endpoint privato. Sostituire <registry-name> con il nome del Registro Azure Container per l'area di lavoro:

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

    Nel documento di risposta verificare che il status campo sia impostato su Approved. Se non è approvata, usare il comando seguente per approvarlo. Sostituire <private-endpoint-name> con il nome restituito dal comando precedente:

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

L'endpoint di assegnazione dei punteggi non può essere risolto

  1. Verificare che il client che emette la richiesta di punteggio sia una rete virtuale in grado di accedere all'area di lavoro di Azure Machine Learning.

  2. Usare il nslookup comando nel nome host dell'endpoint per recuperare le informazioni sull'indirizzo IP:

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

    La risposta contiene un indirizzo. Questo indirizzo deve trovarsi nell'intervallo fornito dalla rete virtuale

    Nota

    Per l'endpoint online Kubernetes, il nome host dell'endpoint deve essere CName (nome di dominio) specificato nel cluster Kubernetes. Se si tratta di un endpoint HTTP, l'indirizzo IP sarà contenuto nell'URI dell'endpoint che è possibile ottenere direttamente nell'interfaccia utente di Studio. Altri modi per ottenere l'indirizzo IP dell'endpoint sono disponibili nell'endpoint online Secure Kubernetes.

  3. Se il nome host non viene risolto dal nslookup comando :

    Per endpoint online gestito,

    1. Controllare se esiste un record A nella zona DNS privata per la rete virtuale.

      Per controllare i record, usare il comando seguente:

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

      I risultati devono contenere una voce simile a *.<GUID>.inference.<region>.

    2. Se non viene restituito alcun valore di inferenza, eliminare l'endpoint privato per l'area di lavoro e ricrearlo. Per altre informazioni, vedere Come configurare un endpoint privato.

    3. Se l'area di lavoro con un endpoint privato viene configurata usando un DNS personalizzato Come usare l'area di lavoro con un server DNS personalizzato, usare il comando seguente per verificare se la risoluzione funziona correttamente dal DNS personalizzato.

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

    Per l'endpoint online di Kubernetes,

    1. Controllare la configurazione DNS nel cluster Kubernetes.

    2. Inoltre, è possibile verificare se azureml-fe funziona come previsto, usare il comando seguente:

      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"

      Per HTTP, usare

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

    Se curl HTTP ha esito negativo (ad esempio, timeout) ma HTTP funziona, verificare che il certificato sia valido.

    Se il problema non viene risolto in un record A, verificare se la risoluzione funziona da DNS di Azure(168.63.129.16).

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

    Se l'operazione ha esito positivo, è possibile risolvere i problemi relativi al server d'inoltro condizionale per il collegamento privato nel DNS personalizzato.

Non è possibile assegnare punteggi alle distribuzioni online

  1. Usare il comando seguente per verificare se la distribuzione è stata distribuita correttamente:

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

    Se la distribuzione è stata completata correttamente, il valore di state sarà Succeeded.

  2. Se la distribuzione ha avuto esito positivo, usare il comando seguente per verificare che il traffico sia assegnato alla distribuzione. Sostituire <endpointname> con il nome dell'endpoint:

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

    Suggerimento

    Questo passaggio non è necessario se si usa l'intestazione azureml-model-deployment nella richiesta per specificare come destinazione questa distribuzione.

    La risposta da questo comando deve elencare la percentuale di traffico assegnato alle distribuzioni.

  3. Se le assegnazioni di traffico (o l'intestazione di distribuzione) sono impostate correttamente, usare il comando seguente per ottenere i log per l'endpoint. Sostituire <endpointname> con il nome dell'endpoint e <deploymentname> con la distribuzione:

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

    Esaminare i log per verificare se si verifica un problema durante l'esecuzione del codice di assegnazione dei punteggi quando si invia una richiesta alla distribuzione.

Risolvere i problemi del server di inferenza

In questa sezione vengono forniti suggerimenti di base per la risoluzione dei problemi per il server HTTP di inferenza di Azure Machine Learning.

Passaggi principali

I passaggi di base per la risoluzione dei problemi sono:

  1. Raccogliere informazioni sulla versione per l'ambiente Python.
  2. Assicurarsi che la versione del pacchetto python azureml-inference-server-http specificata nel file di ambiente corrisponda alla versione del server HTTP di inferenza di AzureML visualizzata nel log di avvio. A volte il sistema di risoluzione delle dipendenze di pip porta a versioni impreviste dei pacchetti installati.
  3. Se si specifica Flask (e le relative dipendenze) nell'ambiente, rimuoverli. Le dipendenze includono Flask, Jinja2, Werkzeugitsdangerous, MarkupSafe, e click. Flask è elencato come dipendenza nel pacchetto del server ed è consigliabile consentire al server di installarlo. In questo modo, quando il server supporta le nuove versioni di Flask, le si otterrà automaticamente.

Versione del server

Il pacchetto azureml-inference-server-http server viene pubblicato in PyPI. È possibile trovare il log delle modifiche e tutte le versioni precedenti nella pagina PyPI. Eseguire l'aggiornamento alla versione più recente se si usa una versione precedente.

  • 0.4.x: versione in bundle nelle immagini di training ≤ 20220601 e in azureml-defaults>=1.34,<=1.43. 0.4.13 è l'ultima versione stabile. Se si usa il server prima della versione 0.4.11, potrebbero verificarsi problemi di dipendenza Flask, ad esempio non è possibile importare il nome Markup da jinja2. È consigliabile eseguire l'aggiornamento a 0.4.13 o 0.8.x (versione più recente), se possibile.
  • 0.6.x: versione preinstallata nelle immagini di inferenza ≤ 20220516. L'ultima versione stabile è 0.6.1.
  • 0.7.x: la prima versione che supporta Flask 2. L'ultima versione stabile è 0.7.7.
  • 0.8.x: il formato del log è stato modificato e il supporto di Python 3.6 è stato eliminato.

Dipendenze dei pacchetti

I pacchetti più rilevanti per il server azureml-inference-server-http sono i pacchetti seguenti:

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

Se è stato specificato azureml-defaults nell'ambiente Python, il azureml-inference-server-http pacchetto dipende e verrà installato automaticamente.

Suggerimento

Se si usa Python SDK v1 e non si specifica azureml-defaults in modo esplicito nell'ambiente Python, l'SDK può aggiungere il pacchetto. Tuttavia, lo bloccherà alla versione in cui è attivo l'SDK. Ad esempio, se la versione dell'SDK è 1.38.0, verrà aggiunta azureml-defaults==1.38.0 ai requisiti pip dell'ambiente.

Domande frequenti

1. Si è verificato l'errore seguente durante l'avvio del server:


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

Flask 2 è installato nell'ambiente Python, ma esegue una versione di azureml-inference-server-http che non supporta Flask 2. Il supporto per Flask 2 viene aggiunto in azureml-inference-server-http>=0.7.0, che è anche in azureml-defaults>=1.44.

  • Se non si usa questo pacchetto in un'immagine Docker di AzureML, usare la versione più recente di azureml-inference-server-http o azureml-defaults.

  • Se si usa questo pacchetto con un'immagine Docker di AzureML, assicurarsi di usare un'immagine incorporata o successiva a luglio 2022. La versione dell'immagine è disponibile nei log del contenitore. Dovrebbe essere possibile trovare un log simile al seguente:

    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 |

    La data di compilazione dell'immagine viene visualizzata dopo "Materialization Build", che nell'esempio precedente è 20220708, o l'8 luglio 2022. Questa immagine è compatibile con Flask 2. Se nel log del contenitore non viene visualizzato un banner simile al seguente, l'immagine non è aggiornata e deve essere aggiornata. Se si usa un'immagine CUDA e non è possibile trovare un'immagine più recente, verificare se l'immagine è deprecata in AzureML-Containers. In caso affermativo, dovrebbe essere possibile trovare sostituzioni.

  • Se si usa il server con un endpoint online, è anche possibile trovare i log in "Log di distribuzione" nella pagina endpoint online in studio di Azure Machine Learning. Se si distribuisce con SDK v1 e non si specifica in modo esplicito un'immagine nella configurazione di distribuzione, per impostazione predefinita si usa una versione di corrispondente al set di openmpi4.1.0-ubuntu20.04 strumenti dell'SDK locale, che potrebbe non essere la versione più recente dell'immagine. Ad esempio, SDK 1.43 usa per openmpi4.1.0-ubuntu20.04:20220616impostazione predefinita , che non è compatibile. Assicurarsi di usare l'SDK più recente per la distribuzione.

  • Se per qualche motivo non è possibile aggiornare l'immagine, è possibile evitare temporaneamente il problema aggiungendo azureml-defaults==1.43 o azureml-inference-server-http~=0.4.13, che installerà il server versione precedente con Flask 1.0.x.

2. Si è verificato un oggetto ImportError o ModuleNotFoundError nei moduli opencensus, jinja2, MarkupSafeo click durante l'avvio, come nel messaggio seguente:

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

Le versioni precedenti (<= 0.4.10) del server non hanno aggiunto la dipendenza di Flask alle versioni compatibili. Questo problema è stato risolto nella versione più recente del server.

Passaggi successivi