Condividi tramite

Risolvere i problemi di distribuzione e assegnazione del punteggio 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)

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

Traccia 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 usa un'immagine esistente se una corrisponde all'ambiente 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 casuale a una macchina virtuale (VM) in cui viene distribuito un modello, ma si possono ottenere i log da alcuni dei contenitori in esecuzione nella 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

O

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.

ERROR: 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. Controllare 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 compilazione 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. L'aggiunta delle dipendenze della 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.

ERROR: 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 quante memorie centrali virtuali sono disponibili 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.

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

Provare a 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

ERROR: BadArgument

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

Si potrebbe ricevere questo errore anche per i motivi seguenti quando si usano solo endpoint online Kubernetes:

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.

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 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 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. Accertarsi di aver registrato il modello nella stessa area di lavoro della 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 integra 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.

ERROR: 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.

  • 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, scegliere uno SKU di macchine virtuali supportato che acceleri 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: ResourceNotFound

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 contenitori

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 contenitori 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 specificare l'indirizzo dell'immagine privata e dare l'istruzione per non modificare (o compilare) l'immagine.

Se questa mitigazione 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.

ERROR: WorkspaceManagedNetworkNotReady

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.

ERROR: OperationCanceled

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 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 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 Controllo degli accessi in base al ruolo di Azure per leggere i segreti dalle connessioni all'area di lavoro o dagli insiemi di credenziali delle chiavi, anche se la definizione di distribuzione è specificata nei segreti come riferimenti mappati alle variabili dell’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: InternalServerError

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:

ERROR: 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 Azure Arc-enabled di Kubernetes o di Azure Machine Learning per il servizio Azure Kubernetes 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 Azure Container, l'account di archiviazione e l'area di lavoro nella rete virtuale del servizio Azure Kubernetes.

  • 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.

ERROR: TokenRefreshFailed

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.

ERROR: 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 altre informazioni, vedere Che cos'è un ambiente di inferenza sicuro 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 un test 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 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.

ERROR: KubernetesUnaccessible

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).

ERROR: 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.

ERROR: 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.

ERROR: 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.

ERROR: 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. 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, rimuovere l'ambiente di calcolo legacy e ricollegarlo per crearne uno nuovo, specificando uno spazio dei nomi già esistente nel cluster.

ERROR: 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.

ERROR: UserScriptImportError

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 importa pacchetti non disponibili. Controllare i log di distribuzione per visualizzare il messaggio di eccezione in dettaglio e correggere l'eccezione.

ERROR: 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.

ERROR: EndpointNotFound

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.

ERROR: EndpointAlreadyExists

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.

ERROR: 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.

ERROR: 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.

ERROR: 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.

ERROR: 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.

ERROR: 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.

ERROR: 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, si può rimuovere e quindi ricollegare l'ambiente di calcolo.

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 Funzioni di Azure, il gateway applicazione di Azure 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 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 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 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 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 Il ridimensionamento automatico è progettato per gestire modifiche 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 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.

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 con un messaggio V1LegacyMode == true

Si può configurare l'area di lavoro di Azure Machine Learning per v1_legacy_mode, che 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.

Per disabilitare v1_legacy_mode, vedere Isolamento rete con v2.

Importante

Rivolgersi al team di sicurezza di rete prima di disabilitare v1_legacy_mode, perché è possibile che sia stata abilitata per un motivo specifico.

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 codice 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 è 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'].{Name:name, status:privateLinkServiceConnectionState.status}"

    Nel codice di risposta verificare che il campo status sia impostato su Approved. In caso contrario, 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, ad esempio:

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

    La risposta contiene un indirizzo che deve trovarsi nell'intervallo fornito 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 l'endpoint è HTTP, l'indirizzo IP è contenuto nell'URI dell'endpoint, che è possibile ottenere dall'interfaccia utente di Studio.
    • Per informazioni su altri modi per ottenere l'indirizzo IP dell'endpoint, vedere Endpoint online Kubernetes sicuro.

  3. Se il comando nslookup non risolve il nome host, eseguire le azioni seguenti:

Endpoint online gestiti

  1. Usare il comando seguente per verificare se esiste un record A nella zona DNS (Domain Name Server) 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, 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 dal DNS personalizzato funzioni correttamente.

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

Endpoint online Kubernetes

  1. Controllare la configurazione DNS nel cluster Kubernetes.

  2. Controllare anche se azureml-fe funziona come previsto usando 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 il comando seguente:

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

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

  4. Se il processo precedente non viene risolto nel record A, verificare se la risoluzione funziona da DNS di Azure (168.63.129.16).

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

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

Non è possibile assegnare punteggi alle distribuzioni online

  1. Eseguire il comando seguente per verificare se la distribuzione ha avuto esito positivo:

    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 è 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

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

    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 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>

  4. Quando si invia una richiesta alla distribuzione, esaminare i log per controllare se si è verificato un problema durante l'esecuzione del codice di assegnazione dei punteggi.

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

Eseguire i seguenti passaggi per risolvere i problemi relativi ai pacchetti installati.

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

  2. Accertarsi che la versione del pacchetto Python azureml-inference-server-http specificata nel file di ambiente corrisponda alla versione del server HTTP di inferenza di Azure Machine Learning visualizzata nel log di avvio.

    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 questi elementi.

    • I pacchetti dipendenti includono flask, jinja2 itsdangerous, werkzeug, markupsafe, e click.
    • flask è elencato come dipendenza nel pacchetto del server. 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 riceve automaticamente gli aggiornamenti del pacchetto non appena diventano disponibili.

Controllare la versione del server

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

Se si usa una versione precedente 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 .1.34 a 1.43. La versione stabile più recente è 0.4.13. Per le versioni del server precedenti a 0.4.11, è possibile che si verifichino problemi di dipendenza Flask, ad esempio "can't import name Markup from jinja2". Se possibile, eseguire l'aggiornamento alla versione 0.4.13 o 0.8.x, ovvero la versione più recente.
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 Flask 2. La versione stabile più recente è 0.7.7. N/D N/D
0.8.x Formato del log modificato. Il supporto di Python 3.6 è terminato. N/D N/D

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 è stato specificato il pacchetto azureml-defaults nell'ambiente Python, il pacchetto azureml-inference-server-http è un pacchetto dipendente. La dipendenza viene installata automaticamente.

Suggerimento

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

TypeError durante l'avvio del server

Durante l'avvio del server potrebbe verificarsi l'errore TypeError seguente:

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 pacchetto azureml-inference-server-http versione 0.7.0 e successive e nel pacchetto azureml-defaults versione 1.44 e 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, accertarsi che la versione della build dell'immagine sia luglio 2022 o successiva.

    È possibile trovare la versione dell'immagine nei log del contenitore. Ad esempio:

    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 Compute Unified Device Architecture (CUDA) e non è possibile trovare un'immagine più recente, verificare se l'immagine è deprecata in AzureML-Containers. È possibile trovare sostituzioni designate per le immagini deprecate.

    Se si usa il server con un endpoint online, è anche possibile trovare i log in Log nella pagina Endpoint 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 della distribuzione, il server applica il pacchetto openmpi4.1.0-ubuntu20.04 con una versione corrispondente al set di strumenti dell'SDK locale. Tuttavia, la versione installata potrebbe non essere la versione più recente disponibile dell'immagine.

Per SDK versione 1.43, il server installa la versione del pacchetto openmpi4.1.0-ubuntu20.04:20220616 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 a installare la versione precedente con flask 1.0.x.

ImportError o ModuleNotFoundError durante l'avvio del server

È possibile che si verifichi un errore ImportError o ModuleNotFoundError in moduli specifici, tra cui opencensus, jinja2, markupsafe o click, durante l'avvio del server. L'esempio seguente mostra il messaggio di errore:

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

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

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 arresta in modo anomalo o impiega troppo tempo ad avviarsi, probabilmente l'aggiornamento dell'ambiente Conda non ha 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.
    • 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 si verificano problemi con la scalabilità automatica, vedere Risoluzione dei problemi di scalabilità automatica di Monitoraggio di Azure.

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