Risolvere gli errori dell'applicazione client negli account di archiviazione di Azure

Questo articolo illustra come analizzare gli errori dell'applicazione client usando metriche, log lato cliente log delle risorse in Monitoraggio di Azure.

Diagnostica degli errori

Gli utenti dell'applicazione possono notificare gli errori segnalati dall'applicazione client. Monitoraggio di Azure registra anche il numero di tipi di risposta diversi (dimensioni ResponseType ) dai servizi di archiviazione, ad esempio NetworkError, ClientTimeoutError o AuthorizationError. Benché Monitoraggio di Azure registri solo i conteggi dei diversi tipi di errore, è possibile ottenere più dettagli sulle singole richieste esaminando i file di log di lato server, lato client e rete. In genere, il codice di stato HTTP restituito dal servizio di archiviazione fornisce un'indicazione del motivo dell'esito negativo della richiesta.

Le seguenti risorse sono utili per l'interpretazione dei codici di errore e di stato correlati all'archiviazione:

• Codici di errore comuni dell'API REST
• Codici di errore del servizio BLOB
• Codici di errore del servizio di accodamento
• Codici di errore del servizio tabelle
• Codici di errore del servizio file

Il client sta ricevendo messaggi HTTP 403 (Accesso negato)

Se l'applicazione client genera errori HTTP 403 (Accesso negato), probabilmente il client sta utilizzando una firma di accesso condiviso (SAS, Shared Access Signature) scaduta per inviare una richiesta di archiviazione (benché esistano altre cause possibili, come sfasamento di orario, chiavi non valide e intestazioni vuote).

Storage Client Library per .NET consente di raccogliere i dati della registrazione lato client correlati alle operazioni di archiviazione eseguite dall'applicazione. Per altre informazioni, vedere Registrazione lato client con la libreria client di archiviazione .NET.

La tabella che segue mostra un esempio del file di log lato client generato da Storage Client Library in cui è illustrato il problema in corso:

In questo scenario, è necessario verificare perché il token SAS scade prima che il client invii il token al server:

• In genere, non è consigliabile impostare un'ora di inizio quando si crea una firma di accesso condiviso per l'uso immediato da parte di un client. Se sono presenti piccole differenze di clock tra l'host che genera la firma di accesso condiviso usando l'ora corrente e il servizio di archiviazione, è possibile che il servizio di archiviazione riceva una firma di accesso condiviso non ancora valida.

• Non impostare una scadenza molto breve in una firma di accesso condiviso. Come già detto, eventuali piccole differenze di orario tra l'host che genera la firma di accesso condiviso e il servizio di archiviazione possono far sì che la firma di accesso condiviso scada prima del tempo.

• Il parametro version nella chiave di firma di accesso condiviso (ad esempio, sv=2015-04-05) corrisponde alla versione della libreria client di archiviazione in uso? Si consiglia di usare sempre la versione più recente della libreria client di archiviazione.

• Se si rigenerano le chiavi di accesso alle risorse di archiviazione, tutti i token SAS esistenti potrebbero essere invalidati. Questo problema può verificarsi se si generano token SAS con tempo di scadenza lungo per le applicazioni client da memorizzare nella cache.

Se si usa la libreria client di archiviazione per generare token di firma di accesso condiviso, è facile compilare un token valido. Tuttavia, se si usa l'API REST di archiviazione e si creano manualmente i token di firma di accesso condiviso, vedere Delega dell'accesso con una firma di accesso condiviso.

Il client sta ricevendo messaggi HTTP 404 (Non trovato)

Se l'applicazione client riceve un messaggio HTTP 404 (Non trovato) dal server, ciò implica che l'oggetto che il client stava tentando di usare (ad esempio un'entità, una tabella, un BLOB, un contenitore o una coda) non esiste nel servizio di archiviazione. I motivi possono essere diversi, ad esempio:

• Il client o un altro processo ha eliminato l'oggetto in precedenza.

• Problema di autorizzazione della firma di accesso condiviso.

• Il codice JavaScript lato client non dispone dell'autorizzazione per accedere all'oggetto.

• Errore di rete.

Il client o un altro processo ha eliminato l'oggetto in precedenza

Negli scenari in cui il client sta tentando di leggere, aggiornare o eliminare i dati in un servizio di archiviazione, è facile identificare nella risorsa di archiviazione un'operazione precedente che ha eliminato l'oggetto in questione dal servizio di archiviazione. Spesso i dati del log indicano che un altro utente o processo ha eliminato l'oggetto. I log di Monitoraggio di Azure (lato server) vengono visualizzati quando un client ha eliminato un oggetto.

Nello scenario in cui un client sta tentando di inserire un oggetto, potrebbe non essere immediatamente ovvio perché questo risultato in una risposta HTTP 404 (Non trovato), dato che il client sta creando un nuovo oggetto. Tuttavia, se il client sta creando un BLOB, deve essere in grado di trovare il contenitore BLOB. Se il client sta creando un messaggio, deve essere in grado di trovare una coda. E se il client aggiunge una riga, deve essere in grado di trovare la tabella.

È possibile usare il log lato client dalla libreria client di archiviazione per comprendere meglio quando il client invia richieste specifiche al servizio di archiviazione.

Il log lato client seguente generato dalla libreria client di archiviazione illustra il problema quando il client non riesce a trovare il contenitore per il BLOB che sta creando. Il file di log include dettagli relativi alle seguenti operazioni di archiviazione:

Voci del log:

In questo esempio il log mostra che il client sta interleaving richieste dal CreateIfNotExists metodo (ID richiesta e2d06d78...) con le richieste del UploadFromStream metodo (de8b1c3c-...). Questa interleaving si verifica perché l'applicazione client richiama questi metodi in modo asincrono. Modificare il codice asincrono nel client per assicurarsi che crei il contenitore prima di tentare di caricare dati in un BLOB in tale contenitore. La soluzione migliore sarebbe creare prima tutti i contenitori.

Si è verificato un problema di autenticazione della firma di accesso condiviso

Se l'applicazione client tenta di usare una chiave di firma di accesso condiviso che non include le autorizzazioni necessarie per l'operazione, il servizio di archiviazione restituisce un messaggio HTTP 404 (Non trovato) al client. Allo stesso tempo, nelle metriche di Monitoraggio di Azure verrà visualizzato anche un AuthorizationError per la dimensione ResponseType .

Esaminare il motivo per cui l'applicazione client sta tentando di eseguire un'operazione per cui non è stata concessa l'autorizzazione.

Il codice JavaScript lato client non dispone dell'autorizzazione per accedere all'oggetto

Se si usa un client JavaScript e il servizio di archiviazione restituisce messaggi HTTP 404, verificare la presenza degli errori JavaScript seguenti nel browser:

SEC7120: origine http://localhost:56309 non trovata nell'intestazione Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: Errore di rete 0x80070005, Accesso negato.

Tali errori si verificano poiché il Web browser implementa come restrizione di sicurezza il criterio della stessa origine che impedisce che una pagina Web esegua una chiamata a un'API in un dominio diverso da quello da cui proviene la pagina.

Per risolvere il problema di JavaScript, è possibile configurare la condivisione di risorse tra le origini (CORS) per il servizio di archiviazione a cui accede il client. Per altre informazioni, vedere Supporto della condivisione delle risorse tra le origini (CORS) per i servizi di archiviazione Azure.

L'esempio di codice che segue indica come configurare il servizio BLOB per consentire l'esecuzione di JavaScript nel dominio Contoso in modo da poter accedere a un BLOB nel servizio di archiviazione BLOB:

var connectionString = Constants.connectionString;

 BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

 BlobServiceProperties sp = blobServiceClient.GetProperties();

 // Set the service properties.
 sp.DefaultServiceVersion = "2013-08-15";
 BlobCorsRule bcr = new BlobCorsRule();
 bcr.AllowedHeaders = "*";

 bcr.AllowedMethods = "GET,POST";
 bcr.AllowedOrigins = "http://www.contoso.com";
 bcr.ExposedHeaders = "x-ms-*";
 bcr.MaxAgeInSeconds = 5;
 sp.Cors.Clear();
 sp.Cors.Add(bcr);
 blobServiceClient.SetProperties(sp);

Errore della rete

In alcune circostanze, la perdita di pacchetti di rete può causare la restituzione da parte del servizio di archiviazione di messaggi HTTP 404 per il client. Ad esempio, quando l'applicazione client elimina un'entità dal servizio tabelle, il client genera un'eccezione di archiviazione che segnala un messaggio di stato "HTTP 404 (Non trovato)" dal servizio tabelle. Quando si esamina la tabella nel servizio di archiviazione tabelle, si può notare che il servizio ha eliminato l'entità come richiesto.

I dettagli dell'eccezione nel client includono l'ID richiesta (7e84f12d…) assegnato dal servizio tabelle per la richiesta. È possibile usare queste informazioni per individuare i dettagli della richiesta nei log delle risorse di archiviazione in Monitoraggio, eseguendo la ricerca in Campi che descrivono in che modo è stata autenticata l'operazione delle voci dei log. È inoltre possibile usare le metriche per identificare il momento in cui si verificano errori come questo e quindi eseguire una ricerca nei file di log in base all'orario in cui le metriche hanno registrato l'errore. Questa voce del file di log indica che l'eliminazione non è riuscita con messaggio di stato HTTP 404 (altro errore del client). La stessa voce di log include anche l'ID richiesta generato dal client nella client-request-id colonna (813ea74f...).

Il log lato server include anche un'altra voce con lo stesso client-request-id valore (813ea74f...) per un'operazione di eliminazione riuscita per la stessa entità e dallo stesso client. Questa operazione di eliminazione riuscita è stata eseguita poco prima della richiesta di eliminazione non riuscita.

La causa più probabile di questo scenario è che il client ha inviato una richiesta di eliminazione per l'entità al servizio tabelle, che ha avuto esito positivo ma non ha ricevuto un riconoscimento dal server (forse a causa di un problema di rete temporaneo). Il client ritenta quindi automaticamente l'operazione (usando lo stesso client-request-id) e questo nuovo tentativo non è riuscito perché l'entità era già stata eliminata.

Se questo problema si verifica di frequente, è necessario capire perché il client non riesce a ricevere le risposte di conferma dal servizio tabelle. Se il problema è intermittente, occorre bloccare l'errore "HTTP (404) Non trovato" e registrarlo nel log del client, ma consentire al client di continuare.

Il client sta ricevendo messaggi HTTP 409 (Conflitto)

Quando un client elimina contenitori BLOB, tabelle o code, è necessario un breve periodo prima che il nome diventi nuovamente disponibile. Se il codice nell'applicazione client viene eliminato e quindi ricrea immediatamente un contenitore BLOB con lo stesso nome, il CreateIfNotExists metodo avrà esito negativo con l'errore HTTP 409 (Conflitto).

L'applicazione client deve utilizzare nomi univoci per i contenitori ogni volta che crea nuovi contenitori se il pattern delete/recreate è comune.

Le metriche indicano un valore PercentSuccess basso o le voci del log di analisi contengono operazioni con stato della transazione ClientOtherErrors

Una dimensione ResponseType equivalente al valore di Success acquisisce la percentuale di operazioni eseguite correttamente in base al relativo codice di stato HTTP. Le operazioni con codici di stato 2XX vengono conteggiate come riuscite, mentre le operazioni con codici di stato in intervalli 3XX, 4XX e 5XX vengono conteggiate come non riuscite e abbassano il valore della metrica Operazione riuscita. Nei log delle risorse di archiviazione, queste operazioni vengono registrate con stato della transazione ClientOtherError.

Queste operazioni sono state completate correttamente e pertanto non influiscono su altre metriche, ad esempio la disponibilità. Alcuni esempi di operazioni eseguite correttamente ma che possono restituire codici di stato HTTP negativi sono:

• ResourceNotFound (non trovato 404), ad esempio da una richiesta GET a un BLOB che non esiste.
• ResourceAlreadyExists (Conflitto 409), ad esempio da un'operazione CreateIfNotExist in cui la risorsa esiste già.
• ConditionNotMet (non modificato 304), ad esempio da un'operazione condizionale, ad esempio quando un client invia un ETag valore e un'intestazione HTTP If-None-Match per richiedere un'immagine solo se è stata aggiornata dall'ultima operazione.

Per l'elenco dei codici di errore API REST che i servizi di archiviazione restituiscono più di frequente, vedere la pagina Codici di errore comuni dell'API REST.

Vedi anche

• Monitoraggio di Archivio BLOB di Azure
• Monitoraggio di File di Azure
• Monitoraggio di Archiviazione code di Azure
• Monitoraggio di Archiviazione tabelle di Azure
• Risolvere i problemi di prestazioni
• Risolvere i problemi di disponibilità
• Monitorare, diagnosticare e risolvere i problemi di Archiviazione di Azure

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.