Risolvere gli errori delle applicazioni client negli account di archiviazione di Azure

Articolo
04/10/2024

Questo articolo consente di analizzare gli errori delle applicazioni client usando metriche, log lato client e log delle risorse in Monitoraggio di Azure.

Diagnosi degli errori

Gli utenti dell'applicazione possono notificare gli errori segnalati dall'applicazione client. Monitoraggio di Azure registra anche i conteggi di tipi di risposta diversi (dimensioni ResponseType ) dai servizi di archiviazione, ad esempio NetworkError, ClientTimeoutError o AuthorizationError. Mentre Monitoraggio di Azure registra solo i conteggi dei diversi tipi di errore, è possibile ottenere maggiori dettagli sulle singole richieste esaminando i log sul lato server, sul lato client e sulla rete. In genere, il codice di stato HTTP restituito dal servizio di archiviazione fornirà un'indicazione del motivo per cui la richiesta non è riuscita.

Nota

Tenere presente che si dovrebbero verificare alcuni errori intermittenti. Ad esempio, errori dovuti a condizioni di rete temporanee o errori dell'applicazione.

Le risorse seguenti sono utili per comprendere lo stato e i codici di errore correlati all'archiviazione:

Il client riceve messaggi HTTP 403 (non consentiti)

Se l'applicazione client genera errori HTTP 403 (non consentiti), è probabile che il client usi una firma di accesso condiviso scaduta quando invia una richiesta di archiviazione (anche se altre possibili cause includono l'asimmetria del clock, chiavi non valide e intestazioni vuote).

La libreria client di archiviazione per .NET consente di raccogliere dati di log sul 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 seguente illustra un esempio del log sul lato client generato dalla libreria client di archiviazione che illustra questo problema che si verifica:

Origine	Dettaglio	Dettaglio	ID richiesta client	Testo dell'operazione
Microsoft.Azure.Storage	Informazioni	3	85d077ab-...	`Starting operation with location Primary per location mode PrimaryOnly.`
Microsoft.Azure.Storage	Informazioni	3	85d077ab -...	`Starting synchronous request to <https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request>`
Microsoft.Azure.Storage	Informazioni	3	85d077ab -...	`Waiting for response.`
Microsoft.Azure.Storage	Avviso	2	85d077ab -...	`Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.`
Microsoft.Azure.Storage	Informazioni	3	85d077ab -...	`Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .`
Microsoft.Azure.Storage	Avviso	2	85d077ab -...	`Exception thrown during the operation: The remote server returned an error: (403) Forbidden..`
Microsoft.Azure.Storage	Informazioni	3	85d077ab -...	`Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden..`
Microsoft.Azure.Storage	Informazioni	3	85d077ab -...	`The next location has been set to Primary, based on the location mode.`
Microsoft.Azure.Storage	Error	1	85d077ab -...	`Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.`

In questo scenario è necessario analizzare il motivo per cui il token di firma di accesso condiviso 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 un client da usare immediatamente. Se esistono 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. Anche in questo caso, piccole differenze di clock tra l'host che genera la firma di accesso condiviso e il servizio di archiviazione possono causare una scadenza della firma di accesso condiviso precedente al previsto.
Il parametro version nella chiave sas (ad esempio= sv2015-04-05) corrisponde alla versione della libreria client di archiviazione in uso? È consigliabile usare sempre la versione più recente della libreria client di archiviazione.
Se si rigenerano le chiavi di accesso di archiviazione, è possibile che tutti i token di firma di accesso condiviso esistenti vengano invalidati. Questo problema può verificarsi se si generano token di firma di accesso condiviso con una scadenza prolungata 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 costruiscono manualmente i token di firma di accesso condiviso, vedere Delegare l'accesso con una firma di accesso condiviso.

Il client riceve messaggi HTTP 404 (non trovati)

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. Ci sono una serie di possibili motivi per questo, ad esempio:

Il client o un altro processo ha eliminato l'oggetto in precedenza.
Problema di autorizzazione della firma di accesso condiviso.A Shared Access Signature (SAS) authorization issue.
Il codice JavaScript sul 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 dati in un servizio di archiviazione, è facile identificare nei log delle risorse di archiviazione un'operazione precedente che ha eliminato l'oggetto in questione dal servizio di archiviazione. Spesso, i dati di log mostrano 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 il motivo per cui questo genera una risposta HTTP 404 (non trovata), 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 sul lato client della libreria client di archiviazione per comprendere meglio quando il client invia richieste specifiche al servizio di archiviazione.

Il log sul 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. Questo log include i dettagli delle operazioni di archiviazione seguenti:

ID Richiesta	Operazione
07b26a5d-...	`DeleteIfExists` per eliminare il contenitore BLOB. Questa operazione include una richiesta HEAD per verificare l'esistenza del contenitore.
e2d06d78...	`CreateIfNotExists` per creare il contenitore BLOB. Questa operazione include una `HEAD` richiesta che verifica l'esistenza del contenitore. Restituisce `HEAD` un messaggio 404, ma continua.
de8b1c3c-...	`UploadFromStream` per creare il BLOB. La `PUT` richiesta ha esito negativo con un messaggio 404

Voci di log:

ID Richiesta	Testo operazione
07b26a5d-...	`Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.`
07b26a5d-...	`StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.`
07b26a5d-...	`Waiting for response.`
07b26a5d-...	`Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = "0x8D14D2DC63D059B".`
07b26a5d-...	`Response headers were processed successfully, proceeding with the rest of the operation.`
07b26a5d-...	`Downloading response body.`
07b26a5d-...	`Operation completed successfully.`
07b26a5d-...	`Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.`
07b26a5d-...	`StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.`
07b26a5d-...	`Waiting for response.`
07b26a5d-...	`Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = .`
07b26a5d-...	`Response headers were processed successfully, proceeding with the rest of the operation.`
07b26a5d-...	`Downloading response body.`
07b26a5d-...	`Operation completed successfully.`
e2d06d78-...	`Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer`.
e2d06d78-...	`StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.`
e2d06d78-...	`Waiting for response.`
de8b1c3c-...	`Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt.`
de8b1c3c-...	`StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt.`
de8b1c3c-...	`Preparing to write request data.`
e2d06d78-...	`Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..`
e2d06d78-...	`Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = .`
e2d06d78-...	`Response headers were processed successfully, proceeding with the rest of the operation.`
e2d06d78-...	`Downloading response body.`
e2d06d78-...	`Operation completed successfully.`
e2d06d78-...	`Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.`
e2d06d78-...	`StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.`
e2d06d78-...	`Waiting for response.`
de8b1c3c-...	`Writing request data.`
de8b1c3c-...	`Waiting for response.`
e2d06d78-...	`Exception thrown while waiting for response: The remote server returned an error: (409) Conflict..`
e2d06d78-...	`Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = .`
e2d06d78-...	`Downloading error response body.`
de8b1c3c-...	`Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..`
de8b1c3c-...	`Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = .`
de8b1c3c-...	`Exception thrown during the operation: The remote server returned an error: (404) Not Found..`
de8b1c3c-...	`Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found..`
e2d06d78-...	`Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict..`

In questo esempio, il log mostra che il client sta interfoliando le richieste dal CreateIfNotExists metodo (ID richiesta e2d06d78...) con le richieste dal UploadFromStream metodo (de8b1c3c-...). Questo interfoliamento 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 i dati in un BLOB in tale contenitore. Idealmente, è consigliabile creare tutti i contenitori in anticipo.

Problema di autorizzazione della firma di accesso condiviso

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

Esaminare il motivo per cui l'applicazione client sta tentando di eseguire un'operazione a cui non sono state concesse autorizzazioni.

Il codice JavaScript sul 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.

Nota

È possibile usare gli strumenti di sviluppo F12 in Internet Explorer per tracciare i messaggi scambiati tra il browser e il servizio di archiviazione durante la risoluzione dei problemi javaScript sul lato client.

Questi errori si verificano perché il Web browser implementa la stessa restrizione di sicurezza dei criteri di origine che impedisce a una pagina Web di chiamare un'API in un dominio diverso dal dominio da cui proviene la pagina.

Per risolvere il problema JavaScript, è possibile configurare la condivisione delle risorse tra origini (CORS) per il servizio di archiviazione a cui il client accede. Per altre informazioni, vedere Supporto cors (Cross-Origin Resource Sharing) per Servizi di archiviazione di Azure.

L'esempio di codice seguente illustra come configurare il servizio BLOB per consentire a JavaScript in esecuzione nel dominio Contoso di accedere a un BLOB nel servizio di archiviazione BLOB:

.NET v12 SDK

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

In alcuni casi, i pacchetti di rete persi possono comportare la restituzione di messaggi HTTP 404 al client da parte del servizio di archiviazione. Ad esempio, quando l'applicazione client elimina un'entità dal servizio tabelle, il client genera un'eccezione di archiviazione segnalando un messaggio di stato "HTTP 404 (non trovato)" dal servizio tabelle. Quando si esamina la tabella nel servizio di archiviazione tabelle, si nota 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 di Azure eseguendo una ricerca in Campi che descrivono come l'operazione è stata autenticata dalle voci di log. È anche possibile usare le metriche per identificare quando si verificano errori di questo tipo e quindi cercare i file di log in base al momento in cui le metriche hanno registrato l'errore. Questa voce di log mostra che l'eliminazione non è riuscita con un messaggio di stato "HTTP (404) Client Other Error". La stessa voce di log include anche l'ID richiesta generato dal client nella client-request-id colonna (813ea74f...).

Il log sul 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 ha avuto esito positivo 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 ha quindi ritentato 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 analizzare il motivo per cui il client non riesce a ricevere i riconoscimenti dal servizio tabelle. Se il problema è intermittente, è consigliabile intercettare l'errore "HTTP (404) Not Found" e registrarlo nel client, ma consentire al client di continuare.

Il client riceve 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 elimina 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 usare nomi di contenitori univoci ogni volta che crea nuovi contenitori se il modello di eliminazione/ricrea è comune.

Le metriche mostrano una percentuale bassa PercentSuccess o le voci di log di analisi hanno operazioni con stato della transazione ClientOtherErrors

Una dimensione ResponseType uguale a un valore di Success acquisisce la percentuale di operazioni riuscite in base al codice di stato HTTP. Le operazioni con codici di stato 2XX hanno esito positivo, mentre le operazioni con codici di stato negli intervalli 3XX, 4XX e 5XX vengono conteggiate come non riuscite e riducono il valore della metrica Success. Nei log delle risorse di archiviazione queste operazioni vengono registrate con lo 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 causare codici di stato HTTP non riusciti includono:

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.

È possibile trovare un elenco di codici di errore comuni dell'API REST restituiti dai servizi di archiviazione nella pagina Codici di errore comuni dell'API REST.

Vedere anche

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.