Condividi tramite

Risolvere i problemi di distribuzione e valutazione degli endpoint online

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

Questo articolo descrive come risolvere i problemi comuni di distribuzione e assegnazione del punteggio degli endpoint online di Azure Machine Learning.

Questo documento rispecchia la struttura in base alla quale si dovrebbe 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.

La sezione Codici di stato HTTP spiega che gli errori di richiesta e previsione si trasformano in codici di stato HTTP durante l'assegnazione dei punteggi agli endpoint con richieste REST.

Prerequisiti

Tracciamento delle richieste

Sono supportate due intestazioni di traccia:

  • x-request-id è riservato per la traccia del server. Azure Machine Learning esegue l'override di questa intestazione per accertarsi che sia un GUID valido. 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 accetta solo caratteri alfanumerici, trattini e caratteri di sottolineatura e viene troncata a un massimo di 40 caratteri.

Distribuire in locale

La distribuzione locale consiste nel distribuire un modello in un ambiente Docker locale. La distribuzione locale supporta la creazione, l'aggiornamento e l'eliminazione di un endpoint locale e consente di richiamare e ottenere i log dall'endpoint. La distribuzione locale è utile per il test e il debug prima della distribuzione nel cloud.

Suggerimento

Inoltre si può usare il pacchetto Python del server HTTP di inferenza di Azure Machine Learning per eseguire il debug dello script di assegnazione del punteggio 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.

Si può distribuire in locale con l'interfaccia della riga di comando di Azure o dell’SDK di Python. Studio di Azure Machine Learning non supporta la distribuzione locale o gli endpoint locali.

Per la distribuzione locale, aggiungere --local al comando appropriato.

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

La distribuzione locale include i seguenti passaggi:

  1. Docker compila una nuova immagine del contenitore o esegue il pull di un'immagine esistente dalla cache Docker locale. Docker utilizza una immagine esistente se corrisponde alla parte ambientale del file delle specifiche.
  2. Docker avvia un nuovo contenitore con gli artefatti locali montati, ad esempio file di modello e codice.

Per altre informazioni, vedere Distribuire ed eseguire il debug in locale usando un endpoint locale.

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.

Ottenere i log dei contenitori

Non si può ottenere l'accesso diretto a una macchina virtuale (VM) in cui viene distribuito un modello, ma si possono ottenere i log da alcuni dei container in esecuzione sulla VM. La quantità di informazioni ottenute dipende dallo stato di provisioning della distribuzione. Se il contenitore specificato è operativo, verrà visualizzato l'output della console. In caso contrario, viene mostrato un messaggio che invita a riprovare più tardi.

Si possono ottenere i log dai tipi di contenitori seguenti:

  • Il log della console del server di inferenza contiene l'output delle funzioni di stampa e registrazione dal codice dello script di assegnazione del punteggio score.py.
  • I log dell'inizializzatore di archiviazione 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 l'endpoint online Kubernetes, gli amministratori possono accedere direttamente al cluster in cui si distribuisce il modello e controllare i log in Kubernetes. Ad esempio:

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

Nota

Se si usa la registrazione Python, accertarsi di usare il livello di registrazione corretto, ad esempio INFO, per la pubblicazione dei messaggi nei log.

Vedere l'output del log dai contenitori

Per visualizzare l'output del log da un contenitore, usare il seguente comando:

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

Oppure

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

Per impostazione predefinita, i log vengono estratti dal server di inferenza. È anche possibile ottenere i log dal contenitore dell'inizializzatore di archiviazione includendo –-container storage-initializer.

Aggiungere --resource-group e --workspace-name a questi comandi se questi parametri non sono già stati impostati tramite az configure. Per vedere le informazioni su come impostare questi parametri o se sono stati impostati valori, eseguire il seguente comando:

az ml online-deployment get-logs -h

Aggiungere --help o --debug ai comandi per vedere altre informazioni.

Errori di distribuzione comuni

Lo stato dell'operazione di distribuzione può segnalare gli errori di distribuzione comuni seguenti:

Se si sta creando o aggiornando una distribuzione online Kubernetes, vedere anche gli errori comuni specifici per le distribuzioni Kubernetes.

ERRORE: ImageBuildFailure

Questo errore viene restituito quando viene compilato l'ambiente immagine Docker. Si può controllare il log di compilazione per altre informazioni sull’errore. 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]'".

Le sezioni che seguono mostrano i contesti comuni in cui si può verificare un errore di compilazione delle immagini:

Errore di autorizzazione del Registro Azure Container

Un messaggio di errore segnala "container registry authorization failure" quando non si può accedere al registro del container con le credenziali correnti. La desincronizzazione delle chiavi delle risorse dell'area di lavoro può causare questo errore e la sincronizzazione automatica richiede tempo. Tuttavia, si può richiedere manualmente la sincronizzazione delle chiavi con az ml workspace sync-keys e ciò potrebbe risolvere l'errore di autorizzazione.

Anche i registri contenitori che si trovano dietro una rete virtuale possono causare questo errore se non sono stati configurati correttamente. È necessario verificare che la rete virtuale sia configurata correttamente.

Ambiente di calcolo di compilazione dell’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 Registro Azure Container dell'area di lavoro è privato e configurato con un endpoint privato, è necessario consentire a Registro Azure Container di compilare immagini nella rete virtuale.

Timeout di compilazione delle immagini

I timeout di compilazione delle immagini spesso si verificano perché un’immagine è troppo grande affinché la compilazione possa essere completata entro l'intervallo di tempo di creazione della distribuzione. Controlla i log di compilazione dell'immagine nella posizione specificata dall'errore. I log vengono tagliati al momento del timeout di compilazione dell'immagine.

Per risolvere questo problema, compilare l'immagine separatamente in modo che debba essere estratta solo durante la creazione della distribuzione. Rivedere anche le impostazioni predefinite del probe se sono presenti timeout di ImageBuild.

Errore di creazione dell'immagine generica

Controllare il log di compilazione per altre informazioni sull’errore. Se non viene rilevato alcun errore esplicito nel log di compilazione e l'ultima riga è Installing pip dependencies: ...working..., è possibile che una dipendenza stia causando l’errore. Il bloccaggio delle dipendenze di versione nel file conda può risolvere questo problema.

Provare a distribuire in locale per testare ed eseguire il debug dei modelli prima della distribuzione nel cloud.

ERRORE: OutOfQuota

Le risorse seguenti potrebbero esaurire la quota quando si usano i servizi di Azure:

Solo per gli endpoint online Kubernetes, anche la risorsa Kubernetes potrebbe esaurire la quota.

Quota della CPU

Prima di distribuire un modello, è necessario disporre di una quota di calcolo sufficiente. La quota della CPU definisce quanti core virtuali sono disponibili per sottoscrizione, per area di lavoro, per SKU e per regione. Ogni distribuzione sottrae un valore dalla quota disponibile e lo aggiunge nuovamente dopo l'eliminazione, in base al tipo di SKU.

Si può controllare se sono presenti distribuzioni inutilizzate che potrebbero essere eliminate oppure inviare una richiesta di aumento della quota.

Quota del cluster

L’errore OutOfQuota si verifica quando la quota del cluster di elaborazione di Azure Machine Learning non è sufficiente. La quota definisce il numero totale di cluster per ciascuna sottoscrizione che potrebbero essere in uso contemporaneamente per distribuire nodi CPU o GPU nel cloud di Azure.

Quota del disco

L’errore OutOfQuota 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

L’errore OutOfQuota 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 affinché l’identità gestita possa accedere alle risorse dell'area di lavoro. Se viene raggiunto il limite dell'assegnazione di ruolo, provare a eliminare alcune assegnazioni di ruolo non usate in questa sottoscrizione. Si possono controllare tutte le assegnazioni di ruolo selezionando Controllo di accesso per la sottoscrizione di Azure nel portale di Azure.

Quota degli endpoint

Cerca di eliminare alcuni endpoint inutilizzati in questa sottoscrizione. Se tutti gli endpoint sono attivamente in uso, 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

L’errore OutOfQuota 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 l'insufficienza della risorsa nel cluster, ad esempio OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Questo messaggio indica che nel cluster sono presenti troppi pod e le risorse per distribuire il nuovo modello basato sulla richiesta non sono sufficienti.

Prova la mitigazione seguente per risolvere questo problema:

  • Gli operatori IT che gestiscono il cluster Kubernetes, possono provare ad aggiungere altri nodi o cancellare alcuni pod inutilizzati nel cluster per rilasciare alcune risorse.

  • Gli ingegneri di machine learning che distribuiscono i modelli, possono 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, provare a ridurre la richiesta di risorse.
    • Se si usa instance_type per definire la risorsa per la distribuzione del modello, contattare l'operatore IT per modificare la configurazione della risorsa del tipo di istanza. Per altre informazioni, vedere Creare e gestire i tipi di istanze.

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. Azure Machine Learning esegue quindi lo script di assegnazione del punteggio in tale contenitore. Se il contenitore non può avviarsi, i punteggio non può essere eseguito. È possibile che il contenitore richieda più risorse di quelle supportate da instance_type. Prendere in considerazione l'aggiornamento di instance_type della distribuzione online.

Per individuare il motivo esatto dell'errore, eseguire l'azione seguente.

Esegui questo comando:

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

ERRORE: Argomento errato

Si potrebbe ricevere questo errore quando si usa l'endpoint online gestito o l'endpoint online Kubernetes, per i motivi seguenti:

Potrebbe anche verificarsi questo errore quando si utilizzano gli endpoint online di Kubernetes solo per i seguenti motivi:

La sottoscrizione non esiste

La sottoscrizione di Azure a cui si fa riferimento deve essere esistente e attiva. Questo errore si verifica quando Azure non riesce a trovare l'ID sottoscrizione che stato immesso. L’errore potrebbe essere dovuto a un errore nell’immissione dell'ID sottoscrizione. Verificare che l'ID sottoscrizione sia stato immesso correttamente e che sia attivo attualmente.

Errore di autorizzazione

Dopo avere effettuato il provisioning della risorsa di calcolo quando si crea la distribuzione, Azure esegue il pull dell'immagine del contenitore utente dal registro contenitori dell'area di lavoro e monta il modello utente e gli artefatti di codice nel contenitore utente dall'account di archiviazione dell'area di lavoro. Azure usa le identità gestite per accedere all'account di archiviazione e al registro contenitori.

Se l'endpoint associato è stato creato con l'identità assegnata dall'utente, l'identità gestita dell'utente deve disporre dell'autorizzazione del lettore dati archiviazione BLOB per l'account di archiviazione dell'area di lavoro e l'autorizzazione AcrPull per il registro contenitori dell’area di lavoro. Accertarsi che l'identità assegnata all'utente abbia l'autorizzazione corretta.

Quando MDC è abilitato, l'identità gestita dell'utente deve disporre dell'autorizzazione Collaboratore ai dati dei BLOB di archiviazione per l'account di archiviazione dell'area di lavoro. Per altre informazioni, vedere Errore di autorizzazione BLOB di archiviazione quando MDC è abilitato.

Se si crea l'endpoint associato con un'identità assegnata dal sistema, l'autorizzazione per il controllo degli accessi in base al ruolo (RBAC) di Azure viene concessa automaticamente e pertanto non sono necessarie ulteriori autorizzazioni. Per altre informazioni, vedere Errore di autorizzazione del registro dei 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 potrebbe includere il nome dell'assegnazione dei criteri e la definizione dei criteri per facilitare il debug di questo errore. Per suggerimenti per evitare errori di modello, vedere struttura di definizione dei criteri di Azure.

Non è possibile scaricare l'immagine del contenitore utente

Potrebbe essere impossibile trovare il contenitore utente. Controllare i log dei contenitori per avere altri dettagli.

Accertarsi che l'immagine del contenitore sia disponibile nel registro contenitori dell'area di lavoro. Ad esempio, se l'immagine è testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, si può usare il comando seguente per controllare il repository:

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

Non è possibile scaricare il modello dell'utente

Potrebbe essere impossibile trovare il modello utente. Controllare i log dei contenitori per avere altri dettagli. Assicurati di aver registrato il modello nella stessa area di lavoro utilizzata per la distribuzione.

Per visualizzare i dettagli di un modello in un'area di lavoro, procedere come segue. Per visualizzare le informazioni del modello è necessario specificare la versione o l'etichetta.

Esegui questo comando:

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

Verificare anche 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, si può usare il comando seguente per verificarne l'esistenza:

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

Se il BLOB esiste, si può usare il comando seguente 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

La 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 per gli endpoint online gestiti. Se è necessario distribuire un modello MLflow con l'approccio di distribuzione senza codice, provare a usare una 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, Azure Machine Learning imposta i valori per impostazione predefinita quando si collega un ambiente di calcolo a un'area di lavoro. Si possono 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 si installa durante l’installazione dell’estensione k8s e viene ridimensionato automaticamente in base alle esigenze. Questo componente dovrebbe avere almeno una replica funzionante nel cluster.

Si riceve questo errore se il componente non risulta disponibile quando si attiva un endpoint online Kubernetes o la richiesta di creazione o aggiornamento della distribuzione. Controllare lo stato e i log del pod per risolvere il problema. È anche possibile provare ad aggiornare l’estensione k8s installata nel cluster.

ERRORE: ResourceNotReady

Per eseguire il file score.py che si è fornito come parte della distribuzione, Azure crea un contenitore che include tutte le risorse necessarie a score.py ed esegue lo script di assegnazione del punteggio in tale contenitore. L'errore in questo contesto è che il contenitore si arresta in modo anomalo durante l'esecuzione, quindi l’assegnazione del punteggio non può avvenire. Questo errore si può verificare a causa di una delle condizioni seguenti:

  • Si è verificato un errore in score.py. Usare get-logs per eseguire la diagnostica dei problemi comuni, ad esempio:

    • Un pacchetto che score.py prova a importare che non è incluso nell'ambiente Conda
    • Un errore di sintassi
    • Un errore nel metodo init()

    Se get-logs non crea alcun log, in genere significa che l'avvio del contenitore non è riuscito. Per eseguire il debug di questo problema, provare la distribuzione in locale.

  • Le probe di prontezza o vitalità non sono configurate correttamente.

  • L'inizializzazione del contenitore richiede troppo tempo, quindi la sonda di idoneità o di vitalità fallisce oltre la soglia di errore. In questo caso, modificare le impostazioni del probe per concedere più tempo all'inizializzazione del contenitore. Oppure prova con uno SKU di macchine virtuali supportato più grande, che accelera l'inizializzazione.

  • Si è verificato un errore nella configurazione dell'ambiente del contenitore, ad esempio una dipendenza mancante.

    Quando si riceve 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 Risolvere dei problemi del server HTTP.

ERROR: RisorsaNonTrovata

Si potrebbe ricevere questo errore mentre si usa l'endpoint online gestito o l'endpoint online Kubernetes, per i motivi seguenti:

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, si può ricevere questo errore se non è possibile trovare un account di archiviazione nel percorso in cui è stato specificato. Controllare due volte le specifiche del percorso o del nome per l'accuratezza e l'ortografia. Per altre informazioni, vedere Risolvere gli errori di Risorsa non trovata.

Errore di autorizzazione del registro dei container

Questo errore si verifica quando per la distribuzione è stata specificata un'immagine appartenente a un registro contenitori privato o inaccessibile. Le API di Azure Machine Learning non possono accettare credenziali di un registro privato.

Per mitigare questo errore, accertarsi che il registro contenitori non sia privato o procedere come segue:

  1. Concedere il ruolo acrPull del registro privato all'identità di sistema dell'endpoint online.
  2. Nella definizione dell'ambiente, specifica l'indirizzo della tua immagine privata e indica di non modificare o creare l'immagine.

Se questa mitigazione ha esito positivo, l'immagine non richiede la costruzione e l'indirizzo dell'immagine finale sarà l'indirizzo dell'immagine fornito. 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: ReteGestitaDaWorkspaceNonPronta

Questo errore si verifica se si prova a creare una distribuzione online che abilita una rete virtuale gestita dell'area di lavoro, ma non è ancora stato effettuato il provisioning della rete virtuale gestita. Effettuare il provisioning della rete virtuale gestita dell'area di lavoro prima di creare una distribuzione online.

Per effettuare manualmente il provisioning della rete virtuale gestita dell'area di lavoro, seguire le istruzioni riportate in Effettuare manualmente il provisioning della rete virtuale gestita dell'area di lavoro. Si può quindi iniziare a creare le distribuzioni online. Per altre informazioni, vedere Isolamento della rete con un endpoint online gestito e Proteggere gli endpoint online gestiti con l’isolamento della rete.

ERRORE: Operazione annullata

Si potrebbe ricevere questo errore mentre si usa l'endpoint online gestito o l'endpoint online Kubernetes, per i motivi seguenti:

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

Le operazioni di Azure hanno un determinato livello di priorità e vengono eseguite dalla più alta alla più bassa. Questo errore si verifica quando un’altra operazione con priorità più alta sostituisce l’operazione. Riprovare l’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 ottengono 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 prima di procedere.

Potrebbe essere stata inviata una richiesta simile troppo presto dopo la richiesta iniziale. Riprovare l'operazione dopo aver atteso fino a un minuto potrebbe consentire di eseguirla senza annullamento.

ERRORE: 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 endpoint o dagli insiemi di credenziali delle chiavi. Questo problema si verifica per uno dei motivi seguenti:

  • L'identità dell'endpoint non dispone dell'autorizzazione Azure RBAC per leggere i segreti dalle connessioni all'area di lavoro o dai key vault, anche se la definizione di distribuzione ha specificato i segreti come riferimenti mappati a variabili d'ambiente. L’assegnazione di ruolo può richiedere tempo per rendere effettive le modifiche.

  • Il formato dei riferimenti al segreto non è valido o i segreti specificati non esistono nelle connessioni all'area di lavoro 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: Errore interno del server

Questo errore indica che si è verificato un problema con il servizio Azure Machine Learning che deve essere risolto. Inviare un ticket all’assistenza clienti con tutte le informazioni necessarie per la risoluzione del problema.

Errori comuni specifici delle distribuzioni Kubernetes

Errori di identità e autenticazione:

Errori Crashloopbackoff:

Errori di assegnazione del punteggio:

Altri errori:

ERRORE: ACRSecretError

Quando si creano o si aggiornano distribuzioni online di Kubernetes, si potrebbe ricevere questo errore per uno dei motivi seguenti:

  • L'assegnazione di ruolo non è stata completata. Attendere alcuni secondi e riprovare.

  • L'estensione del cluster Kubernetes abilitato per Azure Arc o l'estensione di Azure Machine Learning per AKS non è installata o configurata correttamente. Controllare la configurazione e lo stato dell'estensione Azure Arc-enabled di Kubernetes o di Azure Machine Learning.

  • Il cluster Kubernetes ha una configurazione di rete non corretta. Controllare il proxy, i criteri di rete o il certificato.

  • Il cluster del servizio Azure Kubernetes privato non ha gli endpoint appropriati. Accertarsi di configurare gli endpoint privati per Registro Container, l'account di archiviazione e lo spazio di lavoro nella rete virtuale AKS.

  • La versione dell'estensione Azure Machine Learning è 1.1.25 o successiva. Accertarsi che la versione dell'estensione sia successiva alla versione 1.1.25.

ERRORE: Aggiornamento del token non riuscito

Questo errore è dovuto al fatto che l'identità del cluster Kubernetes non è impostata correttamente, quindi l'estensione non può ottenere una credenziale dell’entità di sicurezza da Azure. Reinstallare l'estensione Azure Machine Learning e riprovare.

ERRORE: GetAADTokenFailed

Questo errore si verifica perché la richiesta del cluster Kubernetes richiede il token ID Microsoft Entra non è riuscita o si è verificato il timeout. Controllare l'accesso alla rete e riprovare.

  • Seguire le istruzioni in Usare l’ambiente di calcolo di Kubernetes per controllare il proxy in uscita e accertarsi che il cluster possa connettersi all'area di lavoro. Si può trovare l'URL dell'endpoint dell'area di lavoro nell'endpoint online Custom Resource Definition (CRD) nel cluster.

  • Controllare se l'area di lavoro consente l'accesso pubblico. Indipendentemente dal fatto che il cluster del servizio Azure Kubernetes sia pubblico o privato, se un'area di lavoro privata disabilita l'accesso alla rete pubblica, il cluster Kubernetes può comunicare con tale area di lavoro solo tramite un collegamento privato. Per ulteriori informazioni, vedere Che cos'è un ambiente di inferenza sicuro di AKS.

ERRORE: Autenticazione ACRFallita nella sfida di Challange

Questo errore è dovuto al fatto che il cluster Kubernetes non riesce a raggiungere il servizio Registro Azure Container dell'area di lavoro per eseguire un test di autenticazione. Controlla la tua rete, in particolare l'accesso alla rete pubblica del registro dei contenitori, poi riprova. È possibile seguire i passaggi di risoluzione dei problemi in GetAADTokenFailed per verificare la rete.

ERRORE: Scambio di token ACR fallito

Questo errore si verifica perché il token Microsoft Entra ID non è ancora stato autorizzato, quindi lo scambio tra il token del Registro Azure Container e il cluster Kubernetes ha esito negativo. Poiché l'assegnazione di ruolo richiede tempo, attendere un minuto e quindi riprovare.

Questo errore potrebbe anche essere dovuto a troppe richieste simultanee al servizio Registro Azure Container. Questo errore dovrebbe essere temporaneo ed si può riprovare più tardi.

ERRORE: Kubernetes non accessibile

Si potrebbe ricevere 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 mitigare questo errore, si può ruotare il certificato del servizio Azure Kubernetes per il cluster. Il nuovo certificato deve essere aggiornato dopo 5 ore. Attendere pertanto 5 ore e ridistribuirlo. Per altre informazioni, vedere Rotazione dei certificati nel servizio Azure Kubernetes (AKS).

ERRORE: ImagePullLoopBackOff

Si potrebbe ricevere questo errore durante la creazione o l’aggiornamento delle distribuzioni online Kubernetes se non si possono scaricare le immagini dal registro contenitori con conseguente errore di pull delle immagini. Controllare i criteri di rete del cluster e il registro contenitori dell'area di lavoro per vedere se il cluster può eseguire il pull dell'immagine dal registro contenitori.

ERRORE: DeploymentCrashLoopBackOff

Si potrebbe ricevere questo errore quando si creano o si aggiornano le distribuzioni online di Kubernetes perché il contenitore utente si arresta in modo anomalo durante l'inizializzazione. 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.
  • Il pod di distribuzione richiede una quantità di memoria maggiore rispetto al suo limite.

Per mitigare questo errore, controllare prima 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.

ERRORE: KubernetesCrashLoopBackOff

Si potrebbe ricevere questo errore quando si creano o si aggiornano distribuzioni online di Kubernetes per uno dei motivi seguenti:

  • Uno o più pod sono bloccati nello stato CrashLoopBackoff. Controllare se il log di distribuzione esiste e nel log sono presenti messaggi di errore.
  • Si è verificato un errore in score.py e il contenitore si è arrestato in modo anomalo durante l'inizializzazione del codice del punteggio. Seguire le istruzioni in ERRORE: ResourceNotReady.
  • Il processo di assegnazione del punteggio richiede più memoria rispetto al limite di configurazione della distribuzione. Si può provare ad aggiornare la distribuzione con un limite di memoria maggiore.

ERRORE: NamespaceNotFound

Si potrebbe ricevere questo errore durante la creazione o l’aggiornamento degli endpoint online Kubernetes perché lo spazio dei nomi usato dall'ambiente di calcolo Kubernetes non è disponibile nel cluster. Controlla il calcolo di Kubernetes nel portale della tua area di lavoro e il namespace nel tuo cluster Kubernetes. Se lo spazio dei nomi non è disponibile, rimuovere l'ambiente di calcolo legacy e ricollegarlo per crearne uno nuovo, specificando uno spazio dei nomi già esistente nel cluster.

ERRORE: UserScriptInitFailed

Si potrebbe ricevere questo errore quando si creano o si aggiornano le distribuzioni online di Kubernetes perché la funzione init nel file di score.py caricato ha generato un'eccezione. Controllare i log di distribuzione per visualizzare il messaggio di eccezione in dettaglio e correggere l'eccezione.

ERRORE: UserScriptImportError

Potresti ricevere questo errore quando crei o aggiorni le distribuzioni online di Kubernetes perché il file score.py caricato importa pacchetti non disponibili. Controllare i log di distribuzione per visualizzare il messaggio di eccezione in dettaglio e correggere l'eccezione.

ERRORE: UserScriptFunctionNotFound

Si potrebbe ricevere questo errore quando si creano o si aggiornano le distribuzioni online di Kubernetes perché la funzione nel file di score.py caricato non ha una funzione chiamata init() o run(). Controllare il codice e aggiungere la funzione.

ERRORE: Punto di connessione non trovato

Si potrebbe ricevere questo errore durante la creazione o l’aggiornamento delle distribuzioni online Kubernetes perché il sistema non riesce a trovare la risorsa endpoint per la distribuzione nel cluster. Creare la distribuzione in un endpoint esistente o creare l’endpoint prima nel cluster.

ERRORE: Punto di connessione già esistente

Si potrebbe ricevere questo errore durante la creazione di un endpoint online Kubernetes perché 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. Quindi bisogna creare un endpoint con un altro nome.

ERRORE: ScoringFeUnhealthy

Si potrebbe ricevere questo errore durante la creazione o l’aggiornamento di un endpoint online o una distribuzione di Kubernetes perché il servizio di sistema azureml-fe eseguito nel cluster non viene trovato o non è integro. Per mitigare questo problema bisogna reinstallare o aggiornare l'estensione Azure Machine Learning nel cluster.

ERRORE: ValidateScoringFailed

Si potrebbe ricevere questo errore durante la creazione o l’aggiornamento delle distribuzioni online Kubernetes perché la convalida dell'URL della richiesta di assegnazione del punteggio non è riuscita durante l'elaborazione del modello. Controllare l'URL dell'endpoint e quindi riprovare la distribuzione.

ERRORE: InvalidDeploymentSpec

Si potrebbe ricevere questo errore quando si creano o si aggiornano le distribuzioni online di Kubernetes perché la specifica della distribuzione non è valida. Controllare il messaggio di errore per accertarsi che il instance count sia valido. Se la scalabilità automatica è stata abilitata, accertarsi che minimum instance count e maximum instance count siano entrambi validi.

ERRORE: PodUnschedulable

Si potrebbe ricevere questo errore quando si creano o si aggiornano distribuzioni online di Kubernetes per uno dei motivi seguenti:

  • Non è possibile pianificare il pod nei nodi,per ché le risorse del cluster sono insufficienti.
  • Nessun nodo corrisponde al selettore di affinità dei nodi.

Per mitigare questo errore, fare come indicato di seguito:

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

ERRORE: PodOutOfMemory

Si potrebbe ricevere questo errore quando si crea o si aggiorna una distribuzione online perché il limite di memoria assegnato per la distribuzione é insufficiente. Per mitigare questo errore, si può impostare il limite di memoria su un valore maggiore o usare un tipo di istanza più grande.

ERRORE: InferencingClientCallFailed

Si potrebbe ricevere questo errore quando si creano o si aggiornano endpoint online o distribuzioni Kubernetes perché l'estensione k8s del cluster Kubernetes non può essere connessa. In questo caso, stacca e poi ricollega il computer.

Per risolvere gli errori mediante il ricollegamento, accertarsi di eseguire il ricollegamento con la stessa configurazione dell'ambiente di calcolo rimosso in precedenza, ad esempio lo stesso nome dell'ambiente di calcolo e lo stesso spazio dei nomi per evitare degli errori. Se non dovesse funzionare, si può chiedere all'amministratore con accesso al cluster di usare kubectl get po -n azureml per verificare se i pod del Relay Server sono in esecuzione.

Problemi di uso del modello

Gli errori comuni di uso del modello risultanti dallo stato dell'operazione invoke dell’endpoint includono problemi di limite di larghezza di banda , criteri CORSe vari codici di stato HTTP.

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 riconoscere 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 è il tempo di ritardo in millisecondi necessario per il trasferimento del flusso della richiesta.
  • ms-azureml-bandwidth-response-delay-ms è il tempo di ritardo in millisecondi necessario per il trasferimento del flusso della risposta.

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, si potrebbe 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.

Si può usare Azure Functions, l'Azure Application Gateway, o un altro servizio come livello provvisorio per gestire le richieste preliminari CORS.

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. Le seguenti sezioni presentano i dettagli 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 le richieste REST usano gli endpoint online gestiti:

Codice di stato Motivo Descrizione
200 Va bene 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 calcolo del punteggio, oppure il token è scaduto. Per altre informazioni, vedere Eseguire l'autenticazione per endpoint online gestiti e Eseguire l'autenticazione di client per endpoint online.
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 sotto request_settings nella configurazione di 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 un errore 424 presenta problemi di probe di attività o idoneità, valutare la possibilità di modificare ProbeSettings per avere più tempo a disposizione 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. Per garantire un funzionamento senza problemi, Azure Machine Learning consente a un massimo di 2 * max_concurrent_requests_per_instance * instance_count requests di elaborare in parallelo in qualsiasi momento. Le richieste che superano questo valore massimo vengono rifiutate.

Si può rivedere la configurazione della distribuzione del modello nelle sezioni request_settings e scale_settings per verificare e modificare queste impostazioni. Accertarsi anche che la variabile di ambiente WORKER_COUNT venga passata correttamente, come descritto in RequestSettings.

Se si verifica questo errore quando si usa la scalabilità automatica significa che il modello sta ricevendo richieste più rapidamente rispetto alla velocità con cui il sistema è in grado di aumentare le prestazioni. 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. Combinare questi passaggi con l'impostazione della scalabilità automatica per aiutare a 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 Errore Descrizione
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 un’operazione di creazione o aggiornamento dell'endpoint online è in corso, l'attivazione di una nuova operazione di cancellazione genera un errore.
502 Eccezione o 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 metodo init(), vedere ERRORE: ResourceNotReady per eseguire il debug del file.
503 Numero elevato di picchi nelle richieste al secondo L'autoscalatore è progettato per gestire cambiamenti graduali nel carico. Se si riceve un numero elevato di picchi nelle richieste al secondo, i client potrebbero ricevere il codice di stato HTTP 503. Anche se la scalabilità automatica reagisce rapidamente, il servizio Azure Kubernetes richiede molto tempo per creare più contenitori. Vedere Come prevenire gli errori dei 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. Si può 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, il codice potrebbe trovarsi in uno stato non reattivo o in un ciclo infinito. Seguire ERRORE: ResourceNotReady per eseguire il debug del file di score.py.
500 Errore interno del server L'infrastruttura con provisioning di Azure Machine Learning ha esito negativo.

Come prevenire gli errori dei codici di stato 503

Le distribuzioni online di Kubernetes supportano il ridimensionamento automatico, che consente di aggiungere repliche per supportare un carico aggiuntivo. Per altre informazioni, vedere Router di inferenza di Azure Machine Learning. Le decisioni per aumentare o ridurre le prestazioni si basano sull'utilizzo delle repliche dei contenitori correnti.

Due azioni consentono di evitare errori del codice di stato 503: modifica del livello di utilizzo per la creazione di nuove repliche o modifica del numero minimo di repliche. Questi due approcci possono essere usati singolarmente o combinati.

  • Modificare la destinazione di utilizzo in corrispondenza della quale la scalabilità automatica crea nuove repliche impostando autoscale_target_utilization su un valore inferiore. Questa modifica non comporta la creazione più rapida delle repliche, ma una soglia di utilizzo inferiore. Ad esempio, 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%.

  • Modificare il numero minimo di repliche per fornire un pool di dimensioni maggiori in grado di gestire i picchi in ingresso.

Come calcolare il numero di istanze

Per aumentare il numero di istanze, si possono calcolare le repliche necessarie come indicato di seguito:

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 ricevi picchi di richieste superiori a quelle che possono essere gestite dalle nuove repliche minime, potresti ricevere nuovamente un 503. Ad esempio, mano a mano che il traffico verso l'endpoint aumenta, potrebbe essere necessario aumentare le repliche minime.

Se l'endpoint online Kubernetes sta già usando il numero massimo di repliche correnti e si ricevono ancora codici di stato 503, aumentare il valore autoscale_max_replicas per aumentare il numero massimo di repliche.

Problemi di isolamento della rete

Questa sezione fornisce informazioni sui problemi comuni di isolamento della rete.

La creazione dell'endpoint online ha esito negativo e viene visualizzato un messaggio sulla modalità legacy v1

Gli endpoint online gestiti sono una funzionalità della piattaforma API di Azure Machine Learning v2. Se l'area di lavoro di Azure Machine Learning è configurata per la modalità legacy v1, gli endpoint online gestiti non funzionano. In particolare, se l'impostazione dell'area v1_legacy_mode di lavoro è impostata su true, la modalità legacy v1 è attivata e non è disponibile alcun supporto per le API v2.

Per informazioni su come disattivare la modalità legacy v1, vedere Modifica dell'isolamento della rete con la nuova piattaforma API in Azure Resource Manager.

Importante

Contatta il team di sicurezza di rete prima di impostare v1_legacy_mode su false, perché la modalità legacy v1 potrebbe essere attivata per un motivo.

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 <key-vault-name> con il nome del Key Vault.

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

La risposta di questo comando è simile al codice JSON seguente:

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

Se il valore di bypass non è AzureServices, usare le indicazioni in Configurare le impostazioni di rete di Azure Key Vault 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 della rete legacy per gli endpoint online gestiti. In questo metodo Azure Machine Learning crea una rete virtuale gestita per ogni distribuzione in un endpoint.

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

  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'].{ID:id, status:privateLinkServiceConnectionState.status}"

    Nel codice di risposta verificare che il campo status sia impostato su Approved. Se il valore non è Approved, usa il comando seguente per approvare la connessione. Sostituire <private-endpoint-connection-ID> con l'ID restituito dal comando precedente.

    az network private-endpoint-connection approve --id <private-endpoint-connection-ID> --description "Approved"

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 sul nome host dell'endpoint per recuperare le informazioni sull'indirizzo IP:

    nslookup <endpoint-name>.<endpoint-region>.inference.ml.azure.com

    Ad esempio, il comando potrebbe essere simile al seguente:

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

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

    Nota

    • Per l'endpoint online Kubernetes, il nome host deve essere il CName (nome di dominio) specificato nel cluster Kubernetes.
    • Se l'endpoint usa HTTP, l'indirizzo IP è contenuto nell'URI dell'endpoint, che è possibile ottenere dall'interfaccia utente di Studio.
    • Per altri modi per ottenere l'indirizzo IP dell'endpoint, vedere Aggiornare il DNS con un nome di dominio completo.

  3. Se il nslookup comando non risolve il nome host, eseguire le azioni in una delle sezioni seguenti.

Endpoint online gestiti

  1. Usare il comando seguente per verificare se esiste un record A nella zona DNS (Domain Name System) privata per la rete virtuale.

    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 quindi ricrearlo. Per altre informazioni, vedere Come configurare un endpoint privato.

  3. Se l'area di lavoro con un endpoint privato usa un server DNS personalizzato, eseguire il comando seguente per verificare che la risoluzione del server DNS personalizzato funzioni correttamente:

    dig <endpoint-name>.<endpoint-region>.inference.ml.azure.com

Endpoint online Kubernetes

  1. Controllare la configurazione DNS nel cluster Kubernetes.

  2. Controllare se il router di inferenza di Azure Machine Learning, azureml-fe, funziona come previsto. Per eseguire questo controllo, seguire questa procedura:

    1. Eseguire il comando seguente nel azureml-fe pod:

      kubectl exec -it deploy/azureml-fe -- /bin/bash

    2. Eseguire uno dei comandi riportati di seguito:

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

      Per HTTP, usare il comando seguente:

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

  3. Se il comando CURL HTTPS ha esito negativo o si verifica il timeout, ma il comando HTTP funziona, verificare se il certificato è valido.

  4. Se il processo precedente non riesce a risolvere il record A, usare il comando seguente per verificare se la risoluzione funziona dall'indirizzo IP pubblico virtuale DNS di Azure, 168.63.129.16:

    dig @168.63.129.16 <endpoint-name>.<endpoint-region>.inference.ml.azure.com

  5. Se il comando precedente ha esito positivo, risolvere i problemi relativi al server d'inoltro condizionale per il collegamento privato di Azure in un DNS personalizzato.

Non è possibile assegnare punteggi alle distribuzioni online

  1. Eseguire il comando seguente per visualizzare lo stato di una distribuzione a cui non è possibile assegnare un punteggio:

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

    Un valore di Succeeded per il state campo indica una distribuzione riuscita.

  2. Per una distribuzione corretta, usare il comando seguente per verificare che il traffico sia assegnato alla distribuzione:

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

    La risposta di questo comando deve elencare la percentuale di traffico assegnato a ogni distribuzione.

    Suggerimento

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

  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:

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

  4. Esaminare i log per verificare se si è verificato un problema durante l'invio di una richiesta alla distribuzione.

Problemi del server di inferenza

Questa sezione fornisce suggerimenti di base per la risoluzione dei problemi del server HTTP di inferenza di Azure Machine Learning.

Controllare i pacchetti installati

Per risolvere i problemi relativi ai pacchetti installati, seguire questa procedura:

  1. Raccogliere informazioni su pacchetti e versioni installati per l'ambiente Python.

  2. Nel file di ambiente controllare la versione del azureml-inference-server-http pacchetto Python specificato. Nei log di avvio del server HTTP di inferenza di Azure Machine Learning controllare la versione del server di inferenza visualizzato. Verificare che le due versioni corrispondano.

    In alcuni casi, il sistema di risoluzione delle dipendenze pip installa versioni impreviste del pacchetto. Potrebbe essere necessario eseguire pip per correggere i pacchetti e le versioni installati.

  3. Se si specifica Flask o le relative dipendenze nell'ambiente, rimuovere tali elementi.

    • I pacchetti dipendenti includono flask, jinja2itsdangerous, werkzeug, markupsafe, e click.
    • Il flask pacchetto è elencato come dipendenza nel pacchetto del server di inferenza. L'approccio migliore consiste nel consentire al server di inferenza di installare il pacchetto flask.
    • Quando il server di inferenza è configurato per supportare le nuove versioni di Flask, il server di inferenza riceve automaticamente gli aggiornamenti del pacchetto non appena diventano disponibili.

Controllare la versione del server di inferenza

Il pacchetto server azureml-inference-server-http viene pubblicato in PyPI. La pagina PyPI elenca il log delle modifiche e tutte le versioni del pacchetto.

Se si usa una versione anticipata del pacchetto, aggiornare la configurazione alla versione più recente. La tabella seguente riepiloga le versioni stabili, i problemi comuni e le modifiche consigliate:

Versione pacchetto Descrizione Problema Risoluzione
0.4.x In bundle nelle immagini di training datate 20220601 o precedenti e versioni del pacchetto azureml-defaults da 0.1.34 a 1.43. La versione stabile più recente è 0.4.13. Per le versioni del server precedenti alla 0.4.11, è possibile che si verifichino problemi di dipendenza flask, ad esempio can't import name Markup from jinja2. Eseguire l'aggiornamento alla versione 0.4.13 o 1.4.x, se possibile.
0.6.x Preinstallato nelle immagini di inferenza datate 20220516 e precedenti. La versione stabile più recente è 0.6.1. N/D N/D
0.7.x Supporta il framework Flask 2. La versione stabile più recente è 0.7.7. N/D N/D
0.8.x Usa un formato di log aggiornato. Termina il supporto per Python 3.6. N/D N/D
1.0.x Termina il supporto per Python 3.7. N/D N/D
1.1.x Esegue la migrazione alla pydantic versione 2.0. N/D N/D
1.2.x Aggiunge il supporto per Python 3.11. Aggiornamenti gunicorn alla versione 22.0.0. Aggiornamenti werkzeug alla versione 3.0.3 e successive. N/D N/D
1.3.x Aggiunge il supporto per Python 3.12. certifi Aggiornamenti alla versione 2024.7.4. flask-cors Aggiornamenti alla versione 5.0.0. Aggiorna i pacchetti gunicorn e pydantic. N/D N/D
1.4.x waitress Aggiornamenti alla versione 3.0.1. Termina il supporto per Python 3.8. Rimuove il livello di compatibilità che impedisce all'aggiornamento di Flask 2.0 di interrompere il codice oggetto della richiesta. Se si dipende dal livello di compatibilità, il codice oggetto della richiesta potrebbe non funzionare. Migrare lo script di punteggio a Flask 2.

Verificare le dipendenze del pacchetto

I pacchetti dipendenti più rilevanti per il pacchetto server azureml-inference-server-http includono:

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

Se si specifica il pacchetto azureml-defaults nell'ambiente Python, azureml-inference-server-http è un pacchetto dipendente. La dipendenza viene installata automaticamente.

Suggerimento

Se si usa Azure Machine Learning SDK per Python v1 e non si specifica in modo esplicito il azureml-defaults pacchetto nell'ambiente Python, l'SDK potrebbe aggiungere automaticamente il pacchetto. Tuttavia, la versione del pacchetto è bloccata rispetto alla versione dell'SDK. Ad esempio, se la versione dell'SDK è 1.38.0, la azureml-defaults==1.38.0 voce viene aggiunta ai requisiti pip dell'ambiente.

TypeError durante l'avvio del server di inferenza

Durante l'avvio del server di inferenza potrebbe verificarsi quanto segue TypeError :

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

Questo errore si verifica quando Flask 2 è installato nell'ambiente Python, ma la versione del pacchetto azureml-inference-server-http non supporta Flask 2. Il supporto per Flask 2 è disponibile nel azureml-inference-server-http pacchetto 0.7.0 e versioni successive e nel azureml-defaults pacchetto 1.44 e versioni successive.

  • Se non si usa il pacchetto Flask 2 in un'immagine Docker di Azure Machine Learning, usare la versione più recente del pacchetto azureml-inference-server-http o azureml-defaults.

  • Se si usa il pacchetto Flask 2 in un'immagine Docker di Azure Machine Learning, verificare che la versione della build dell'immagine sia July 2022 o successiva.

    È possibile trovare la versione dell'immagine nei log del contenitore. Ad esempio, vedere le istruzioni di log seguenti:

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materialization Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    La data di compilazione dell'immagine viene visualizzata dopo la notazione Materialization Build. Nell'esempio precedente la versione dell'immagine è 20220708, o 8 luglio 2022. L'immagine in questo esempio è compatibile con Flask 2.

    Se nel log del contenitore non viene visualizzato un messaggio simile, l'immagine non è aggiornata e deve essere aggiornata. Se si usa un'immagine CUDA (Compute Unified Device Architecture) e non è possibile trovare un'immagine più recente, controllare il repository AzureML-Containers per verificare se l'immagine è deprecata. È possibile trovare sostituzioni designate per le immagini deprecate.

    Se si usa il server di inferenza con un endpoint online, è anche possibile trovare i log in Azure Machine Learning Studio. Nella pagina dell'endpoint selezionare la scheda Log .

Se si esegue la distribuzione con l'SDK v1 e non si specifica in modo esplicito un'immagine nella configurazione di distribuzione, il server di inferenza applica il openmpi4.1.0-ubuntu20.04 pacchetto con una versione corrispondente al set di strumenti DELL'SDK locale. Tuttavia, la versione installata potrebbe non essere la versione disponibile più recente dell'immagine.

Per SDK versione 1.43, il server di inferenza installa la versione del openmpi4.1.0-ubuntu20.04:20220616 pacchetto per impostazione predefinita, ma questa versione del pacchetto non è compatibile con SDK 1.43. Assicurarsi di usare l'SDK più recente per la distribuzione.

Se non è possibile aggiornare l'immagine, è possibile evitare temporaneamente il problema aggiungendo le voci azureml-defaults==1.43 o azureml-inference-server-http~=0.4.13 nel file di ambiente. Queste voci indirizzano il server di inferenza a installare la versione precedente con flask 1.0.x.

ImportError o ModuleNotFoundError durante l'avvio del server di inferenza

Durante l'avvio del server di inferenza, potresti incontrare un ImportError o ModuleNotFoundError in moduli specifici, come opencensus, jinja2, markupsafe o click. L'esempio seguente mostra il messaggio di errore:

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

Gli errori di importazione e di modulo si verificano quando si usa la versione 0.4.10 o versioni precedenti del server di inferenza che non fissano la dipendenza di Flask a una versione compatibile. Per evitare il problema, installare una versione successiva del server di inferenza.

Altri problemi comuni

Altri problemi comuni degli endpoint online sono correlati all'installazione e alla scalabilità automatica di Conda.

Problemi di installazione di Conda

I problemi relativi alla distribuzione di MLflow in genere derivano dai problemi di installazione dell'ambiente utente specificato nel file conda.yml.

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 è bloccato o ha impiegato troppo tempo ad avviarsi, probabilmente l'aggiornamento dell'ambiente conda non è 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 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.
    • L'installazione del pacchetto Conda viene eseguita in fase di runtime, quindi se le dimensioni dello SKU sono insufficienti per contenere tutti i pacchetti nel file di ambiente conda.yml, il contenitore potrebbe arrestarsi in modo anomalo.
    • Una macchina virtuale Standard_F4s_v2 fornisce una buona dimensione iniziale dello SKU, ma potrebbero essere necessarie macchine virtuali maggiori a seconda delle dipendenze specificate nel file Conda.
    • Per gli endpoint online Kubernetes, il cluster Kubernetes deve avere un minimo di 4 core di CPU virtuale e 8 GB di memoria.

Problemi di scalabilità automatica

Se hai problemi con la scalabilità automatica, consulta Risolvi i problemi di scalabilità automatica in Azure Monitor.

Per gli endpoint online Kubernetes il router di inferenza di Azure Machine Learning è un componente front-end che gestisce la scalabilità automatica per tutte le distribuzioni di modelli nel cluster Kubernetes. Per altre informazioni, vedere Routing di inferenza di scalabilità automatica di Kubernetes.

Contenuto correlato