Risolvere i problemi di distribuzione e assegnazione dei punteggi 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)
Informazioni su come risolvere i problemi comuni nella distribuzione e nell'assegnazione dei punteggi degli endpoint online di Azure Machine Learning.
Questo documento è descritta la struttura in base alla quale è consigliabile gestire la risoluzione dei problemi:
- Usare la distribuzione locale per testare ed eseguire il debug dei modelli in locale prima della distribuzione nel cloud.
- Usare i log dei contenitori per facilitare il debug dei problemi.
- Comprendere gli errori di distribuzione comuni che potrebbero verificarsi e come risolverli.
Nella sezione relativa ai codici di stato HTTP viene illustrato il mapping tra gli errori di chiamata e previsione e i codici di stato HTTP durante l'assegnazione dei punteggi agli endpoint con richieste REST.
Prerequisiti
- Una sottoscrizione di Azure. Provare la versione gratuita o a pagamento di Azure Machine Learning.
- Interfaccia della riga di comando di Azure.
- Per l'interfaccia della riga di comando di Azure Machine Learning v2, vedere Installare, configurare e usare l'interfaccia della riga di comando (v2).
- Per l'SDK di Azure Machine Learning per Python v2, vedere Installare Azure Machine Learning SDK v2 per Python.
Distribuire in locale
La distribuzione locale consiste nel distribuire un modello in un ambiente Docker locale. La distribuzione locale è utile per il test e il debug prima della distribuzione nel cloud.
Suggerimento
È possibile usare il pacchetto Python del server HTTP di inferenza di Azure Machine Learning per eseguire il debug dello script di assegnazione dei punteggi in locale. Il debug con il server di inferenza consente di eseguire il debug dello script di assegnazione dei punteggi prima della distribuzione negli endpoint locali in modo che sia possibile eseguire il debug senza alcun impatto sulle configurazioni del contenitore di distribuzione.
La distribuzione locale supporta la creazione, l'aggiornamento e l'eliminazione di endpoint locali e consente di richiamare e ottenere log dagli endpoint.
Per usare la distribuzione locale, aggiungere --local
al comando dell'interfaccia della riga di comando appropriato:
az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local
Nell'ambito della distribuzione locale, vengono eseguiti i passaggi seguenti:
- Docker compila una nuova immagine del contenitore o esegue il pull di un'immagine esistente dalla cache Docker locale. Viene usata un'immagine esistente se ne è presente una che corrisponde all'ambiente del file delle specifiche.
- Docker avvia un nuovo contenitore con gli artefatti locali montati, ad esempio file di modello e codice.
Per altre informazioni, vedere l'argomento relativo alla distribuzione locale in Distribuire e assegnare un punteggio a un modello di Machine Learning.
Suggerimento
Usare Visual Studio Code per testare ed eseguire il debug degli endpoint in locale. Per altre informazioni, vedere Eseguire il debug degli endpoint online in locale in Visual Studio Code.
Installazione di Conda
In genere, i problemi relativi alla distribuzione di MLflow derivano dai problemi di installazione dell'ambiente utente specificato nel file conda.yaml
.
Per eseguire il debug dei problemi di installazione di Conda, seguire questa procedura:
Controllare i log dell'installazione di conda. Se il contenitore si arresta in modo anomalo o richiede troppo tempo per l'avvio, è probabile che l'aggiornamento dell'ambiente conda non abbia risolto il problema.
Installare il file conda mlflow in locale con il comando
conda env create -n userenv -f <CONDA_ENV_FILENAME>
.Se si verificano errori in locale, provare a risolvere l'ambiente conda e a crearne uno funzionante prima della ridistribuzione.
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 descritti in dettaglio nel file di ambiente
conda.yaml
, il contenitore potrebbe arrestarsi in modo anomalo. - Una macchina virtuale Standard_F4s_v2 fornisce una buona dimensione iniziale dello SKU, ma potrebbero essere necessarie dimensioni maggiori a seconda delle dipendenze specificate nel file conda.
- Per l'endpoint online Kubernetes, il cluster Kubernetes deve avere almeno 4 core vCPU e 8 GB di memoria.
- L'installazione del pacchetto Conda viene eseguita in fase di runtime, quindi se le dimensioni dello SKU sono insufficienti per contenere tutti i pacchetti descritti in dettaglio nel file di ambiente
Ottenere i log dei contenitori
Non è possibile ottenere l'accesso diretto alla macchina virtuale in cui viene distribuito il modello. Tuttavia, è possibile ottenere i log da alcuni dei contenitori in esecuzione nella macchina virtuale. La quantità di informazioni ottenute dipende dallo stato di provisioning della distribuzione. Se il contenitore specificato è in esecuzione, verrà visualizzato l'output della console, in caso contrario verrà visualizzato un messaggio che indica di riprovare in un secondo momento.
Esistono due tipi di contenitori da cui è possibile ottenere i log:
- Server di inferenza: i log includono il log della console (dal server di inferenza) che contiene l'output delle funzioni di stampa/registrazione dallo script di assegnazione dei punteggi (codice
score.py
). - Inizializzatore di archiviazione: i log contengono informazioni che specificano se il codice e i dati del modello sono stati scaricati correttamente nel contenitore. Il contenitore viene eseguito prima dell'avvio dell'esecuzione del contenitore del server di inferenza.
Per visualizzare l'output del log da un contenitore, usare il seguente comando dell'interfaccia della riga di comando:
az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100
or
az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100
Aggiungere --resource-group
e --workspace-name
a questi comandi se questi parametri non sono già stati impostati tramite az configure
.
Per visualizzare informazioni su come impostare questi parametri e se sono stati impostati valori, eseguire:
az ml online-deployment get-logs -h
I log vengono estratti dal server di inferenza.
Nota
Se si usa la registrazione Python, assicurarsi di usare l'ordine del livello di registrazione corretto per la pubblicazione dei messaggi nei log. Ad esempio, INFO.
È anche possibile recuperare i log dal contenitore dell'inizializzatore di archiviazione passando –-container storage-initializer
.
Aggiungere --help
e/o --debug
ai comandi per visualizzare altre informazioni.
Per l'endpoint online Kubernetes, gli amministratori sono in grado di accedere direttamente al cluster in cui si distribuisce il modello e ciò costituisce il modo più flessibile per controllare il log in Kubernetes. Ad esempio:
kubectl -n <compute-namespace> logs <container-name>
Traccia delle richieste
Sono supportate due intestazioni di traccia:
x-request-id
è riservato per la traccia del server. Si esegue l'override di questa intestazione per assicurarsi che si tratti di un GUID valido.Nota
Quando si crea un ticket di supporto per una richiesta non riuscita, allegare l'ID della richiesta non riuscita per accelerare l'indagine. In alternativa, specificare il nome dell'area e il nome dell'endpoint.
x-ms-client-request-id
è disponibile per gli scenari di traccia client. Questa intestazione viene purificata in modo che vengano accettati solo caratteri alfanumerici, trattini e caratteri di sottolineatura e viene troncata a un massimo di 40 caratteri.
Errori di distribuzione comuni
L'elenco seguente riporta gli errori di distribuzione comuni segnalati a livello di stato dell'operazione di distribuzione:
- ImageBuildFailure
- OutOfQuota
- BadArgument
- Condiviso sia dall'endpoint online gestito che dall'endpoint online Kubernetes
- La sottoscrizione non esiste
- Attività di avvio non riuscita a causa di un errore di autorizzazione
- Attività di avvio non riuscita a causa di assegnazioni di ruolo non corrette nella risorsa
- Specifica della funzione modello non valida
- Non è possibile scaricare l'immagine del contenitore utente
- Non è possibile scaricare il modello dell'utente
- Errori limitati all'endpoint online Kubernetes
- Condiviso sia dall'endpoint online gestito che dall'endpoint online Kubernetes
- ResourceNotReady
- ResourceNotFound
- WorkspaceManagedNetworkNotReady
- OperationCanceled
- SecretsInjectionError
- InternalServerError
Se si sta creando o aggiornando una distribuzione online Kubernetes, è possibile visualizzare gli errori comuni specifici per le distribuzioni Kubernetes.
ERROR: ImageBuildFailure
Questo errore viene restituito quando viene compilato l'ambiente (immagine Docker). È possibile controllare il log di compilazione per altre informazioni sugli errori. Il log di compilazione si trova nella risorsa di archiviazione predefinita dell'area di lavoro di Azure Machine Learning. È possibile che la posizione esatta venga restituita come parte dell'errore. Ad esempio, "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'"
.
L'elenco seguente contiene scenari comuni di errore di compilazione delle immagini:
- Errore di autorizzazione di Registro Azure Container
- Ambiente di calcolo di compilazione immagine non impostato in un'area di lavoro privata con rete virtuale
- Errore generico o sconosciuto
È anche consigliabile esaminare le impostazioni predefinite del probe se sono presenti timeout di ImageBuild.
Errore di autorizzazione del registro contenitori
Se il messaggio di errore riporta "container registry authorization failure"
, significa che non è possibile accedere al registro contenitori con le credenziali correnti.
La desincronizzazione delle chiavi di una risorsa dell'area di lavoro può causare questo errore; la sincronizzazione automatica richiede tempo.
Tuttavia, è possibile richiedere manualmente una sincronizzazione delle chiavi; ciò potrebbe risolvere l'errore di autorizzazione.
Anche i registri contenitori che si trovano dietro una rete virtuale possono rilevare questo errore se la configurazione non è corretta. È necessario verificare che la rete virtuale sia configurata correttamente.
Ambiente di calcolo di compilazione immagine non impostato in un'area di lavoro privata con rete virtuale
Se il messaggio di errore indica "failed to communicate with the workspace's container registry"
, si usano reti virtuali e Registro Azure Container dell'area di lavoro è privato e configurato con un endpoint privato, è necessario abilitare Registro Azure Container per consentire la compilazione di immagini nella rete virtuale.
Timeout di compilazione delle immagini
I timeout di compilazione delle immagini si verificano spesso perché un’immagine è troppo grande perché la compilazione possa essere completata entro l'intervallo di tempo di creazione della distribuzione. Per verificare se si tratta di questo problema, controllare i log di compilazione delle immagini nel percorso indicato 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 l'immagine debba essere estratta solo durante la creazione della distribuzione.
Errore di compilazione dell'immagine generica
Come indicato in precedenza, è possibile controllare il log di compilazione per altre informazioni sugli errori.
Se non viene rilevato alcun errore esplicito nel log di compilazione e l'ultima riga è Installing pip dependencies: ...working...
, è possibile che la causa dell'errore sia una dipendenza. L'aggiunta delle dipendenze della versione nel file conda può risolvere questo problema.
È anche consigliato eseguire una distribuzione locale per testare ed eseguire il debug dei modelli in locale prima della distribuzione nel cloud.
ERROR: OutOfQuota
L'elenco seguente contiene le risorse comuni che potrebbero esaurire la quota quando si usano i servizi di Azure:
- CPU
- Cluster
- Disco
- Memory
- Assegnazioni di ruoli
- Endpoint
- Capacità di macchine virtuali a livello di regione
- Altro
L'elenco seguente contiene anche le risorse comuni che potrebbero esaurire la quota solo per l'endpoint online Kubernetes:
Quote della CPU
Prima di distribuire un modello, è necessario disporre di una quota di calcolo sufficiente. Questa quota definisce la quantità di memoria centrale virtuale disponibile per sottoscrizione, per area di lavoro, per SKU e per area. Ogni distribuzione sottrae un valore dalla quota disponibile e lo aggiunge nuovamente dopo l'eliminazione, in base al tipo di SKU.
Una possibile mitigazione consiste nel verificare se sono presenti distribuzioni inutilizzate eliminabili. In alternativa, è possibile inviare una richiesta di aumento della quota.
Quota del cluster
Questo problema si verifica quando la quota di cluster dell'ambiente di calcolo di Azure Machine Learning non è sufficiente. Questa quota definisce il numero totale di cluster che potrebbero essere in uso contemporaneamente per sottoscrizione per distribuire nodi CPU o GPU nel cloud di Azure.
Una possibile mitigazione consiste nel verificare se sono presenti distribuzioni inutilizzate eliminabili. In alternativa, è possibile inviare una richiesta di aumento della quota. Assicurarsi di selezionare Machine Learning Service: Cluster Quota
come tipo di quota per questa richiesta di aumento della quota.
Quota del disco
Questo problema si verifica quando le dimensioni del modello sono maggiori dello spazio disponibile su disco e il modello non può essere scaricato. Provare a usare uno SKU con più spazio su disco o ridurre le dimensioni dell'immagine e del modello.
Quota di memoria
Questo problema si verifica quando il footprint della memoria del modello è maggiore della memoria disponibile. Provare a usare uno SKU con più memoria.
Quota dell'assegnazione di ruolo
Quando si crea un endpoint online gestito, l'assegnazione di ruolo è necessaria per l'identità gestita per accedere alle risorse dell'area di lavoro. Se viene raggiunto il limite dell'assegnazione di ruolo, provare a eliminare alcune assegnazioni di ruolo inutilizzate in questa sottoscrizione. È possibile controllare tutte le assegnazioni di ruolo nel portale di Azure passando al menu Controllo di accesso.
Quota degli endpoint
Provare a eliminare alcuni endpoint inutilizzati in questa sottoscrizione. Se tutti gli endpoint sono attivamente in uso, è possibile provare a richiedere un aumento del limite di endpoint. Per altre informazioni sul limite degli endpoint, vedere Quota degli endpoint con endpoint online ed endpoint batch di Azure Machine Learning.
Quota di Kubernetes
Questo problema si verifica quando la CPU o la memoria richiesta non può essere resa disponibile a causa di nodi non pianificabili per questa distribuzione. Ad esempio, i nodi possono essere bloccati o non disponibili.
Il messaggio di errore indica in genere la risorsa insufficiente nel cluster, ad esempio OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods...
, il che significa che nel cluster è presente un numero eccessivo di pod e una quantità insufficiente di risorse per distribuire il nuovo modello in base alla richiesta.
Per risolvere questo problema, è possibile provare la mitigazione seguente:
- Per le operazioni IT che gestiscono il cluster Kubernetes, è possibile provare ad aggiungere altri nodi o cancellare alcuni pod inutilizzati nel cluster per rilasciare alcune risorse.
- Per i tecnici addetti all'apprendimento automatico che distribuiscono i modelli, è possibile provare a ridurre la richiesta di risorse della distribuzione:
- Se si definisce direttamente la richiesta di risorse nella configurazione della distribuzione tramite la sezione delle risorse, è possibile provare a ridurre la richiesta di risorse.
- Se si usa
instance type
per definire la risorsa per la distribuzione del modello, è possibile contattare le operazioni IT per modificare la configurazione della risorsa di tipo istanza. Per altri dettagli, vedere Come gestire il tipo di istanza Kubernetes.
Capacità delle macchine virtuali a livello di area
A causa della mancanza di capacità di Azure Machine Learning nell'area, il servizio non è riuscito a effettuare il provisioning delle dimensioni della macchina virtuale specificate. Riprovare più tardi o provare a eseguire la distribuzione in un'area diversa.
Altre quote
Per eseguire il file score.py
fornito come parte della distribuzione, Azure crea un contenitore che include tutte le risorse necessarie a score.py
ed esegue lo script di assegnazione punteggio in tale contenitore.
Se non è stato possibile avviare il contenitore, significa che non è stato possibile assegnare il punteggio. È possibile che il contenitore richieda più risorse di quelle supportate da instance_type
. In tal caso, prendere in considerazione l'aggiornamento di instance_type
della distribuzione online.
Per recuperare il motivo esatto di un errore, eseguire:
az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100
ERROR: BadArgument
L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore quando si usa l'endpoint online gestito o l'endpoint online Kubernetes:
- La sottoscrizione non esiste
- Attività di avvio non riuscita a causa di un errore di autorizzazione
- Attività di avvio non riuscita a causa di assegnazioni di ruolo non corrette nella risorsa
- Specifica della funzione modello non valida
- Non è possibile scaricare l'immagine del contenitore utente
- Non è possibile scaricare il modello dell'utente
- Il formato del modello MLFlow con rete privata non è supportato
L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore solo quando si usa l'endpoint online Kubernetes:
- La richiesta di risorse è maggiore dei limiti
- azureml-fe per l'endpoint online Kubernetes non è pronto
La sottoscrizione non esiste
La sottoscrizione di Azure immessa deve esistere. Questo errore si verifica quando non è possibile trovare la sottoscrizione di Azure a cui si fa riferimento. È possibile che questo errore sia dovuto a un refuso nell'ID sottoscrizione. Verificare che l'ID sottoscrizione sia stato digitato correttamente e che sia attualmente attivo.
Per altre informazioni sulle sottoscrizioni di Azure, vedere la sezione relativa ai prerequisiti.
Errore di autorizzazione
Dopo aver effettuato il provisioning della risorsa di calcolo (durante la creazione di una distribuzione), Azure tenta di eseguire il pull dell'immagine del contenitore utente dall'area di lavoro Registro Azure Container. Tenta quindi di montare il modello utente e gli artefatti di codice nel contenitore utente dall'account di archiviazione dell'area di lavoro.
Per eseguire queste azioni, Azure usa le identità gestite per accedere all'account di archiviazione e al registro contenitori.
Se l'endpoint associato è stato creato con un'identità assegnata dal sistema, l'autorizzazione per il controllo degli accessi in base al ruolo di Azure viene concessa automaticamente e pertanto non sono necessarie ulteriori autorizzazioni.
Se l'endpoint associato è stato creato con l'identità assegnata dall'utente, l'identità gestita dell'utente deve disporre dell'autorizzazione di lettura dati del BLOB di archiviazione per l'account di archiviazione per l'area di lavoro e l'autorizzazione AcrPull per Registro Azure Container per l'area di lavoro. Assicurarsi che l'identità assegnata dall'utente disponga dell'autorizzazione corretta.
Per altre informazioni, vedere Errore di autorizzazione del registro contenitori.
Specifica della funzione modello non valida
Questo errore si verifica quando una funzione modello è stata specificata in modo non corretto. Correggere il criterio o rimuovere l'assegnazione dei criteri per sbloccare. Il messaggio di errore può includere il nome dell'assegnazione dei criteri e la definizione dei criteri per facilitare il debug di questo errore e l'articolo sulla struttura della definizione dei criteri di Azure, che illustra i suggerimenti per evitare errori del modello.
Non è possibile scaricare l'immagine del contenitore utente
È possibile che il contenitore utente non sia stato trovato. Controllare i log dei contenitori per recuperare altri dettagli.
Assicurarsi che l'immagine del contenitore sia disponibile nell'area di lavoro di Registro Azure Container.
Ad esempio, se l'immagine è testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest
, controllare il repository con az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table
.
Non è possibile scaricare il modello dell'utente
È possibile che il modello utente non sia stato trovato. Controllare i log dei contenitori per recuperare altri dettagli.
Assicurarsi di aver registrato il modello nella stessa area di lavoro della distribuzione. Per visualizzare i dettagli di un modello in un'area di lavoro:
az ml model show --name <model-name> --version <version>
Avviso
È necessario specificare la versione o l'etichetta per visualizzare le informazioni del modello.
È anche possibile verificare se i BLOB sono presenti nell'account di archiviazione dell'area di lavoro.
Ad esempio, se il BLOB è
https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl
, è possibile usare questo comando per verificarne l'esistenza:az storage blob exists --account-name foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`
Se il BLOB esiste, è possibile usare questo comando per ottenere i log dall'inizializzatore di archiviazione:
az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`
Il formato del modello MLFlow con rete privata non è supportato
Questo errore si verifica quando si tenta di distribuire un modello MLflow con un approccio di distribuzione senza codice insieme al metodo di isolamento della rete legacy per gli endpoint online gestiti. Questa funzionalità di rete privata non può essere usata insieme a un formato di modello MLFlow se si usa il metodo di isolamento della rete legacy. Se è necessario distribuire un modello MLflow con l'approccio di distribuzione senza codice, provare a usare la rete virtuale gestita dall'area di lavoro.
Le richieste di risorse superano i limiti
Le richieste di risorse devono essere minori o uguali ai limiti. Se non si impostano limiti, vengono impostati i valori predefiniti quando si collega un'operazione di calcolo a un'area di lavoro di Azure Machine Learning. È possibile controllare i limiti nel portale di Azure o usando il comando az ml compute show
.
azureml-fe non pronto
Il componente front-end (azureml-fe) che indirizza le richieste di inferenza in ingresso ai servizi distribuiti viene ridimensionato automaticamente in base alle esigenze. Viene installato durante l'installazione di k8s-extension.
Questo componente o almeno una sua replica deve essere integro nel cluster. Questo messaggio di errore viene visualizzato se non risulta disponibile quando si attiva l'endpoint online Kubernetes e la richiesta di creazione/aggiornamento della distribuzione.
Controllare lo stato e i log del pod per risolvere questo problema; è anche possibile provare ad aggiornare il componente k8s-extension installato nel cluster.
ERROR: ResourceNotReady
Per eseguire il file score.py
fornito come parte della distribuzione, Azure crea un contenitore che include tutte le risorse necessarie a score.py
ed esegue lo script di assegnazione punteggio in tale contenitore. L'errore in questo scenario fa riferimento al fatto che questo contenitore si arresta in modo anomalo durante l'esecuzione, il che significa che risulta impossibile eseguire l'assegnazione del punteggio. Questo errore si verifica quando:
- Si verifica un errore in
score.py
. Usareget-logs
per eseguire la diagnostica dei problemi comuni:- Un pacchetto che
score.py
tenta di importare non è incluso nell'ambiente conda. - Errore di sintassi.
- Errore nel metodo
init()
.
- Un pacchetto che
- Se
get-logs
non restituisce alcun log, in genere significa che l'avvio del contenitore non è riuscito. Per eseguire il debug di questo problema, provare invece a eseguire la distribuzione localmente. - I probe di idoneità o attività non sono configurati correttamente.
- L'inizializzazione del contenitore richiede troppo tempo e pertanto il probe di idoneità o attività ha esito negativo quando supera la soglia di errore. In questo caso, modificare le impostazioni del probe per concedere più tempo all'inizializzazione del contenitore. In alternativa, tra gli SKU di macchine virtuali supportati scegliere uno SKU della macchina virtuale di dimensioni maggiori, in grado di accelerare l'inizializzazione.
- Si è verificato un errore nella configurazione dell'ambiente del contenitore, ad esempio una dipendenza mancante.
- Quando viene visualizzato l'errore
TypeError: register() takes 3 positional arguments but 4 were given
, controllare la dipendenza tra Flask v2 eazureml-inference-server-http
. Per altre informazioni, vedere Domande frequenti per il server HTTP di inferenza.
ERROR: ResourceNotFound
L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore solo quando si usa l'endpoint online gestito o l'endpoint online Kubernetes:
- Azure Resource Manager non è in grado di trovare una risorsa richiesta
- Registro Azure Container è privato o altrimenti inaccessibile
Resource Manager non riesce a trovare una risorsa
Questo errore si verifica quando Azure Resource Manager non riesce a trovare una risorsa necessaria. Ad esempio, è possibile ricevere questo errore se è stato fatto riferimento a un account di archiviazione, ma non è possibile trovarlo nel percorso in cui è stato specificato. Assicurarsi di controllare con estrema attenzione le risorse che potrebbero essere state specificate mediante un percorso esatto o l'ortografia dei relativi nomi.
Per altre informazioni, vedere Risolvere gli errori di risorsa non trovata.
Errore di autorizzazione del registro contenitori
Questo errore si verifica quando per la distribuzione è stata specificata un'immagine appartenente a un registro contenitori privato o inaccessibile. Al momento, le API non possono accettare credenziali di un registro contenitori privato.
Per ridurre l'impatto di questo errore, assicurarsi che il registro contenitori non sia privato o attenersi alla procedura seguente:
- Concedere il ruolo
acrPull
del registro privato all'identità di sistema dell'endpoint online. - Nella definizione dell'ambiente specificare l'indirizzo dell'immagine privata e l'istruzione per non modificare (compilare) l'immagine.
Se la mitigazione dell'errore ha esito positivo, l'immagine non richiede la compilazione e l'indirizzo dell'immagine finale sarà l'indirizzo dell'immagine specificato. In fase di distribuzione, l'identità di sistema dell'endpoint online esegue il pull dell'immagine dal registro privato.
Per altre informazioni di diagnostica, vedere Come usare l'API di diagnostica dell'area di lavoro.
ERROR: WorkspaceManagedNetworkNotReady
Questo errore si verifica quando si tenta di creare una distribuzione online nell'area di lavoro in cui è stata abilitata la rete virtuale gestita dell'area di lavoro senza che sia stato ancora effettuato il provisioning della rete virtuale gestita. Prima di creare una distribuzione online, è necessario effettuare il provisioning della rete virtuale gestita dell'area di lavoro. Seguire le istruzioni riportate in Effettuare manualmente il provisioning della rete virtuale gestita dell'area di lavoro per effettuare manualmente il provisioning della rete virtuale gestita dell'area di lavoro. Al termine, è possibile iniziare a creare distribuzioni online. Per altre informazioni, vedere Isolamento della rete con un endpoint online gestito e Proteggere gli endpoint online gestiti con l’isolamento della rete.
ERROR: OperationCanceled
L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore quando si usa l'endpoint online gestito o l'endpoint online Kubernetes:
- Operazione annullata da un'altra operazione con priorità più alta
- Operazione annullata a causa di un'operazione precedente in attesa della conferma del blocco
Operazione annullata da un'altra operazione con priorità più alta
Le operazioni di Azure hanno un determinato livello di priorità e vengono eseguite dalla priorità più alta a quella più bassa. Questo errore si verifica quando l'operazione è stata sostituita da un'altra operazione con priorità più alta.
Il nuovo tentativo di esecuzione dell'operazione potrebbe comportare la sua esecuzione senza annullamento.
Operazione annullata in attesa di conferma del blocco
Le operazioni di Azure hanno un breve periodo di attesa dopo l'invio durante il quale acquisiscono un blocco per evitare condizioni di race condition. Questo errore si verifica quando l'operazione inviata è uguale a un'altra operazione. L'altra operazione è attualmente in attesa di conferma della ricezione del blocco. L'errore potrebbe indicare che è stata inviata una richiesta simile troppo presto dopo la richiesta iniziale.
La ripetizione dell'operazione dopo l'attesa di alcuni secondi (fino a un minuto) potrebbe consentire l'esecuzione senza annullamento.
ERROR: SecretsInjectionError
Il recupero e l'inserimento di segreti durante la creazione della distribuzione online usano l'identità associata all'endpoint online per recuperare i segreti dalle connessioni all'area di lavoro e/o dagli insiemi di credenziali delle chiavi. Questo errore si verifica quando:
- L'identità dell'endpoint non dispone dell'autorizzazione Controllo degli accessi in base al ruolo di Azure per leggere i segreti dalle connessioni all'area di lavoro e/o dagli insiemi di credenziali delle chiavi, anche se i segreti sono stati specificati nella definizione di distribuzione come riferimenti (mappati alle variabili di ambiente). Tenere presente che l'assegnazione di ruolo può richiedere tempo per rendere effettive le modifiche.
- Il formato dei riferimenti al segreto non è valido oppure i segreti specificati non esistono nelle connessioni all'area di lavoro e/o negli insiemi di credenziali delle chiavi.
Per altre informazioni, vedere Inserimento di segreti negli endpoint online (anteprima) e Accesso ai segreti dalla distribuzione online tramite l'inserimento di segreti (anteprima).
ERROR: InternalServerError
Anche se l'impegno Microsoft mira a fornire un servizio stabile e affidabile, a volte le cose non vanno secondo i piani. Se viene visualizzato questo errore, significa che qualcosa non è andato a buon fine a livello di server e la risoluzione di questo problema è responsabilità di Microsoft. Inviare un ticket di supporto clienti con tutte le informazioni correlate necessarie per la risoluzione del problema.
Errori comuni specifici delle distribuzioni Kubernetes
Errori relativi all'identità e all'autenticazione:
- ACRSecretError
- TokenRefreshFailed
- GetAADTokenFailed
- ACRAuthenticationChallengeFailed
- ACRTokenExchangeFailed
- KubernetesUnaccessible
Errori relativi a crashloopbackoff:
Errori relativi allo script di punteggio:
Altri:
- NamespaceNotFound
- EndpointAlreadyExists
- ScoringFeUnhealthy
- ValidateScoringFailed
- InvalidDeploymentSpec
- PodUnschedulable
- PodOutOfMemory
- InferencingClientCallFailed
ERROR: ACRSecretError
L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore durante la creazione e l'aggiornamento delle distribuzioni online Kubernetes:
- L'assegnazione di ruolo non è stata completata. In questo caso, attendere alcuni secondi e riprovare più tardi.
- L'estensione Azure ARC (per il cluster Azure Arc Kubernetes) o l'estensione Azure Machine Learning (per il servizio Azure Kubernetes) non è installata o configurata correttamente. Provare a controllare la configurazione e lo stato dell'estensione Azure ARC o Azure Machine Learning.
- Il cluster Kubernetes ha una configurazione di rete non corretta; controllare il proxy, i criteri di rete o il certificato.
- Se si usa un cluster del servizio Azure Kubernetes privato, è necessario configurare endpoint privati per Registro Azure Container, account di archiviazione e area di lavoro nella rete virtuale del servizio Azure Kubernetes.
- Assicurarsi che la versione dell'estensione Azure Machine Learning sia successiva alla versione 1.1.25.
ERROR: TokenRefreshFailed
Questo errore è dovuto al fatto che l'estensione non riesce a recuperare le credenziali dell'entità di sicurezza da Azure perché l'identità del cluster Kubernetes non è impostata correttamente. Reinstallare l'estensione Azure Machine Learning e riprovare.
ERROR: GetAADTokenFailed
Questo errore è dovuto al fatto che il token di Azure AD della richiesta del cluster Kubernetes ha avuto esito negativo o si è verificato il timeout; controllare l'accessibilità di rete e riprovare.
- È possibile fare riferimento alla sezione Configurare il traffico di rete necessario per controllare il proxy in uscita; assicurarsi che il cluster possa connettersi all'area di lavoro.
- L'URL dell'endpoint dell'area di lavoro è disponibile nella definizione di risorse personalizzate (CRD) dell'endpoint online nel cluster.
Se l'area di lavoro è un'area di lavoro privata, con l'accesso alla rete pubblica disabilitato, il cluster Kubernetes deve comunicare solo con l'area di lavoro privata tramite il collegamento privato.
- È possibile verificare se l'accesso all'area di lavoro consente l'accesso pubblico; indipendentemente dal fatto che un cluster del servizio Azure Kubernetes sia pubblico o privato, non può accedere all'area di lavoro privata.
- Per altre informazioni, vedere Proteggere l'ambiente di inferenza del servizio Azure Kubernetes.
ERROR: ACRAuthenticationChallengeFailed
Questo errore è dovuto al fatto che il cluster Kubernetes non riesce a raggiungere il servizio Registro Azure Container dell'area di lavoro per eseguire una richiesta di autenticazione. Controllare la rete, in particolare l'accesso alla rete pubblica del Registro Azure Container, quindi riprovare.
È possibile seguire i passaggi per la risoluzione dei problemi validi per l'errore GetAADTokenFailed per controllare la rete.
ERROR: ACRTokenExchangeFailed
Questo errore è dovuto al fatto che il token del Registro Azure Container per lo scambio di cluster Kubernetes ha avuto esito negativo perché il token di Azure AD non è ancora autorizzato. Poiché l'assegnazione di ruolo richiede tempo, è possibile attendere e quindi riprovare.
Questo errore potrebbe anche essere dovuto a un numero eccessivo di richieste al servizio Registro Azure Container in determinato momento. Poiché dovrebbe essere un errore temporaneo, è possibile riprovare in un secondo momento.
ERROR: KubernetesUnaccessible
È possibile che venga visualizzato l'errore seguente durante le distribuzioni del modello Kubernetes:
{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}
Per ridurre l'impatto di questo errore, è possibile:
- Eseguire la rotazione del certificato del servizio Azure Kubernetes per il cluster. Per altre informazioni, vedere Rotazione dei certificati nel servizio Azure Kubernetes.
- Il nuovo certificato deve essere aggiornato dopo 5 ore. Attendere pertanto 5 ore e ridistribuirlo.
ERROR: ImagePullLoopBackOff
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è dovuto al fatto che non è possibile scaricare le immagini dal registro contenitori e ciò causa l'errore di pull delle immagini.
In questo caso, è possibile controllare i criteri di rete del cluster e il registro contenitori dell'area di lavoro per verificare se il cluster può eseguire il pull dell'immagine dal registro contenitori.
ERROR: DeploymentCrashLoopBackOff
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è l'arresto anomalo dell'inizializzazione del contenitore utente. Le cause di questo errore possono essere due:
- Lo script utente
score.py
presenta un errore di sintassi o un errore di importazione e pertanto eccezioni durante l'inizializzazione. - In alternativa, il pod di distribuzione richiede una quantità di memoria maggiore rispetto al limite.
Per ridurre l'impatto di questo errore, è prima possibile controllare i log di distribuzione per verificare la presenza di eventuali eccezioni negli script utente. Se l'errore persiste, provare a estendere il limite di memoria per il tipo di istanza o le risorse.
ERROR: KubernetesCrashLoopBackOff
L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore durante la creazione e l'aggiornamento di endpoint/distribuzioni online Kubernetes:
- Uno o più pod bloccati nello stato CrashLoopBackoff; è possibile verificare se il log di distribuzione esiste e se sono presenti messaggi di errore nel log.
- Si verifica un errore in
score.py
e il contenitore si arresta in modo anomalo quando viene inizializzato il codice del punteggio; fare riferimento alla parte ERROR: ResourceNotReady. - Il processo di assegnazione del punteggio richiede una quantità maggiore di memoria rispetto al limite della configurazione della distribuzione. È possibile provare ad aggiornare la distribuzione con un limite di memoria superiore.
ERROR: NamespaceNotFound
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento degli endpoint online Kubernetes è l'indisponibilità dello spazio dei nomi usato dall'ambiente di calcolo Kubernetes nel cluster.
È possibile controllare l'ambiente di calcolo Kubernetes nel portale dell'area di lavoro e lo spazio dei nomi nel cluster Kubernetes. Se lo spazio dei nomi non è disponibile, è possibile scollegare l'ambiente di calcolo legacy e ricollegarlo per crearne uno nuovo, specificando uno spazio dei nomi già esistente nel cluster.
ERROR: UserScriptInitFailed
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il fatto che la funzione init nel file caricato score.py
ha generato un'eccezione.
È possibile controllare i log di distribuzione per visualizzare il messaggio di eccezione in dettaglio e correggere l'eccezione.
ERROR: UserScriptImportError
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il fatto che il file score.py
caricato ha importato pacchetti non disponibili.
È possibile controllare i log di distribuzione per visualizzare il messaggio di eccezione in dettaglio e correggere l'eccezione.
ERROR: UserScriptFunctionNotFound
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il fatto che il file score.py
caricato non dispone di una funzione denominata init()
o run()
. È possibile controllare il codice e aggiungere la funzione.
ERROR: EndpointNotFound
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il fatto che il sistema non riesce a trovare la risorsa endpoint per la distribuzione nel cluster. È necessario creare la distribuzione in un endpoint esistente o creare questo endpoint prima nel cluster.
ERROR: EndpointAlreadyExists
Il motivo per cui è possibile che si verifichi questo errore durante la creazione di un endpoint online Kubernetes è il fatto che l'endpoint in fase di creazione esiste già nel cluster.
Il nome dell'endpoint deve essere univoco per area di lavoro e per ogni cluster. In questo caso, è pertanto necessario creare un endpoint con un altro nome.
ERROR: ScoringFeUnhealthy
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento di un endpoint online Kubernetes/distribuzione online è il fatto che il servizio di sistema Azureml-fe in esecuzione nel cluster non viene trovato o non è integro.
Per risolvere questo problema, è possibile reinstallare o aggiornare l'estensione Azure Machine Learning nel cluster.
ERROR: ValidateScoringFailed
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il fatto che la convalida dell'URL della richiesta di assegnazione del punteggio non è riuscita durante l'elaborazione della distribuzione del modello.
In questo caso, per prima cosa è possibile controllare l'URL dell'endpoint e quindi provare a rieseguire la distribuzione.
ERROR: InvalidDeploymentSpec
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento delle distribuzioni online Kubernetes è il fatto che la specifica di distribuzione non è valida.
In questo caso, è possibile controllare il messaggio di errore.
- Assicurarsi che
instance count
sia valido. - Se la scalabilità automatica è stata abilitata, assicurarsi che
minimum instance count
emaximum instance count
siano entrambi validi.
ERROR: PodUnschedulable
L'elenco seguente riporta i motivi per cui è possibile riscontrare questo errore durante la creazione e l'aggiornamento di endpoint/distribuzioni online Kubernetes:
- Non è possibile pianificare il pod nei nodi, a causa di risorse insufficienti nel cluster.
- Nessuna affinità/selettore per corrispondenza nodi.
Per ridurre l'impatto di questo errore, seguire questa procedura:
- Controllare la definizione di
node selector
del parametroinstance type
usato e la configurazione dinode label
dei nodi del cluster. - Controllare
instance type
e le dimensioni dello SKU del nodo per il cluster del servizio Azure Kubernetes o la risorsa del nodo per il cluster ARC-Kubernetes.- Se il cluster dispone di risorse insufficienti, è possibile ridurre il requisito della risorsa di tipo istanza o usare un altro tipo di istanza con requisiti inferiori a livello di risorse richieste.
- Se il cluster non dispone più di risorse per soddisfare il requisito della distribuzione, eliminare alcune distribuzioni per rilasciare le risorse.
ERROR: PodOutOfMemory
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento della distribuzione online è il fatto che il limite di memoria assegnato per la distribuzione risulta insufficiente. È possibile impostare il limite di memoria su un valore maggiore o usare un tipo di istanza più grande per ridurre l'impatto di questo errore.
ERROR: InferencingClientCallFailed
Il motivo per cui è possibile che si verifichi questo errore durante la creazione/aggiornamento di endpoint online Kubernetes/distribuzioni è il fatto che l'estensione k8s del cluster Kubernetes nel cluster non è collegabile.
In questo caso, è possibile scollegare e quindi ricollegare l'ambiente di calcolo.
Nota
Per risolvere gli errori mediante lo scollegamento, assicurarsi di rieseguire il collegamento con la stessa configurazione dell'ambiente di calcolo scollegato in precedenza, ad esempio lo stesso nome dell'ambiente di calcolo e lo stesso spazio dei nomi. In caso contrario, potrebbero verificarsi altri errori.
Se il problema persiste, è possibile chiedere all'amministratore con accesso al cluster di usare kubectl get po -n azureml
per verificare se i pod del server di inoltro sono in esecuzione.
Problemi di scalabilità automatica
Se si verificano problemi con la scalabilità automatica, vedere Risoluzione dei problemi di scalabilità automatica di Azure.
Per l'endpoint online Kubernetes, è disponibile un router di inferenza di Azure Machine Learning che è un componente front-end per gestire la scalabilità automatica per tutte le distribuzioni di modelli nel cluster Kubernetes. Per altre informazioni, vedere Scalabilità automatica del routing dell'inferenza Kubernetes.
Errori comuni relativi all'utilizzo di modelli
L'elenco seguente si riferisce agli errori comuni di utilizzo del modello risultanti dallo stato dell'operazione invoke
dell'endpoint.
Problemi relativi al limite della larghezza di banda
Gli endpoint online gestiti hanno limiti di larghezza di banda per ogni endpoint. La configurazione del limite è disponibile nei limiti per gli endpoint online. Se l'utilizzo della larghezza di banda supera il limite, la richiesta viene ritardata. Per monitorare il ritardo della larghezza di banda:
- Usare la metrica "Byte di rete" per analizzare l'utilizzo corrente della larghezza di banda. Per altre informazioni, vedere Monitorare gli endpoint online gestiti.
- Se viene applicato il limite di larghezza di banda, vengono restituiti due trailer di risposta:
ms-azureml-bandwidth-request-delay-ms
: tempo di ritardo in millisecondi necessario per il trasferimento del flusso della richiesta.ms-azureml-bandwidth-response-delay-ms
: tempo di ritardo in millisecondi necessario per il trasferimento del flusso della risposta.
Codici di stato HTTP
Quando si accede ai servizi Web con richieste REST, i codici di stato restituiti rispettano gli standard dei codici di stato HTTP. Di seguito sono riportate informazioni dettagliate sul mapping tra gli errori di chiamata e previsione del servizio Web e i codici di stato HTTP.
Codici di errore comuni per gli endpoint online gestiti
La tabella seguente contiene i codici di errore comuni quando si utilizzano endpoint online gestiti con richieste REST:
Codice di stato | Frase per il motivo | Possibile motivo della restituzione di questo codice |
---|---|---|
200 | OK | Il modello è stato eseguito correttamente nel rispetto del limite di latenza. |
401 | Non autorizzata | Non si dispone dell'autorizzazione necessaria per eseguire l'azione richiesta, ad esempio il calcolo del punteggio, oppure il token è scaduto. Per altre informazioni, vedere Concetto relativo all’autenticazione dell’endpoint e Come eseguire l'autenticazione per l'endpoint. |
404 | Non trovato | L'endpoint non ha una distribuzione valida con peso positivo. |
408 | Timeout richiesta | L'esecuzione del modello ha richiesto più tempo rispetto al timeout fornito in request_timeout_ms in request_settings della configurazione della distribuzione del modello. |
424 | Errore del modello | Se il contenitore di modelli restituisce una risposta non 200, Azure restituisce una risposta 424. Controllare la dimensione Model Status Code nella metrica Requests Per Minute in Esplora metriche di Monitoraggio di Azure dell'endpoint. In alternativa, controllare le intestazioni della risposta ms-azureml-model-error-statuscode e ms-azureml-model-error-reason per altre informazioni. Se la risposta 424 presenta problemi a livello di probe di attività o idoneità, valutare la possibilità di modificare le impostazioni del probe per consentire tempi più lunghi per esaminare l'attività o l'idoneità del contenitore. |
429 | Troppe richieste in sospeso | Il modello sta attualmente ricevendo più richieste di quante possa gestire. Azure Machine Learning ha implementato un sistema che consente di elaborare in parallelo un massimo di 2 * max_concurrent_requests_per_instance * instance_count requests in qualsiasi momento per garantire un funzionamento ottimale. Le richieste che superano questo valore massimo vengono rifiutate. È possibile esaminare la configurazione della distribuzione del modello nelle sezioni request_settings e scale_settings per verificare e modificare queste impostazioni. Inoltre, come descritto nella definizione YAML per RequestSettings, è importante assicurarsi che la variabile di ambiente WORKER_COUNT venga passata correttamente. Se si usa la scalabilità automatica e si riceve questo errore, significa che il modello sta ricevendo richieste più rapidamente rispetto alla velocità con cui il sistema in grado di aumentare le prestazioni. In questo caso, valutare la possibilità di inviare di nuovo le richieste con un backoff esponenziale per fornire al sistema il tempo di adeguamento necessario. È anche possibile aumentare il numero di istanze usando il codice per calcolare il numero di istanze. Questi passaggi, assieme all'impostazione della scalabilità automatica, consentono di garantire che il modello sia pronto per gestire il flusso di richieste in entrata. |
429 | Velocità limitata | Il numero di richieste al secondo ha raggiunto i limiti degli endpoint online gestiti. |
500 | Errore interno del server | L'infrastruttura con provisioning di Azure Machine Learning ha esito negativo. |
Codici di errore comuni per gli endpoint online Kubernetes
La tabella seguente contiene codici di errore comuni quando si usano endpoint online Kubernetes con richieste REST:
Codice di stato | Frase per il motivo | Possibile motivo della restituzione di questo codice |
---|---|---|
409 | errore di conflitto | Quando un'operazione è già in corso, qualsiasi nuova operazione nello stesso endpoint online risponderà con un errore di conflitto 409. Ad esempio, se l'operazione di creazione o aggiornamento dell'endpoint online è in corso e, se si attiva una nuova operazione di eliminazione, viene generato un errore. |
502 | È stata generata un'eccezione o si è verificato un arresto anomalo nel metodo run() del file score.py |
Quando si verifica un errore in score.py , ad esempio un pacchetto importato non esiste nell'ambiente conda, un errore di sintassi o un errore nel metodo init() . È possibile seguire la procedura descritta qui per eseguire il debug del file. |
503 | Ricevere un numero elevato di picchi nelle richieste al secondo | La scalabilità automatica è progettata per gestire variazioni graduali a livello di carico. Se si riceve un numero elevato di picchi nelle richieste al secondo, i client potrebbero ricevere un codice di stato HTTP 503. Anche se la scalabilità automatica reagisce rapidamente, il servizio Azure Kubernetes richiede molto tempo per creare più contenitori. È possibile seguire la procedura descritta qui per evitare codici di stato 503. |
504 | Timeout della richiesta | Un codice di stato 504 indica che si è verificato il timeout della richiesta. L'impostazione predefinita del timeout è di 5 secondi. È possibile aumentare il timeout o provare ad accelerare l'endpoint modificando il file score.py per rimuovere le chiamate non necessarie. Se queste azioni non risolvono il problema, è possibile seguire questa procedura per eseguire il debug del file score.py. Il codice potrebbe trovarsi in uno stato non reattivo o in un ciclo infinito. |
500 | Errore interno del server | L'infrastruttura con provisioning di Azure Machine Learning ha esito negativo. |
Come prevenire i codici di stato 503
Le distribuzioni online Kubernetes supportano la scalabilità automatica, che consente l'aggiunta di repliche per supportare il caricamento aggiuntivo; altre informazioni sono disponibili nel router di inferenza di Azure Machine Learning. Le decisioni per aumentare o ridurre le prestazioni si basano sull'utilizzo delle repliche dei contenitori correnti.
Esistono due elementi che consentono di prevenire codici di stato 503:
Suggerimento
Questi due approcci possono essere usati singolarmente o combinati.
Modificare il livello di utilizzo a cui il ridimensionamento automatico crea nuove repliche. È possibile regolare la destinazione di utilizzo impostando
autoscale_target_utilization
su un valore inferiore.Importante
Questa modifica non comporta la creazione di repliche più velocemente. Vengono invece create con una soglia di utilizzo inferiore. Anziché attendere fino al 70% di utilizzo del servizio, la modifica del valore su 30% comporta la creazione di repliche quando si verifica l'utilizzo al 30%.
Se l'endpoint online Kubernetes sta già usando il numero massimo di repliche correnti e vengono ancora visualizzati codici di stato 503, aumentare il valore di
autoscale_max_replicas
per aumentare il numero massimo di repliche.Modificare il numero minimo di repliche. L'aumento delle repliche minime offre un pool più grande per gestire i picchi in ingresso.
Per aumentare il numero di istanze, è possibile calcolare le repliche necessarie in base a questi codici.
from math import ceil # target requests per second target_rps = 20 # time to process the request (in seconds, choose appropriate percentile) request_process_time = 10 # Maximum concurrent requests per instance max_concurrent_requests_per_instance = 1 # The target CPU usage of the model container. 70% in this example target_utilization = .7 concurrent_requests = target_rps * request_process_time / target_utilization # Number of instance count instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)
Nota
Se si ricevono picchi di richieste di dimensioni maggiori di quelle che possono essere gestite dalle nuove repliche minime, si potrebbero ricevere nuovamente codici di stato 503. Ad esempio, mano a mano che il traffico verso l'endpoint aumenta, potrebbe essere necessario aumentare le repliche minime.
Come calcolare il numero di istanze
Per aumentare il numero di istanze, è possibile calcolare le repliche necessarie usando il codice seguente:
from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7
concurrent_requests = target_rps * request_process_time / target_utilization
# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)
Bloccato dai criteri CORS
Gli endpoint online (v2) attualmente non supportano la condivisione di risorse tra origini (CORS) in modo nativo. Se l'applicazione Web tenta di richiamare l'endpoint senza gestire correttamente le richieste preliminari CORS, è possibile visualizzare il messaggio di errore seguente:
Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.
È consigliabile usare Funzioni di Azure, il gateway applicazione di Azure o qualsiasi servizio come livello provvisorio per gestire le richieste preliminari CORS.
Problemi comuni di isolamento della rete
La creazione dell'endpoint online ha esito negativo con un messaggio V1LegacyMode == true
L'area di lavoro di Azure Machine Learning può essere configurata per v1_legacy_mode
, questo disabilita le API v2. Gli endpoint online gestiti sono una funzionalità della piattaforma API v2 e non funzionano se v1_legacy_mode
è abilitato per l'area di lavoro.
Importante
Rivolgersi al team della sicurezza di rete prima di disabilitare v1_legacy_mode
. Potrebbe essere stato abilitato dal team della sicurezza di rete per un motivo preciso.
Per informazioni su come disabilitare v1_legacy_mode
, vedere Isolamento rete con v2.
La creazione dell'endpoint online con l'autenticazione basata su chiavi ha esito negativo
Usare il comando seguente per elencare le regole di rete di Azure Key Vault per l'area di lavoro. Sostituire <keyvault-name>
con il nome dell'insieme di credenziali delle chiavi:
az keyvault network-rule list -n <keyvault-name>
La risposta di questo comando è simile al documento JSON seguente:
{
"bypass": "AzureServices",
"defaultAction": "Deny",
"ipRules": [],
"virtualNetworkRules": []
}
Se il valore di bypass
non è AzureServices
, seguire le istruzioni riportate in Configurare le impostazioni di rete dell'insieme di credenziali delle chiavi per impostarlo su AzureServices
.
Le distribuzioni online hanno esito negativo con un errore di download dell'immagine
Nota
Questo problema si verifica quando si usa il metodo di isolamento rete legacy per gli endpoint online gestiti, in cui Azure Machine Learning crea una rete virtuale gestita per ciascuna distribuzione in un endpoint.
Controllare se il flag
egress-public-network-access
è disabilitato per la distribuzione. Se questo flag è abilitato e la visibilità del registro contenitori è privata, è previsto questo errore.Usare il comando seguente per controllare lo stato della connessione all'endpoint privato. Sostituire
<registry-name>
con il nome del Registro Azure Container per la propria area di lavoro:az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{Name:name, status:privateLinkServiceConnectionState.status}"
Nel documento di risposta verificare che il campo
status
sia impostato suApproved
. Se non è approvato, usare il comando seguente per approvarlo. Sostituire<private-endpoint-name>
con il nome restituito dal comando precedente:az network private-endpoint-connection approve -n <private-endpoint-name>
L'endpoint di assegnazione dei punteggi non può essere risolto
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.
Usare il comando
nslookup
nel nome host dell'endpoint per recuperare le informazioni sull'indirizzo IP:nslookup endpointname.westcentralus.inference.ml.azure.com
La risposta contiene un indirizzo. Questo indirizzo deve trovarsi nell'intervallo specificato dalla rete virtuale
Nota
Per un endpoint online Kubernetes, il nome host dell'endpoint deve essere il CName (nome di dominio) specificato nel cluster Kubernetes. Se si tratta di un endpoint HTTP, l'indirizzo IP sarà contenuto nell'URI dell'endpoint che si può ottenere direttamente nell'interfaccia utente di Studio. Altri modi per ottenere l'indirizzo IP dell'endpoint sono disponibili in Endpoint online Kubernetes sicuro.
Se il nome host non viene risolto dal comando
nslookup
:Per l'endpoint online gestito,
Controllare se esiste un record A nella zona DNS privata per la rete virtuale.
Per controllare i record, usare il comando seguente:
az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name
I risultati devono contenere una voce simile a
*.<GUID>.inference.<region>
.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.
Se l'area di lavoro con un endpoint privato viene configurata usando un DNS personalizzato (Come usare l'area di lavoro con un server DNS personalizzato), usare il comando seguente per verificare se la risoluzione funziona correttamente dal DNS personalizzato.
dig endpointname.westcentralus.inference.ml.azure.com
Per l'endpoint online Kubernetes,
Controllare la configurazione DNS nel cluster Kubernetes.
Inoltre, per verificare se azureml-fe funziona come previsto, usare il comando seguente:
kubectl exec -it deploy/azureml-fe -- /bin/bash (Run in azureml-fe pod) curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json "Swagger not found"
Per HTTP, usare
curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json "Swagger not found"
Se curl HTTP ha esito negativo (ad esempio, timeout) ma HTTP funziona, controllare la validità del certificato.
Se il problema non viene risolto per il record A, verificare se la risoluzione funziona dal DNS di Azure(168.63.129.16).
dig @168.63.129.16 endpointname.westcentralus.inference.ml.azure.com
Se l'operazione ha esito positivo, è possibile risolvere i problemi relativi al server d'inoltro condizionale per il collegamento privato nel DNS personalizzato.
Non è possibile assegnare punteggi alle distribuzioni online
Usare il comando seguente per verificare se la distribuzione è stata eseguita correttamente:
az ml online-deployment show -e <endpointname> -n <deploymentname> --query '{name:name,state:provisioning_state}'
Se la distribuzione è stata completata correttamente, il valore di
state
saràSucceeded
.Se la distribuzione ha avuto esito positivo, usare il comando seguente per verificare che il traffico venga assegnato alla distribuzione. Sostituire
<endpointname>
con il nome dell'endpoint:az ml online-endpoint show -n <endpointname> --query traffic
Suggerimento
Questo passaggio non è necessario se si usa l'intestazione
azureml-model-deployment
nella richiesta per specificare come destinazione questa distribuzione.La risposta di questo comando deve riportare la percentuale di traffico assegnato alle distribuzioni.
Se le assegnazioni di traffico (o l'intestazione della distribuzione) sono impostate correttamente, usare il comando seguente per ottenere i log per l'endpoint. Sostituire
<endpointname>
con il nome dell'endpoint e<deploymentname>
con la distribuzione:az ml online-deployment get-logs -e <endpointname> -n <deploymentname>
Esaminare i log per controllare se si è verificato un problema durante l'esecuzione del codice di assegnazione dei punteggi quando una richiesta viene inviata alla distribuzione.
Risolvere i problemi del server di inferenza
In questa sezione vengono forniti suggerimenti di base per la risoluzione dei problemi del server HTTP di inferenza di Azure Machine Learning.
Passaggi principali
I passaggi di base per la risoluzione dei problemi sono:
- Raccogliere informazioni sulla versione per l'ambiente Python.
- Assicurarsi che la versione del pacchetto azureml-inference-server-http specificata nel file di ambiente corrisponda alla versione del server HTTP di inferenza di AzureML visualizzata nel log di avvio. A volte il sistema di risoluzione delle dipendenze pip può portare a versioni impreviste dei pacchetti installati.
- Se si specifica Flask (e/o le relative dipendenze) nell'ambiente, rimuoverle. Le dipendenze includono
Flask
,Jinja2
,itsdangerous
,Werkzeug
,MarkupSafe
eclick
. Flask è elencato come dipendenza nel pacchetto del server ed è consigliabile consentire l'installazione da parte del server. In questo modo, quando il server supporta le nuove versioni di Flask, tali versioni verranno recuperate automaticamente.
Versione del server
Il pacchetto server azureml-inference-server-http
viene pubblicato in PyPI. È possibile trovare il log delle modifiche e tutte le versioni precedenti nella pagina PyPI. Eseguire l'aggiornamento alla versione più recente se si usa una versione precedente.
- 0.4.x: versione nel pacchetto delle immagini di training ≤
20220601
e inazureml-defaults>=1.34,<=1.43
.0.4.13
è l'ultima versione stabile. Se si usa il server anteriore alla versione0.4.11
, potrebbero verificarsi problemi di dipendenze Flask, ad esempio non è possibile importare il nomeMarkup
dajinja2
. È consigliabile eseguire l'aggiornamento a0.4.13
o0.8.x
(versione più recente), se possibile. - 0.6.x: versione preinstallata nelle immagini di inferenza ≤ 20220516. L'ultima versione stabile è
0.6.1
. - 0.7.x: la prima versione che supporta Flask 2. L'ultima versione stabile è
0.7.7
. - 0.8.x: il formato del log è stato modificato e il supporto di Python 3.6 è stato eliminato.
Dipendenze dei pacchetti
I pacchetti più rilevanti per il server azureml-inference-server-http
sono i pacchetti seguenti:
- flask
- opencensus-ext-azure
- inference-schema
Se è stato specificato azureml-defaults
nell'ambiente Python, il pacchetto azureml-inference-server-http
ne sarà dipendente e verrà installato automaticamente.
Suggerimento
Se si usa Python SDK v1 e non si specifica azureml-defaults
in modo esplicito nell'ambiente Python, l'SDK può aggiungere il pacchetto. Tuttavia, lo bloccherà alla versione dell'SDK. Ad esempio, se la versione dell'SDK è 1.38.0
, verrà aggiunto azureml-defaults==1.38.0
ai requisiti pip dell'ambiente.
Domande frequenti
1. Si è verificato l'errore seguente durante l'avvio del server:
TypeError: register() takes 3 positional arguments but 4 were given
File "/var/azureml-server/aml_blueprint.py", line 251, in register
super(AMLBlueprint, self).register(app, options, first_registration)
TypeError: register() takes 3 positional arguments but 4 were given
Flask 2 è installato nell'ambiente Python, ma è in esecuzione una versione di azureml-inference-server-http
che non supporta Flask 2. Il supporto di Flask 2 viene aggiunto in azureml-inference-server-http>=0.7.0
, che anche si trova in azureml-defaults>=1.44
.
Se non si usa questo pacchetto in un'immagine Docker di AzureML, usare la versione più recente di
azureml-inference-server-http
oazureml-defaults
.Se si usa questo pacchetto con un'immagine Docker di AzureML, assicurarsi di usare un'immagine incorporata o successiva a luglio 2022. La versione dell'immagine è disponibile nei log del contenitore. Dovrebbe essere possibile trovare un log simile al seguente:
2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information 2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ############################################### 2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materializaton Build:20220708.v2 2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |
La data di compilazione dell'immagine viene visualizzata dopo la voce "Materialization Build", che nell'esempio precedente è
20220708
o 8 luglio 2022. Questa immagine è compatibile con Flask 2. Se nel log del contenitore non viene visualizzato un banner simile al seguente, l'immagine non è aggiornata e deve essere aggiornata. Se si usa un'immagine CUDA e non è possibile trovare un'immagine più recente, verificare se l'immagine è deprecata in AzureML-Containers. In caso affermativo, dovrebbe essere possibile trovare una sostituzione.Se si usa il server con un endpoint online, è anche possibile trovare i log in "Log di distribuzione" nella pagina dell'endpoint online nello studio di Azure Machine Learning. Se si esegue la distribuzione con SDK v1 e non si specifica in modo esplicito un'immagine nella configurazione di distribuzione, per impostazione predefinita viene usata una versione di
openmpi4.1.0-ubuntu20.04
corrispondente al set di strumenti dell'SDK locale, che potrebbe non essere la versione più recente dell'immagine. Ad esempio, SDK 1.43 usa l'impostazione predefinitaopenmpi4.1.0-ubuntu20.04:20220616
, che non è compatibile. Assicurarsi di usare l'SDK più recente per la distribuzione.Se per qualche motivo non è possibile aggiornare l'immagine, è possibile evitare temporaneamente il problema aggiungendo
azureml-defaults==1.43
oazureml-inference-server-http~=0.4.13
, che installerà la versione precedente del server conFlask 1.0.x
.
2. È stato rilevato un errore ImportError
o ModuleNotFoundError
nei moduli opencensus
, jinja2
, MarkupSafe
o click
durante l'avvio, come nel messaggio seguente:
ImportError: cannot import name 'Markup' from 'jinja2'
Le versioni precedenti (<= 0.4.10) del server non hanno aggiunto la dipendenza di Flask alle versioni compatibili. Questo problema è stato risolto nella versione più recente del server.
Passaggi successivi
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per