Condividi tramite

Risolvere i problemi di distribuzione e assegnazione dei punteggi degli 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 è descritta la struttura in base alla quale è consigliabile gestire 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.

Nella sezione relativa ai codici di stato HTTP viene illustrato il mapping tra gli errori di chiamata e previsione e i 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

È 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 alcun impatto 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

Nell'ambito della distribuzione locale, vengono eseguiti i passaggi seguenti:

  • Docker compila una nuova immagine del contenitore o esegue il pull di un'immagine esistente dalla cache Docker locale. Viene usata un'immagine esistente se ne è presente una che corrisponde all'ambiente del file delle specifiche.
  • Docker avvia un nuovo contenitore con gli artefatti locali montati, ad esempio file di modello e codice.

Per altre informazioni, vedere l'argomento relativo alla distribuzione locale in Distribuire e assegnare un punteggio 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 di installazione dell'ambiente utente specificato nel file conda.yaml.

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

  1. Controllare i log dell'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 abbia risolto il problema.

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

  3. Se si verificano errori in locale, provare a risolvere l'ambiente conda e a crearne uno funzionante prima della ridistribuzione.

  4. Se il contenitore si arresta in modo anomalo anche se il problema risulta risolto in locale, è possibile che le dimensioni dello SKU usate per la distribuzione siano insufficienti.

    1. L'installazione del pacchetto Conda viene eseguita in fase di runtime, quindi se le dimensioni dello SKU sono insufficienti per contenere tutti i pacchetti descritti in dettaglio nel file di ambiente conda.yaml, il contenitore potrebbe arrestarsi in modo anomalo.
    2. Una macchina virtuale Standard_F4s_v2 fornisce 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 ottenute dipende dallo stato di provisioning della distribuzione. Se il contenitore specificato è in esecuzione, verrà visualizzato l'output della console, in caso contrario verrà visualizzato un messaggio che indica di riprovare in un secondo momento.

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 seguente comando dell'interfaccia della riga di comando:

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

I log vengono estratti dal server di inferenza.

Nota

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

È anche possibile recuperare 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 e ciò costituisce il modo più flessibile per controllare il log in Kubernetes. Ad esempio:

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

Traccia delle richieste

Sono supportate due intestazioni di traccia:

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

    Nota

    Quando si crea un ticket di supporto per una richiesta non riuscita, allegare l'ID della richiesta non riuscita per accelerare l'indagine. In alternativa, specificare il nome dell'area e il nome dell'endpoint.

  • x-ms-client-request-id è disponibile per gli scenari di traccia client. Questa intestazione viene purificata in modo che vengano accettati solo caratteri alfanumerici, trattini e caratteri di sottolineatura e viene troncata a un massimo di 40 caratteri.

Errori di distribuzione comuni

L'elenco seguente riporta gli errori di distribuzione comuni segnalati a livello di stato dell'operazione di distribuzione:

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

ERROR: 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 dell'area di lavoro di Azure Machine Learning. È possibile che la posizione esatta venga 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 riporta "container registry authorization failure", significa che non è possibile accedere al registro contenitori con le credenziali correnti. La desincronizzazione delle chiavi di una risorsa dell'area di lavoro può causare questo errore; la sincronizzazione automatica richiede tempo. Tuttavia, è possibile richiedere manualmente una sincronizzazione delle chiavi; ciò potrebbe risolvere l'errore di autorizzazione.

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

Ambiente di 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", si usano reti virtuali e Registro Azure Container dell'area di lavoro è privato e configurato con un endpoint privato, è necessario abilitare Registro Azure Container per consentire la compilazione di immagini nella rete virtuale.

Errore di compilazione dell'immagine generica

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

È anche consigliato eseguire una distribuzione locale per testare ed eseguire il debug dei modelli in locale prima della distribuzione nel cloud.

ERROR: OutOfQuota

L'elenco seguente contiene le risorse comuni che potrebbero esaurire la quota quando si usano i servizi di Azure:

L'elenco seguente contiene anche le risorse comuni che potrebbero esaurire la quota solo per l'endpoint online Kubernetes:

Quote della CPU

Prima di distribuire un modello, è necessario disporre di una quota di calcolo sufficiente. Questa quota definisce la quantità di memoria centrale virtuale disponibile per sottoscrizione, per area di lavoro, per SKU e per area. Ogni distribuzione sottrae un valore dalla quota disponibile e lo aggiunge nuovamente dopo l'eliminazione, in base al tipo di SKU.

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

Quota del cluster

Questo problema si verifica quando la quota di cluster dell'ambiente 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 eliminabili. 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 del 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 a usare 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 della memoria del modello è maggiore della memoria disponibile. Provare a usare uno SKU con più memoria.

Quota dell'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 dell'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 degli 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 degli endpoint, vedere Quota degli endpoint con endpoint online ed endpoint batch di Azure Machine Learning.

Quota di Kubernetes

Questo problema si verifica quando la CPU o la memoria richiesta non può essere resa disponibile a causa di nodi non pianificabili per questa distribuzione. Ad esempio, i nodi possono essere bloccati o 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 è presente un numero eccessivo di pod e una quantità insufficiente di risorse 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 addetti all'apprendimento automatico che distribuiscono i modelli, è possibile provare a ridurre la richiesta di risorse della distribuzione:
    • Se si definisce direttamente la richiesta di risorse nella configurazione della distribuzione tramite la sezione delle risorse, è possibile provare a ridurre la richiesta di risorse.
    • 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 di tipo istanza. Per altri dettagli, vedere Come gestire il tipo di istanza Kubernetes.

Capacità delle 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.

Altre quote

Per eseguire il file score.py fornito come parte della distribuzione, Azure crea un contenitore che include tutte le risorse necessarie a score.py ed esegue lo script di assegnazione punteggio in tale contenitore.

Se non è stato possibile avviare il contenitore, significa che non è stato possibile assegnare il punteggio. È possibile che il contenitore richieda più risorse di quelle supportate da instance_type. In tal caso, prendere in considerazione l'aggiornamento di instance_type della distribuzione online.

Per recuperare il motivo esatto di un errore, eseguire:

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

ERROR: BadArgument

L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore quando si usa l'endpoint online gestito o l'endpoint online Kubernetes:

L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore solo quando si usa l'endpoint online Kubernetes:

La sottoscrizione non esiste

La sottoscrizione di Azure immessa deve esistere. Questo errore si verifica quando non è possibile trovare la sottoscrizione di Azure a cui si fa riferimento. È possibile che questo errore sia dovuto a un refuso 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 relativa ai 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. Tenta quindi 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 l'endpoint associato è stato creato con un'identità assegnata dal sistema, l'autorizzazione per il controllo degli accessi in base al ruolo di Azure viene concessa automaticamente e pertanto non sono necessarie ulteriori autorizzazioni.

  • Se l'endpoint associato è stato creato con l'identità assegnata dall'utente, l'identità gestita dell'utente deve disporre dell'autorizzazione di lettura dati del BLOB di archiviazione per l'account di archiviazione per l'area di lavoro e l'autorizzazione AcrPull per Registro Azure Container 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 contenitori.

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 recuperare altri dettagli.

Assicurarsi che l'immagine del contenitore sia disponibile nell'area di lavoro di Registro Azure Container.

Ad esempio, se l'immagine è testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, controllare 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 utente non sia stato trovato. Controllare i log dei contenitori per recuperare 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 visualizzare 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 verificarne l'esistenza:

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

  • Se il BLOB esiste, è 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 dall'area di lavoro.

Le richieste di risorse superano i limiti

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

azureml-fe non pronto

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

Questo componente o almeno una sua replica deve essere integro nel cluster. Questo messaggio di errore viene visualizzato se non risulta 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 il componente k8s-extension installato nel cluster.

ERROR: ResourceNotReady

Per eseguire il file score.py fornito come parte della distribuzione, Azure crea un contenitore che include tutte le risorse necessarie a score.py ed esegue lo script di assegnazione punteggio in tale contenitore. L'errore in questo scenario fa riferimento al fatto che questo contenitore si arresta in modo anomalo durante l'esecuzione, il che significa che risulta impossibile eseguire l'assegnazione del punteggio. Questo errore si verifica quando:

  • Si verifica un errore in score.py. Usare get-logs per eseguire la diagnostica dei problemi comuni:
    • Un pacchetto che score.py tenta di importare non è incluso nell'ambiente conda.
    • Errore di sintassi.
    • Errore nel metodo init().
  • Se get-logs non restituisce alcun log, in genere significa che l'avvio del contenitore non è riuscito. Per eseguire il debug di questo problema, provare invece a eseguire la distribuzione localmente.
  • I probe di idoneità o attività non sono configurati correttamente.
  • L'inizializzazione del contenitore richiede troppo tempo e pertanto il probe di idoneità o attività ha esito negativo quando supera la soglia di errore. In questo caso, modificare le impostazioni del probe per concedere più tempo all'inizializzazione del contenitore. In alternativa, tra gli SKU di macchine virtuali supportati scegliere uno SKU della macchina virtuale di dimensioni maggiori, in grado di accelerare l'inizializzazione.
  • Si è verificato un errore nella configurazione dell'ambiente 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.

ERROR: ResourceNotFound

L'elenco seguente riporta i motivi 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 con estrema attenzione le risorse che potrebbero essere state specificate mediante un percorso esatto o l'ortografia dei relativi nomi.

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

Errore di autorizzazione del registro contenitori

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

Per ridurre l'impatto di questo errore, assicurarsi che il registro contenitori non sia privato o attenersi alla procedura seguente:

  1. Concedere il ruolo acrPull del 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 dell'errore ha esito positivo, l'immagine non richiede la compilazione e l'indirizzo dell'immagine finale sarà 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 di diagnostica dell'area di lavoro.

ERRORE: WorkspaceManagedNetworkNotReady

Questo errore si verifica quando si tenta di creare una distribuzione online nell'area di lavoro in cui è stata abilitata la rete virtuale gestita dell'area di lavoro, ma non è ancora stato effettuato il provisioning della rete virtuale gestita. Prima di creare una distribuzione online, è necessario effettuare il provisioning della rete virtuale gestita dell'area di lavoro. Seguire le istruzioni Effettuare manualmente il provisioning della rete virtuale gestita dell'area di lavoro per effettuare manualmente il provisioning della rete virtuale gestita dell'area di lavoro. Al termine, è possibile iniziare a creare distribuzioni online. Per altre informazioni, vedere Isolamento della rete con endpoint online gestito e Proteggere gli endpoint online gestiti con isolamento di rete.

ERROR: OperationCanceled

L'elenco seguente riporta i motivi per cui è possibile riscontrare 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 dalla priorità più alta a quella più bassa. Questo errore si verifica quando l'operazione è stata sostituita da un'altra operazione con priorità più alta.

Il nuovo tentativo di esecuzione dell'operazione potrebbe comportare la sua 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 acquisiscono un blocco per evitare 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. L'errore 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.

ERROR: SecretsInjectionError

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 nella 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 all'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).

ERROR: InternalServerError

Anche se l'impegno Microsoft mira a fornire un servizio stabile e affidabile, a volte le cose non vanno secondo i piani. Se viene visualizzato questo errore, significa che qualcosa non è andato a buon fine a livello di server e la risoluzione di questo problema è responsabilità di Microsoft. Inviare un ticket di supporto clienti con tutte le informazioni correlate necessarie per la risoluzione del problema.

Errori comuni specifici delle distribuzioni Kubernetes

Errori relativi all'identità e all'autenticazione:

Errori relativi a crashloopbackoff:

Errori relativi allo script di punteggio:

Altri:

ERROR: ACRSecretError

L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore durante la creazione e l'aggiornamento delle distribuzioni online 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.

ERROR: TokenRefreshFailed

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

ERROR: GetAADTokenFailed

Questo errore è dovuto al fatto che il token di Azure AD della richiesta del cluster Kubernetes ha avuto esito negativo o si è verificato il timeout; controllare l'accessibilità di rete e riprovare.

  • È possibile fare riferimento alla sezione 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 nella definizione di risorse personalizzate (CRD) dell'endpoint online nel cluster.

Se l'area di lavoro è un'area di lavoro privata, con l'accesso alla rete pubblica disabilitato, 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 l'ambiente di inferenza del servizio Azure Kubernetes.

ERROR: 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 validi per l'errore GetAADTokenFailed per controllare la rete.

ERROR: ACRTokenExchangeFailed

Questo errore è dovuto al fatto che il token del Registro Azure Container per lo scambio di cluster Kubernetes ha avuto esito negativo perché il token di Azure AD non è ancora autorizzato. Poiché l'assegnazione di ruolo richiede tempo, è possibile attendere e quindi riprovare.

Questo errore potrebbe anche essere dovuto a un numero eccessivo di richieste al servizio Registro Azure Container in determinato momento. Poiché dovrebbe essere un errore temporaneo, è possibile riprovare in un secondo momento.

ERROR: 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 ridurre l'impatto di questo errore, è possibile:

ERROR: ImagePullLoopBackOff

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è dovuto al fatto che non è possibile scaricare le immagini dal registro contenitori e ciò causa 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 per verificare se il cluster può eseguire il pull dell'immagine dal registro contenitori.

ERROR: DeploymentCrashLoopBackOff

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è l'arresto anomalo dell'inizializzazione del contenitore utente. Le cause di questo errore possono essere due:

  • Lo script utente score.py presenta un errore di sintassi o un errore di importazione e pertanto eccezioni durante l'inizializzazione.
  • In alternativa, il pod di distribuzione richiede una quantità di memoria maggiore rispetto al limite.

Per ridurre l'impatto di questo errore, è prima possibile controllare i log di distribuzione per verificare la presenza di eventuali eccezioni negli script utente. Se l'errore persiste, provare a estendere il limite di memoria per il tipo di istanza o le risorse.

ERROR: KubernetesCrashLoopBackOff

L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore durante la creazione e l'aggiornamento di endpoint/distribuzioni online Kubernetes:

  • Uno o più pod bloccati nello stato CrashLoopBackoff; è possibile verificare se il log di distribuzione esiste e se sono presenti messaggi di errore nel log.
  • Si verifica un errore in score.py e il contenitore si arresta in modo anomalo quando viene inizializzato il codice del punteggio; fare riferimento alla parte ERROR: ResourceNotReady.
  • Il processo di assegnazione del punteggio richiede una quantità maggiore di memoria rispetto al limite della configurazione della distribuzione. È possibile provare ad aggiornare la distribuzione con un limite di memoria superiore.

ERROR: NamespaceNotFound

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento degli endpoint online Kubernetes è l'indisponibilità dello spazio dei nomi usato dall'ambiente di calcolo Kubernetes nel cluster.

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

ERROR: UserScriptInitFailed

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il fatto che la funzione init nel file caricato score.py ha generato un'eccezione.

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

ERROR: UserScriptImportError

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il fatto che il file score.py caricato ha importato pacchetti non disponibili.

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

ERROR: UserScriptFunctionNotFound

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

ERROR: EndpointNotFound

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il 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.

ERROR: EndpointAlreadyExists

Il motivo per cui è possibile che si verifichi questo errore durante la creazione di un endpoint online Kubernetes è il fatto che l'endpoint in fase di creazione esiste già nel cluster.

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

ERROR: ScoringFeUnhealthy

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento di un endpoint online Kubernetes/distribuzione online è il fatto che il servizio di sistema Azureml-fe 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.

ERROR: ValidateScoringFailed

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il fatto che la convalida dell'URL della richiesta di assegnazione del punteggio non è riuscita durante l'elaborazione della distribuzione del modello.

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

ERROR: InvalidDeploymentSpec

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il fatto che la specifica di distribuzione non è valida.

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

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

ERROR: PodUnschedulable

L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore durante la creazione e l'aggiornamento di endpoint/distribuzioni online Kubernetes:

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

Per ridurre l'impatto di questo errore, seguire questa procedura:

  • Controllare la definizione di node selector del parametro instance type usato e la configurazione di node label dei nodi del cluster.
  • Controllare instance type e 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 dispone di risorse insufficienti, è possibile ridurre il requisito della risorsa di tipo istanza o usare un altro tipo di istanza con requisiti inferiori a livello di risorse richieste.
  • Se il cluster non dispone più di risorse per soddisfare il requisito della distribuzione, eliminare alcune distribuzioni per rilasciare le risorse.

ERROR: PodOutOfMemory

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento della distribuzione online è il fatto che il limite di memoria assegnato per la distribuzione risulta insufficiente. È possibile impostare il limite di memoria su un valore maggiore o usare un tipo di istanza più grande per ridurre l'impatto di questo errore.

ERROR: InferencingClientCallFailed

Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento di endpoint online Kubernetes/distribuzioni è il fatto che l'estensione k8s del cluster Kubernetes nel cluster non è collegabile.

In questo caso, è possibile scollegare e quindi ricollegare l'ambiente di calcolo.

Nota

Per risolvere gli errori mediante lo scollegamento, assicurarsi di rieseguire il collegamento con la stessa configurazione dell'ambiente di calcolo scollegato in precedenza, ad esempio lo stesso nome dell'ambiente di calcolo e lo stesso spazio dei nomi. In caso contrario, potrebbero verificarsi altri errori.

Se il problema persiste, è possibile chiedere all'amministratore con accesso al cluster di 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 si riferisce agli errori comuni di utilizzo del modello risultanti dallo stato dell'operazione invoke dell'endpoint.

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 analizzare 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, vengono restituiti due trailer di risposta:
    • ms-azureml-bandwidth-request-delay-ms: tempo di ritardo in millisecondi necessario per il trasferimento del flusso della richiesta.
    • ms-azureml-bandwidth-response-delay-ms: tempo di ritardo in millisecondi necessario per il trasferimento del flusso della risposta.

Codici di stato HTTP

Quando si accede ai servizi Web con richieste REST, i codici di stato restituiti rispettano gli standard dei codici di stato HTTP. Di seguito sono riportate informazioni dettagliate sul mapping tra gli errori di chiamata e previsione del servizio Web e i codici di stato HTTP.

Codici di errore comuni per gli endpoint online gestiti

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

Codice di stato Frase per il motivo Possibile motivo della restituzione di questo codice
200 OK Il modello è stato eseguito correttamente nel rispetto 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 in request_timeout_ms in request_settings della configurazione della distribuzione del modello.
424 Errore del modello Se il contenitore di modelli restituisce una risposta non 200, Azure restituisce una risposta 424. Controllare la dimensione Model Status Code nella metrica Requests Per Minute in Esplora metriche di Monitoraggio di Azure dell'endpoint. In alternativa, controllare le intestazioni della risposta ms-azureml-model-error-statuscode e ms-azureml-model-error-reason per altre informazioni. Se la risposta 424 presenta problemi a livello di probe di attività o idoneità, valutare la possibilità di modificare le impostazioni del probe per consentire tempi più lunghi per esaminare l'attività o l'idoneità del contenitore.
429 Troppe richieste in sospeso Il modello sta attualmente ricevendo più richieste di quante 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 ottimale. Le 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 RequestSettings, è importante assicurarsi che la variabile di ambiente WORKER_COUNT venga passata correttamente.

Se si usa la scalabilità automatica e si riceve questo errore, significa che il modello sta ricevendo richieste più rapidamente rispetto alla velocità con cui il sistema in grado di aumentare le prestazioni. In questo caso, valutare la possibilità di inviare di nuovo le richieste con un backoff esponenziale per fornire al sistema il tempo di adeguamento necessario. È anche possibile aumentare il numero di istanze usando il codice per calcolare il numero di istanze. Questi passaggi, assieme all'impostazione della scalabilità automatica, consentono di garantire che il modello sia pronto per gestire il flusso di richieste in entrata.
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 per il motivo Possibile motivo della restituzione di questo codice
409 errore di conflitto Quando un'operazione è già in corso, qualsiasi nuova operazione nello stesso endpoint online risponderà 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 metodo run() 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 metodo init(). È possibile seguire la procedura descritta qui per eseguire il debug del file.
503 Ricevere un numero elevato di picchi nelle richieste al secondo La scalabilità automatica è progettata per gestire variazioni graduali a livello di carico. Se si riceve un numero elevato di picchi nelle richieste al secondo, i client potrebbero ricevere un codice di stato HTTP 503. Anche se la scalabilità automatica reagisce rapidamente, il servizio Azure Kubernetes richiede molto tempo per creare più contenitori. È possibile seguire la procedura descritta qui per evitare codici di stato 503.
504 Timeout della richiesta Un codice di stato 504 indica che si è verificato il timeout della richiesta. L'impostazione predefinita del timeout è di 5 secondi. È possibile aumentare il timeout o provare ad accelerare l'endpoint modificando il file score.py per rimuovere le chiamate non necessarie. Se queste azioni non risolvono il problema, è possibile seguire questa procedura per eseguire il debug del file 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 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 si basano 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 combinati.

  • 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 sta già usando il numero massimo di repliche correnti e vengono ancora visualizzati codici di stato 503, aumentare il valore di autoscale_max_replicas 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 in base a 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 di dimensioni maggiori di quelle che possono essere gestite dalle nuove repliche minime, si potrebbero ricevere nuovamente codici di stato 503. Ad esempio, mano a mano che il traffico verso l'endpoint aumenta, 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 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, il gateway applicazione di Azure o qualsiasi servizio come livello provvisorio 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, questo disabilita le API v2. Gli endpoint online gestiti sono una funzionalità della piattaforma API v2 e non funzionano se v1_legacy_mode è abilitato per l'area di lavoro.

Importante

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

Per informazioni su come disabilitare v1_legacy_mode, vedere Isolamento 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 di questo comando è simile al documento JSON seguente:

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

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

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

Nota

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

  1. Controllare se il flag egress-public-network-access è 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 la propria 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 campo status sia impostato su Approved. Se non è approvato, 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 comando nslookup 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 specificato dalla rete virtuale

    Nota

    Per un endpoint online Kubernetes, il nome host dell'endpoint deve essere il 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 si può ottenere direttamente nell'interfaccia utente di Studio. Altri modi per ottenere l'indirizzo IP dell'endpoint sono disponibili in Endpoint online Kubernetes sicuro.

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

    Per l'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, quindi 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 Kubernetes,

    1. Controllare la configurazione DNS nel cluster Kubernetes.

    2. Inoltre, per 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, controllare la validità del certificato.

    Se il problema non viene risolto per il record A, verificare se la risoluzione funziona dal 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 eseguita 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 venga 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 di questo comando deve riportare la percentuale di traffico assegnato alle distribuzioni.

  3. Se le assegnazioni di traffico (o l'intestazione della 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 controllare se si è verificato un problema durante l'esecuzione del codice di assegnazione dei punteggi quando una richiesta viene inviata alla distribuzione.

Risolvere i problemi del server di inferenza

In questa sezione vengono forniti suggerimenti di base per la risoluzione dei problemi del 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 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 pip può portare a versioni impreviste dei pacchetti installati.
  3. Se si specifica Flask (e/o le relative dipendenze) nell'ambiente, rimuoverle. Le dipendenze includono Flask, Jinja2, itsdangerous, Werkzeug, MarkupSafe e click. Flask è elencato come dipendenza nel pacchetto del server ed è consigliabile consentire l'installazione da parte del server. In questo modo, quando il server supporta le nuove versioni di Flask, tali versioni verranno recuperate automaticamente.

Versione del server

Il pacchetto server azureml-inference-server-http 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 nel pacchetto delle immagini di training ≤ 20220601 e in azureml-defaults>=1.34,<=1.43. 0.4.13 è l'ultima versione stabile. Se si usa il server anteriore alla versione 0.4.11, potrebbero verificarsi problemi di dipendenze 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 pacchetto azureml-inference-server-http ne sarà dipendente 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 dell'SDK. Ad esempio, se la versione dell'SDK è 1.38.0, verrà aggiunto 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 è in esecuzione una versione di azureml-inference-server-http che non supporta Flask 2. Il supporto di Flask 2 viene aggiunto in azureml-inference-server-http>=0.7.0, che anche si trova 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 la voce "Materialization Build", che nell'esempio precedente è 20220708 o 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 una sostituzione.

  • Se si usa il server con un endpoint online, è anche possibile trovare i log in "Log di distribuzione" nella pagina dell'endpoint online nello studio di Azure Machine Learning. Se si esegue la distribuzione con SDK v1 e non si specifica in modo esplicito un'immagine nella configurazione di distribuzione, per impostazione predefinita viene usata una versione di openmpi4.1.0-ubuntu20.04 corrispondente al set di strumenti dell'SDK locale, che potrebbe non essere la versione più recente dell'immagine. Ad esempio, SDK 1.43 usa l'impostazione predefinita openmpi4.1.0-ubuntu20.04:20220616, 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à la versione precedente del server con Flask 1.0.x.

2. È stato rilevato un errore ImportError o ModuleNotFoundError nei moduli opencensus, jinja2, MarkupSafe o 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