Monitorare, diagnosticare e risolvere i problemi di Archiviazione di Microsoft Azure (versione classica)

  • Articolo

Questa guida illustra come usare funzionalità come Azure Analisi archiviazione, la registrazione lato client nella libreria client di Archiviazione di Azure e altri strumenti di terze parti per identificare, diagnosticare e risolvere i problemi correlati ad Archiviazione di Azure.

Diagramma che mostra il flusso di informazioni tra le applicazioni client e i servizi di archiviazione di Azure.

Questa guida deve essere letta principalmente dagli sviluppatori di Servizi online che usano i servizi di archiviazione di Azure e i professionisti IT responsabili della gestione di tali Servizi online. Gli obiettivi di questa guida sono:

  • Per mantenere l'integrità e le prestazioni degli account di archiviazione di Azure.
  • Per fornire i processi e gli strumenti necessari per decidere se un problema o un problema in un'applicazione si riferisce ad Archiviazione di Azure.
  • Per fornire indicazioni utili per la risoluzione dei problemi relativi ad Archiviazione di Azure.

Nota

Questo articolo si basa sull'uso di metriche e log Analisi archiviazione definiti metriche e log classici. È consigliabile usare le metriche e i log di Archiviazione di Azure in Monitoraggio di Azure anziché Analisi archiviazione log. Per altre informazioni, vedere uno degli articoli seguenti:

Panoramica

La diagnosi e la risoluzione dei problemi in un'applicazione distribuita ospitata in un ambiente cloud può essere più complessa rispetto agli ambienti tradizionali. Le applicazioni possono essere distribuite in un'infrastruttura PaaS o IaaS, in locale, in un dispositivo mobile o in una combinazione di questi ambienti. In genere, il traffico di rete dell'applicazione può attraversare reti pubbliche e private e l'applicazione può usare più tecnologie di archiviazione, ad esempio tabelle Archiviazione di Microsoft Azure, BLOB, code o file, oltre ad altri archivi dati, ad esempio database relazionali e di documenti.

Per gestire correttamente tali applicazioni, è consigliabile monitorarle in modo proattivo e comprendere come diagnosticare e risolvere tutti gli aspetti di tali applicazioni e le relative tecnologie dipendenti. Gli utenti dei servizi di Archiviazione di Azure devono monitorare continuamente i servizi di archiviazione usati dall'applicazione per eventuali modifiche impreviste del comportamento (ad esempio tempi di risposta più lenti del solito) e usare la registrazione per raccogliere dati più dettagliati e analizzare in modo approfondito un problema. Le informazioni di diagnostica ottenute dal monitoraggio e dalla registrazione consentono di determinare la causa radice del problema riscontrato dall'applicazione. È quindi possibile risolvere il problema e determinare i passaggi appropriati per risolverlo. Archiviazione di Azure è un servizio di Azure di base e costituisce una parte importante della maggior parte delle soluzioni distribuite dai clienti nell'infrastruttura di Azure. Archiviazione di Azure include funzionalità per semplificare il monitoraggio, la diagnosi e la risoluzione dei problemi di archiviazione nelle applicazioni basate sul cloud.

Come è organizzata questa guida

La sezione Monitoraggio del servizio di archiviazione descrive come monitorare l'integrità e le prestazioni dei servizi di archiviazione di Azure usando le metriche di Analisi archiviazione di Azure (metriche di archiviazione).

La sezione Diagnosi dei problemi di archiviazione descrive come diagnosticare i problemi usando La registrazione di Analisi archiviazione di Azure (registrazione archiviazione). Descrive anche come abilitare la registrazione sul lato client usando le funzionalità in una delle librerie client, ad esempio la libreria client di archiviazione per .NET o Azure SDK per Java.

La sezione Traccia end-to-end descrive come correlare le informazioni contenute in vari file di log e dati delle metriche.

La sezione Indicazioni per la risoluzione dei problemi fornisce indicazioni per la risoluzione di alcuni dei problemi comuni relativi all'archiviazione che potrebbero verificarsi.

La sezione Appendici include informazioni sull'uso di altri strumenti, ad esempio Wireshark e Netmon per l'analisi dei dati dei pacchetti di rete, e Fiddler per l'analisi dei messaggi HTTP/HTTPS.

Monitoraggio del servizio di archiviazione

Se si ha familiarità con il monitoraggio delle prestazioni di Windows, è possibile considerare le metriche di archiviazione come un equivalente di Archiviazione di Azure dei contatori di Windows Monitor prestazioni. In Metriche di archiviazione è disponibile un set completo di metriche (contatori nella terminologia di Windows Monitor prestazioni), ad esempio la disponibilità del servizio, il numero totale di richieste di assistenza o la percentuale di richieste riuscite al servizio. Per un elenco completo delle metriche disponibili, vedere Analisi archiviazione Schema tabella metriche. È possibile specificare se si vuole che il servizio di archiviazione possa raccogliere e aggregare le metriche ogni ora o ogni minuto. Per altre informazioni su come abilitare le metriche e monitorare gli account di archiviazione, vedere Abilitazione delle metriche di archiviazione e visualizzazione dei dati delle metriche.

È possibile scegliere le metriche orarie da visualizzare nel portale di Azure e configurare regole che notificano agli amministratori tramite posta elettronica ogni volta che una metrica oraria supera una determinata soglia. Per altre informazioni, vedere Ricevere notifiche di avviso.

È consigliabile esaminare Monitoraggio di Azure per l'archiviazione (anteprima). Si tratta di una funzionalità di Monitoraggio di Azure che offre un monitoraggio completo degli account di archiviazione di Azure offrendo una visualizzazione unificata delle prestazioni, della capacità e della disponibilità dei servizi di Archiviazione di Azure. Non richiede di abilitare o configurare nulla ed è possibile visualizzare immediatamente queste metriche dai grafici interattivi predefiniti e da altre visualizzazioni incluse.

Il servizio di archiviazione tenta di raccogliere al meglio le metriche, ma potrebbe non registrare tutte le operazioni di archiviazione.

Nel portale di Azure è possibile visualizzare metriche come disponibilità, richieste totali e numeri di latenza media per un account di archiviazione. È stata inoltre configurata una regola di notifica per avvisare un amministratore se la disponibilità scende al di sotto di un determinato livello. Dalla visualizzazione di questi dati, un'area possibile per l'analisi è la percentuale di esito positivo del servizio tabelle inferiore al 100% (per altre informazioni, vedere la sezione Metriche con percentuale percentualesuccessa bassa o le voci del log di analisi hanno operazioni con stato della transazione di ClientOtherErrors ).

È necessario monitorare continuamente le applicazioni di Azure per assicurarsi che siano integre e che funzionino come previsto da:

  • Definizione di alcune metriche di base per l'applicazione che consentono di confrontare i dati correnti e identificare eventuali modifiche significative nel comportamento dell'archiviazione di Azure e dell'applicazione. I valori delle metriche di base saranno, in molti casi, specifici dell'applicazione e dovrebbero essere stabiliti durante il test delle prestazioni dell'applicazione.
  • Registrare le metriche dei minuti e usarle per monitorare attivamente errori e anomalie imprevisti, ad esempio picchi nei conteggi degli errori o frequenza delle richieste.
  • Registrare le metriche orarie e usarle per monitorare i valori medi, ad esempio i conteggi medi degli errori e la frequenza delle richieste.
  • Analisi dei potenziali problemi relativi all'uso degli strumenti di diagnostica, come illustrato più avanti nella sezione Diagnosi dei problemi di archiviazione .

I grafici nell'immagine seguente illustrano come la media che si verifica per le metriche orarie può nascondere i picchi di attività. Le metriche orarie sembrano mostrare una frequenza costante di richieste, mentre le metriche dei minuti rivelano le fluttuazioni effettivamente in corso.

Grafici che mostrano in che modo la media che si verifica per le metriche orarie può nascondere i picchi nell'attività.

Nella parte restante di questa sezione vengono descritte le metriche da monitorare e il motivo.

Monitoraggio dell'integrità del servizio

È possibile usare il portale di Azure per visualizzare l'integrità del servizio di archiviazione (e di altri servizi di Azure) in tutte le aree di Azure in tutto il mondo. Il monitoraggio consente di verificare immediatamente se un problema esterno al controllo influisce sul servizio di archiviazione nell'area usata per l'applicazione.

Il portale di Azure può anche fornire notifiche di eventi imprevisti che interessano i vari servizi di Azure.

Nota

Queste informazioni erano disponibili in precedenza, insieme ai dati cronologici, nel dashboard del servizio di Azure. Per altre informazioni su Application Insights per Azure DevOps, vedere Appendice 5: Monitoraggio con Application Insights per Azure DevOps.

Capacità di monitoraggio

Le metriche di archiviazione archiviano solo le metriche di capacità per il servizio BLOB perché i BLOB rappresentano in genere la percentuale maggiore di dati archiviati(al momento della scrittura, non è possibile usare le metriche di archiviazione per monitorare la capacità delle tabelle e delle code). È possibile trovare questi dati nella $MetricsCapacityBlob tabella se è stato abilitato il monitoraggio per il servizio BLOB. Le metriche di archiviazione registrano questi dati una volta al giorno ed è possibile usare il valore di RowKey per determinare se la riga contiene un'entità correlata ai dati utente (valore data) o ai dati analitici (valore analytics). Ogni entità archiviata contiene informazioni sulla quantità di archiviazione usata (Capacity misurata in byte) e sul numero corrente di contenitori (ContainerCount) e BLOB (ObjectCount) in uso nell'account di archiviazione. Per altre informazioni sulle metriche di capacità archiviate nella $MetricsCapacityBlob tabella, vedere Analisi archiviazione Schema tabella metriche.

Nota

È consigliabile monitorare questi valori per segnalare in anticipo che si stanno raggiungendo i limiti di capacità dell'account di archiviazione. Nel portale di Azure è possibile aggiungere regole di avviso per notificare se l'uso dell'archiviazione aggregata supera o scende al di sotto delle soglie specificate.

Per stimare le dimensioni di vari oggetti di archiviazione, ad esempio BLOB, vedere il post di blog Understanding Azure Storage Billing – Bandwidth, Transactions, and Capacity (Informazioni sulla fatturazione dell'archiviazione di Azure - Larghezza di banda, transazioni e capacità).

Monitoraggio della disponibilità

È consigliabile monitorare la disponibilità dei servizi di archiviazione nell'account di archiviazione monitorando il valore nella Availability colonna nelle tabelle delle metriche orarie o minuti , $MetricsHourPrimaryTransactionsBlob, $MetricsHourPrimaryTransactionsQueue$MetricsHourPrimaryTransactionsTable, $MetricsMinutePrimaryTransactionsBlob, $MetricsMinutePrimaryTransactionsTable, $MetricsMinutePrimaryTransactionsQueue, $MetricsCapacityBlob. La Availability colonna contiene un valore percentuale che indica la disponibilità del servizio o l'operazione API rappresentata dalla riga ( indica RowKey se la riga contiene metriche per il servizio nel suo complesso o per un'operazione API specifica).

Qualsiasi valore inferiore al 100% indica che alcune richieste di archiviazione hanno esito negativo. È possibile capire perché hanno esito negativo esaminando le altre colonne nei dati delle metriche che mostrano il numero di richieste con tipi di errore diversi, ad esempio ServerTimeoutError. Per motivi quali timeout temporanei del server, si dovrebbe prevedere un Availability calo temporaneo al di sotto del 100%, mentre il servizio sposta le partizioni in richieste di bilanciamento del carico migliori. La logica di ripetizione dei tentativi nell'applicazione client deve gestire tali condizioni intermittenti. L'articolo Analisi archiviazione Operazioni registrate e messaggi di stato elenca i tipi di transazione inclusi nelle metriche di archiviazione nel calcoloAvailability.

Nel portale di Azure è possibile aggiungere regole di avviso per notificare se Availability per un servizio è inferiore a una soglia specificata.

La sezione Indicazioni per la risoluzione dei problemi di questa guida descrive alcuni problemi comuni del servizio di archiviazione correlati alla disponibilità.

Monitoraggio delle prestazioni

Per monitorare le prestazioni dei servizi di archiviazione, è possibile usare le metriche seguenti delle tabelle delle metriche orarie e dei minuti.

  • I valori nelle AverageE2ELatency colonne e AverageServerLatency mostrano il tempo medio che il servizio di archiviazione o il tipo di operazione API sta impiegando per elaborare le richieste. AverageE2ELatency è una misura della latenza end-to-end che include il tempo impiegato per leggere la richiesta e inviare la risposta oltre al tempo impiegato per elaborare la richiesta (include pertanto la latenza di rete una volta che la richiesta raggiunge il servizio di archiviazione); AverageServerLatency è una misura solo del tempo di elaborazione e pertanto esclude qualsiasi latenza di rete correlata alla comunicazione con il client. Vedere la sezione Metrics show high AverageE2ELatency and low AverageServerLatency più avanti in questa guida per una descrizione del motivo per cui potrebbe esserci una differenza significativa tra questi due valori.
  • I valori nelle TotalIngress colonne e TotalEgress mostrano la quantità totale di dati, in byte, che entrano e escono dal servizio di archiviazione o tramite un tipo di operazione API specifico.
  • I valori nella TotalRequests colonna mostrano il numero totale di richieste ricevute dal servizio di archiviazione dell'operazione API. TotalRequests è il numero totale di richieste ricevute dal servizio di archiviazione.

In genere, si monitorerà la ricerca di modifiche impreviste in uno di questi valori, in quanto indica che si è verificato un problema che richiede un'indagine.

Nel portale di Azure è possibile aggiungere regole di avviso per notificare se le metriche delle prestazioni per questo servizio sono inferiori o superano una soglia specificata.

La sezione Indicazioni per la risoluzione dei problemi di questa guida descrive alcuni problemi comuni del servizio di archiviazione correlati alle prestazioni.

Diagnosi dei problemi di archiviazione

Esistono diversi modi per venire a conoscenza di un problema o di un problema nell'applicazione, tra cui:

  • Errore principale che causa l'arresto anomalo o l'arresto anomalo dell'applicazione.
  • Modifiche significative rispetto ai valori di base nelle metriche da monitorare, come descritto nella sezione precedente Monitoraggio del servizio di archiviazione.
  • Segnala agli utenti dell'applicazione che una determinata operazione non è stata completata come previsto o che alcune funzionalità non funzionano.
  • Errori generati all'interno dell'applicazione che vengono visualizzati nei file di log o tramite un altro metodo di notifica.

In genere, i problemi relativi ai servizi di archiviazione di Azure rientrano in una delle quattro categorie principali:

  • L'applicazione presenta un problema di prestazioni, segnalato dagli utenti o rilevato dalle modifiche nelle metriche delle prestazioni.
  • Si è verificato un problema con l'infrastruttura di Archiviazione di Azure in una o più aree.
  • L'applicazione sta riscontrando un errore, segnalato dagli utenti o rivelato da un aumento di una delle metriche di conteggio degli errori monitorate.
  • Durante lo sviluppo e il test, è possibile usare l'emulatore di archiviazione locale. è possibile che si verifichino alcuni problemi correlati in modo specifico all'utilizzo dell'emulatore di archiviazione.

Le sezioni seguenti descrivono i passaggi da seguire per diagnosticare e risolvere i problemi in ognuna di queste quattro categorie. La sezione Indicazioni per la risoluzione dei problemi più avanti in questa guida fornisce maggiori dettagli per alcuni problemi comuni che potrebbero verificarsi.

Integrità dei servizi problemi

Integrità dei servizi problemi sono in genere al di fuori del controllo. Il portale di Azure fornisce informazioni su eventuali problemi in corso con i servizi di Azure, inclusi i servizi di archiviazione. Se si è scelto di Read-Access Geo-Redundant Storage al momento della creazione dell'account di archiviazione, se i dati non sono più disponibili nella posizione primaria, l'applicazione può passare temporaneamente alla copia di sola lettura nella posizione secondaria. Per eseguire la lettura dal database secondario, l'applicazione deve essere in grado di passare dall'uso dei percorsi di archiviazione primario a quello secondario ed essere in grado di lavorare in una modalità con funzionalità ridotte con dati di sola lettura. Le librerie client di Archiviazione di Azure consentono di definire criteri di ripetizione dei tentativi che possono essere letti dall'archiviazione secondaria nel caso in cui una lettura dall'archiviazione primaria non riesca. L'applicazione deve anche tenere presente che i dati nella posizione secondaria sono alla fine coerenti. Per altre informazioni, vedere il post di blog Opzioni di ridondanza dell'archiviazione di Azure e Archiviazione con ridondanza geografica di accesso in lettura.

Problemi di prestazioni

Le prestazioni di un'applicazione possono essere soggettive, soprattutto dal punto di vista dell'utente. Di conseguenza, è importante disporre di metriche di base disponibili per identificare gli eventuali problemi di prestazioni. Molti fattori possono influire sulle prestazioni di un servizio di archiviazione di Azure dal punto di vista dell'applicazione client. Questi fattori possono operare nel servizio di archiviazione, nel client o nell'infrastruttura di rete; è quindi importante avere una strategia per identificare l'origine del problema di prestazioni.

Dopo aver identificato la posizione probabile della causa del problema di prestazioni dalle metriche, è possibile usare i file di log per trovare informazioni dettagliate per diagnosticare e risolvere ulteriormente il problema.

La sezione Indicazioni per la risoluzione dei problemi più avanti in questa guida fornisce altre informazioni su alcuni problemi comuni correlati alle prestazioni che potrebbero verificarsi.

Diagnosi degli errori

Gli utenti dell'applicazione possono notificare gli errori segnalati dall'applicazione client. Le metriche di archiviazione registrano anche i conteggi dei diversi tipi di errore dei servizi di archiviazione, ad esempio NetworkError, ClientTimeoutError o AuthorizationError. Sebbene Le metriche di archiviazione registrino solo i conteggi di diversi tipi di errore, è possibile ottenere maggiori dettagli sulle singole richieste esaminando i log lato server, lato client e di 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:

Problemi dell'emulatore di archiviazione

Azure SDK include un emulatore di archiviazione che è possibile eseguire in una workstation di sviluppo. Questo emulatore simula la maggior parte del comportamento dei servizi di archiviazione di Azure ed è utile durante lo sviluppo e il test, consentendo di eseguire applicazioni che usano servizi di archiviazione di Azure senza la necessità di una sottoscrizione di Azure e di un account di archiviazione di Azure.

La sezione Indicazioni per la risoluzione dei problemi di questa guida descrive alcuni problemi comuni riscontrati con l'emulatore di archiviazione.

Strumenti di registrazione dell'archiviazione

Registrazione archiviazione fornisce la registrazione lato server delle richieste di archiviazione nell'account di archiviazione di Azure. Per altre informazioni su come abilitare la registrazione sul lato server e accedere ai dati di log, vedere Abilitazione della registrazione dell'archiviazione e dell'accesso ai dati di log.

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.

Nota

In alcuni casi, ad esempio errori di autorizzazione della firma di accesso condiviso, un utente può segnalare un errore per il quale non è possibile trovare dati di richiesta nei log di archiviazione sul lato server. È possibile usare le funzionalità di registrazione della libreria client di archiviazione per verificare se la causa del problema si trova nel client o usare gli strumenti di monitoraggio di rete per analizzare la rete.

Uso degli strumenti di registrazione di rete

È possibile acquisire il traffico tra il client e il server per fornire informazioni dettagliate sui dati scambiati dal client e dal server e sulle condizioni di rete sottostanti. Gli strumenti utili per la registrazione di rete includono:

In molti casi, i dati di log della registrazione archiviazione e della libreria client di archiviazione saranno sufficienti per diagnosticare un problema, ma in alcuni scenari potrebbero essere necessarie informazioni più dettagliate che questi strumenti di registrazione di rete possono fornire. Ad esempio, l'uso di Fiddler per visualizzare i messaggi HTTP e HTTPS consente di visualizzare i dati di intestazione e payload inviati da e verso i servizi di archiviazione, che consentono di esaminare il modo in cui un'applicazione client ritenta le operazioni di archiviazione. Gli analizzatori di protocollo, ad esempio Wireshark, operano a livello di pacchetto consentendo di visualizzare i dati TCP, consentendo di risolvere i problemi di connettività e pacchetti persi.

Traccia end-to-end

La traccia end-to-end che usa un'ampia gamma di file di log è una tecnica utile per analizzare i potenziali problemi. È possibile usare le informazioni di data/ora dai dati delle metriche per indicare dove iniziare a cercare nei file di log informazioni dettagliate per risolvere il problema.

Correlazione dei dati di log

Quando si visualizzano i log da applicazioni client, tracce di rete e registrazione dell'archiviazione sul lato server, è fondamentale poter correlare le richieste tra i diversi file di log. I file di log includono diversi campi utili come identificatori di correlazione. L'ID richiesta client è il campo più utile da usare per correlare le voci nei diversi log. Tuttavia, a volte può essere utile usare l'ID richiesta del server o i timestamp. Le sezioni seguenti forniscono altri dettagli su queste opzioni.

ID richiesta client

La libreria client di archiviazione genera automaticamente un ID richiesta client univoco per ogni richiesta.

  • Nel log sul lato client creato dalla libreria client di archiviazione, l'ID richiesta client viene visualizzato nel Client Request ID campo di ogni voce di log relativa alla richiesta.
  • In una traccia di rete, ad esempio quella acquisita da Fiddler, l'ID richiesta client è visibile nei messaggi di richiesta come valore dell'intestazione x-ms-client-request-id HTTP.
  • Nel log di registrazione archiviazione sul lato server, l'ID richiesta client viene visualizzato nella colonna ID richiesta client.

Nota

È possibile che più richieste condividano lo stesso ID richiesta client perché il client può assegnare questo valore (anche se la libreria client di archiviazione assegna automaticamente un nuovo valore). Quando il client riprova, tutti i tentativi condividono lo stesso ID richiesta client. Nel caso di un batch inviato dal client, il batch ha un singolo ID richiesta client.

ID richiesta server

Il servizio di archiviazione genera automaticamente gli ID richiesta del server.

  • Nel log di registrazione archiviazione sul lato server l'ID richiesta del server viene visualizzato nella Request ID header colonna .
  • In una traccia di rete, ad esempio quella acquisita da Fiddler, l'ID richiesta del server viene visualizzato nei messaggi di risposta come valore dell'intestazione x-ms-request-id HTTP.
  • Nel log sul lato client creato dalla libreria client di archiviazione, l'ID richiesta del Operation Text server viene visualizzato nella colonna per la voce di log che mostra i dettagli della risposta del server.

Nota

Il servizio di archiviazione assegna sempre un ID richiesta server univoco a ogni richiesta ricevuta, quindi ogni tentativo dal client e ogni operazione inclusa in un batch ha un ID richiesta server univoco.

L'esempio di codice seguente illustra come usare un ID richiesta client personalizzato.

var connectionString = Constants.connectionString;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");

BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");

string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
    BlobDownloadInfo download = blobClient.Download();

    using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
    {
        download.Content.CopyTo(downloadFileStream);
        downloadFileStream.Close();
    }
}

Timestamp

È anche possibile usare i timestamp per individuare le voci di log correlate, ma prestare attenzione a qualsiasi differenza di orologio tra il client e il server che può esistere. Search più o meno 15 minuti per le voci sul lato server corrispondenti in base al timestamp nel client. Tenere presente che i metadati del BLOB per i BLOB contenenti metriche indicano l'intervallo di tempo per le metriche archiviate nel BLOB. Questo intervallo di tempo è utile se sono presenti molti BLOB di metriche per lo stesso minuto o ora.

Istruzioni per la risoluzione dei problemi

Questa sezione illustra la diagnosi e la risoluzione dei problemi comuni che l'applicazione può riscontrare quando si usano i servizi di archiviazione di Azure. Usare l'elenco seguente per individuare le informazioni rilevanti per il problema specifico.

Risoluzione dei problemi relativi all'albero delle decisioni

Il problema riguarda le prestazioni di uno dei servizi di archiviazione?

Il problema riguarda la disponibilità di uno dei servizi di archiviazione?

L'applicazione client riceve una risposta HTTP 4XX (ad esempio 404) da un servizio di archiviazione?

Le metriche mostrano che le voci di log PercentSuccess o analytics hanno operazioni con stato di transazione ClientOtherErrors.

Le metriche di capacità mostrano un aumento imprevisto dell'utilizzo della capacità di archiviazione.

Il problema è dovuto all'uso dell'emulatore di archiviazione per lo sviluppo o il test.

Si verificano problemi durante l'installazione di Azure SDK per .NET.

Si è verificato un problema diverso con un servizio di archiviazione.

Le metriche mostrano un'elevata averageE2ELatency e una bassa averageServerLatency

La figura seguente dello strumento di monitoraggio portale di Azure mostra un esempio in cui AverageE2ELatency è significativamente superiore a AverageServerLatency.

Illustrazione del portale di Azure che mostra un esempio in cui AverageE2ELatency è significativamente superiore a AverageServerLatency.

Il servizio di archiviazione calcola solo la metrica AverageE2ELatency per le richieste riuscite e, a differenza di AverageServerLatency, include il tempo impiegato dal client per inviare i dati e ricevere il riconoscimento dal servizio di archiviazione. Di conseguenza, una differenza tra AverageE2ELatency e AverageServerLatency potrebbe essere dovuta al fatto che l'applicazione client è lenta a rispondere o a causa di condizioni sulla rete.

Nota

È anche possibile visualizzare E2ELatency e ServerLatency per le singole operazioni di archiviazione nei dati del log di registrazione archiviazione.

Analisi dei problemi di prestazioni del client

I possibili motivi per cui il client risponde lentamente includono la presenza di un numero limitato di connessioni o thread disponibili o l'esaurimento di risorse quali CPU, memoria o larghezza di banda di rete. È possibile risolvere il problema modificando il codice client in modo che sia più efficiente (ad esempio, usando chiamate asincrone al servizio di archiviazione) o usando una macchina virtuale più grande (con più core e più memoria).

Per i servizi di tabella e coda, l'algoritmo Nagle può anche causare un'elevata averageE2ELatency rispetto a AverageServerLatency.For the table and queue services, the Nagle algorithm can also cause high AverageE2ELatency compared to AverageServerLatency. Per altre informazioni, vedere Algoritmo di Nagle non descrittivo per le richieste di piccole dimensioni. È possibile disabilitare l'algoritmo Nagle nel codice usando la ServicePointManager classe nello spazio dei System.Net nomi . È consigliabile eseguire questa operazione prima di effettuare chiamate ai servizi di tabella o di coda nell'applicazione, in quanto ciò non influisce sulle connessioni già aperte. L'esempio seguente proviene dal Application_Start metodo in un ruolo di lavoro.

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

È consigliabile controllare i log sul lato client per verificare il numero di richieste inviate dall'applicazione client e verificare la presenza di informazioni generali. Colli di bottiglia delle prestazioni correlati a NET nel client, ad esempio CPU, Garbage Collection .NET, utilizzo della rete o memoria. Come punto di partenza per la risoluzione dei problemi delle applicazioni client .NET, vedere Debug, traccia e profilatura.

Analisi dei problemi di latenza di rete

In genere, la latenza end-to-end elevata causata dalla rete è dovuta a condizioni temporanee. È possibile analizzare i problemi di rete sia temporanei che persistenti, ad esempio i pacchetti eliminati, usando strumenti come Wireshark.

Per altre informazioni sull'uso di Wireshark per risolvere i problemi di rete, vedere Appendice 2: Uso di Wireshark per acquisire il traffico di rete.

Le metriche mostrano una bassa latenza AverageE2ELatency e una bassa averageServerLatency, ma il client sta riscontrando una latenza elevata

In questo scenario, la causa più probabile è un ritardo nelle richieste di archiviazione che raggiungono il servizio di archiviazione. È consigliabile analizzare il motivo per cui le richieste dal client non vengono inviate al servizio BLOB.

Un possibile motivo per cui il client ritarda l'invio delle richieste è che esiste un numero limitato di connessioni o thread disponibili.

Controllare anche se il client sta eseguendo più tentativi ed esaminare il motivo. Per determinare se il client esegue più tentativi, è possibile:

  • Esaminare i log Analisi archiviazione. Se si verificano più tentativi, verranno visualizzate più operazioni con lo stesso ID richiesta client ma con ID richiesta server diverso.
  • Esaminare i log client. La registrazione dettagliata indicherà che si è verificato un nuovo tentativo.
  • Eseguire il debug del codice e controllare le proprietà dell'oggetto OperationContext associato alla richiesta. Se l'operazione è stata ritentata, la RequestResults proprietà includerà più ID richiesta server univoci. È anche possibile controllare gli orari di inizio e fine per ogni richiesta. Per altre informazioni, vedere l'esempio di codice nella sezione ID richiesta server.

Se non si verificano problemi nel client, è necessario analizzare potenziali problemi di rete, ad esempio la perdita di pacchetti. È possibile usare strumenti come Wireshark per analizzare i problemi di rete.

Per altre informazioni sull'uso di Wireshark per risolvere i problemi di rete, vedere Appendice 2: Uso di Wireshark per acquisire il traffico di rete.

Le metriche mostrano un'elevata averageServerLatency

Nel caso di averageServerLatency elevata per le richieste di download dei BLOB, è necessario usare i log di registrazione archiviazione per verificare se sono presenti richieste ripetute per lo stesso BLOB (o set di BLOB). Per le richieste di caricamento BLOB, è consigliabile esaminare le dimensioni del blocco che il client sta usando( ad esempio, blocchi di dimensioni inferiori a 64 K possono comportare sovraccarichi a meno che le letture non siano anche in blocchi inferiori a 64 K) e se più client caricano blocchi nello stesso BLOB in parallelo. È anche consigliabile controllare le metriche al minuto per individuare i picchi nel numero di richieste che comportano il superamento degli obiettivi di scalabilità al secondo. Per altre informazioni, vedere Metrics show an increase in PercentTimeoutError.For more information, see Metrics show an increase in PercentTimeoutError.

Se viene visualizzata un'elevata averageServerLatency per le richieste di download dei BLOB quando sono presenti richieste ripetute per lo stesso BLOB o set di BLOB, prendere in considerazione la memorizzazione nella cache di questi BLOB usando Cache di Azure o la rete cdN (Content Delivery Network) di Azure. Per le richieste di caricamento, è possibile migliorare la velocità effettiva usando dimensioni di blocco maggiori. Per le query nelle tabelle, è anche possibile implementare la memorizzazione nella cache lato client nei client che eseguono le stesse operazioni di query e in cui i dati non cambiano di frequente.

I valori AverageServerLatency elevati possono anche essere un sintomo di tabelle o query progettate in modo non corretto che comportano operazioni di analisi o che seguono l'anti-pattern di accodamento/anteposizione. Per altre informazioni, vedere Metriche che mostrano un aumento di PercentThrottlingError.

Nota

È possibile trovare un elenco di controllo completo per le prestazioni qui: Archiviazione di Microsoft Azure Elenco di controllo per prestazioni e scalabilità.

Si verificano ritardi imprevisti nel recapito dei messaggi in una coda

Se si verifica un ritardo tra il momento in cui un'applicazione aggiunge un messaggio a una coda e il tempo in cui diventa disponibile per la lettura dalla coda, seguire questa procedura per diagnosticare il problema:

  • Verificare che l'applicazione stia aggiungendo correttamente i messaggi alla coda. Verificare che l'applicazione non stia ritentando il AddMessage metodo più volte prima dell'esito positivo. I log della libreria client di archiviazione mostreranno eventuali tentativi ripetuti di operazioni di archiviazione.
  • Verificare che non vi sia alcuna differenza di clock tra il ruolo di lavoro che aggiunge il messaggio alla coda e il ruolo di lavoro che legge il messaggio dalla coda. Un'asimmetria dell'orologio viene visualizzata come se si verificasse un ritardo nell'elaborazione.
  • Controllare se il ruolo di lavoro che legge i messaggi dalla coda ha esito negativo. Se un client di coda chiama il GetMessage metodo ma non riesce a rispondere con un riconoscimento, il messaggio rimarrà invisibile nella coda fino alla scadenza del invisibilityTimeout periodo. A questo punto, il messaggio diventa nuovamente disponibile per l'elaborazione.
  • Controllare se la lunghezza della coda sta crescendo nel tempo. Ciò può verificarsi se non sono disponibili ruoli di lavoro sufficienti per elaborare tutti i messaggi che altri ruoli di lavoro stanno inserendo nella coda. Controllare inoltre le metriche per verificare se le richieste di eliminazione hanno esito negativo e il conteggio della dequeue sui messaggi, che potrebbe indicare tentativi ripetuti non riusciti di eliminare il messaggio.
  • Esaminare i log di registrazione archiviazione per individuare eventuali operazioni di coda con valori E2ELatency e ServerLatency superiori al previsto per un periodo di tempo più lungo del solito.

Le metriche mostrano un aumento di PercentThrottlingError

Gli errori di limitazione si verificano quando si superano le destinazioni di scalabilità di un servizio di archiviazione. Il servizio di archiviazione limita per garantire che nessun singolo client o tenant possa usare il servizio a spese di altri. Per altre informazioni, vedere Obiettivi di scalabilità e prestazioni per gli account di archiviazione standard per informazioni dettagliate sugli obiettivi di scalabilità per gli account di archiviazione e sugli obiettivi di prestazioni per le partizioni all'interno degli account di archiviazione.

Se la metrica PercentThrottlingError mostra un aumento della percentuale di richieste che hanno esito negativo con un errore di limitazione, è necessario analizzare uno dei due scenari seguenti:

Un aumento di PercentThrottlingError si verifica spesso contemporaneamente a un aumento del numero di richieste di archiviazione o quando si sta inizialmente testando il carico dell'applicazione. Questo può anche manifestarsi nel client come messaggi di stato HTTP "503 Server Occupato" o "Timeout operazione 500" dalle operazioni di archiviazione.

Aumento temporaneo di PercentThrottlingError

Se si riscontrano picchi nel valore di PercentThrottlingError che coincidono con periodi di attività elevata per l'applicazione, è possibile implementare una strategia di back-off esponenziale (non lineare) per i tentativi nel client. I tentativi di back-off riducono il carico immediato sulla partizione e consentono all'applicazione di eliminare i picchi di traffico. Per altre informazioni su come implementare i criteri di ripetizione dei tentativi usando la libreria client di archiviazione, vedere lo spazio dei nomi Microsoft.Azure.Storage.RetryPolicies.

Nota

È anche possibile che si verifichino picchi nel valore di PercentThrottlingError che non coincidono con i periodi di attività elevata per l'applicazione. La causa più probabile è lo spostamento delle partizioni da parte del servizio di archiviazione per migliorare il bilanciamento del carico.

Aumento permanente di PercentThrottlingError

Se viene visualizzato un valore costantemente elevato per PercentThrottlingError in seguito a un aumento permanente dei volumi delle transazioni o quando si eseguono i test di carico iniziali nell'applicazione, è necessario valutare il modo in cui l'applicazione usa le partizioni di archiviazione e se sta raggiungendo gli obiettivi di scalabilità per un account di archiviazione. Ad esempio, se vengono visualizzati errori di limitazione in una coda (che viene conteggiata come una singola partizione), è consigliabile usare code aggiuntive per distribuire le transazioni tra più partizioni. Se vengono visualizzati errori di limitazione in una tabella, è necessario prendere in considerazione l'uso di uno schema di partizionamento diverso per distribuire le transazioni tra più partizioni usando un intervallo più ampio di valori della chiave di partizione. Una causa comune di questo problema è l'anti-pattern anteponi/accodamento in cui si seleziona la data come chiave di partizione e quindi tutti i dati di un determinato giorno vengono scritti in una partizione: in caso di caricamento, questo può causare un collo di bottiglia di scrittura. Considerare una progettazione di partizionamento diversa o valutare se l'uso dell'archiviazione BLOB potrebbe essere una soluzione migliore. Controllare anche se la limitazione si verifica a causa di picchi nel traffico e analizzare i modi per smussare il modello di richieste.

Se si distribuiscono le transazioni tra più partizioni, è comunque necessario tenere presente i limiti di scalabilità impostati per l'account di archiviazione. Ad esempio, se sono state usate dieci code, ognuna delle quali elabora al massimo 2.000 messaggi 1KB al secondo, si raggiungerà il limite complessivo di 20.000 messaggi al secondo per l'account di archiviazione. Se è necessario elaborare più di 20.000 entità al secondo, è consigliabile usare più account di archiviazione. È anche necessario tenere presente che le dimensioni delle richieste e delle entità influiscono su quando il servizio di archiviazione limita i client. Se si dispone di richieste ed entità più grandi, è possibile che si venga limitati prima.

La progettazione di query inefficiente può anche causare il raggiungere i limiti di scalabilità per le partizioni di tabella. Ad esempio, una query con un filtro che seleziona solo l'1% delle entità in una partizione ma che analizza tutte le entità in una partizione dovrà accedere a ogni entità. Ogni entità letta verrà conteggiata per il numero totale di transazioni in tale partizione; pertanto, è possibile raggiungere facilmente gli obiettivi di scalabilità.

Nota

Il test delle prestazioni dovrebbe rivelare qualsiasi progettazione di query inefficiente nell'applicazione.

Le metriche mostrano un aumento di PercentTimeoutError

Le metriche mostrano un aumento di PercentTimeoutError per uno dei servizi di archiviazione. Allo stesso tempo, il client riceve un volume elevato di messaggi di stato HTTP "Timeout operazione 500" dalle operazioni di archiviazione.

Nota

È possibile che vengano visualizzati temporaneamente errori di timeout quando il servizio di archiviazione bilancia il carico delle richieste spostando una partizione in un nuovo server.

La metrica PercentTimeoutError è un'aggregazione delle metriche seguenti: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError e SASServerTimeoutError.

I timeout del server sono causati da un errore nel server. I timeout client si verificano perché un'operazione nel server ha superato il timeout specificato dal client; Ad esempio, un client che usa la libreria client di archiviazione può impostare un timeout per un'operazione usando la ServerTimeout proprietà della QueueRequestOptions classe .

I timeout del server indicano un problema con il servizio di archiviazione che richiede ulteriori indagini. È possibile usare le metriche per verificare se si raggiungono i limiti di scalabilità per il servizio e per identificare eventuali picchi di traffico che potrebbero causare questo problema. Se il problema è intermittente, potrebbe essere dovuto all'attività di bilanciamento del carico nel servizio. Se il problema è persistente e non è causato dal raggiungimento dei limiti di scalabilità del servizio da parte dell'applicazione, è necessario generare un problema di supporto. Per i timeout client, è necessario decidere se il timeout è impostato su un valore appropriato nel client e modificare il valore di timeout impostato nel client oppure esaminare come migliorare le prestazioni delle operazioni nel servizio di archiviazione, ad esempio ottimizzando le query di tabella o riducendo le dimensioni dei messaggi.

Le metriche mostrano un aumento di PercentNetworkError

Le metriche mostrano un aumento di PercentNetworkError per uno dei servizi di archiviazione. La metrica PercentNetworkError è un'aggregazione delle metriche seguenti: NetworkError, AnonymousNetworkError e SASNetworkError. Questi si verificano quando il servizio di archiviazione rileva un errore di rete quando il client effettua una richiesta di archiviazione.

La causa più comune di questo errore è la disconnessione di un client prima della scadenza di un timeout nel servizio di archiviazione. Esaminare il codice nel client per comprendere perché e quando il client si disconnette dal servizio di archiviazione. È anche possibile usare Wireshark o Tcping per analizzare i problemi di connettività di rete dal client. Questi strumenti sono descritti nelle Appendici.

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). Se la causa è una chiave sas scaduta, non verranno visualizzate voci nei dati del log di registrazione archiviazione sul lato server. 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 portare a una firma di accesso condiviso apparentemente in scadenza prima del previsto.
  • Il parametro version nella chiave sas (ad esempio, sv=2015-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

Negli scenari in cui il client sta tentando di leggere, aggiornare o eliminare dati in un servizio di archiviazione, in genere è facile identificare nei log sul lato server 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. Nel log di registrazione archiviazione sul lato server le colonne operation-type e requested-object-key mostrano 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 ottenere informazioni più dettagliate su 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. Si noti che questa operazione include una HEAD richiesta per verificare l'esistenza del contenitore.
e2d06d78... CreateIfNotExists per creare il contenitore BLOB. Si noti che 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 dell'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 = &quot;0x8D14D2DC63D059B&quot;.
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. Allo stesso tempo, verrà visualizzato anche un valore diverso da zero per SASAuthorizationError nelle metriche.

La tabella seguente mostra un messaggio di log sul lato server di esempio dal file di log di registrazione archiviazione:

Name Valore
Ora di inizio della richiesta 2014-05-30T06:17:48.4473697Z
Tipo di operazione GetBlobProperties
Stato della richiesta SASAuthorizationError
Codice di stato HTTP 404
Tipo di autenticazione Sas
Tipo di servizio Blob
URL richiesta https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt
  ?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&; api-version=2014-02-14
Intestazione ID richiesta <Intestazione ID richiesta>
ID richiesta client <ID richiesta client>

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:

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 di archiviazione lato server eseguendo una ricerca nella request-id-header colonna nel file 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)

La tabella seguente mostra un'estrazione dal log sul lato server per due operazioni client: DeleteIfExists seguita immediatamente dall'uso CreateIfNotExists dello stesso nome del contenitore BLOB. Ogni operazione client genera due richieste inviate al server, prima una GetContainerProperties richiesta per verificare se il contenitore esiste, seguito dalla DeleteContainer richiesta o CreateContainer .

Data e ora Operazione Risultato Nome del contenitore ID richiesta client
05:10:13.7167225 GetContainerProperties 200 mmcont c9f52c89-...
05:10:13.8167325 DeleteContainer 202 mmcont c9f52c89-...
05:10:13.8987407 GetContainerProperties 404 mmcont bc881924-...
05:10:14.2147723 CreateContainer 409 mmcont bc881924-...

Il codice nell'applicazione client elimina e quindi ricrea immediatamente un contenitore BLOB con lo stesso nome: il CreateIfNotExists metodo (ID richiesta client bc881924-...) ha esito negativo con l'errore HTTP 409 (Conflitto). Quando un client elimina contenitori BLOB, tabelle o code, è necessario un breve periodo prima che il nome diventi nuovamente disponibile.

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

La metrica PercentSuccess 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 PercentSuccess . Nei file di log di archiviazione sul lato server queste operazioni vengono registrate con lo stato della transazione ClientOtherErrors.

È importante notare che 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 GET richiesta 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.

Le metriche di capacità mostrano un aumento imprevisto dell'utilizzo della capacità di archiviazione

Se si verificano modifiche improvvise e impreviste nell'utilizzo della capacità nell'account di archiviazione, è possibile analizzare i motivi esaminando prima le metriche di disponibilità; Ad esempio, un aumento del numero di richieste di eliminazione non riuscite potrebbe comportare un aumento della quantità di archiviazione BLOB in uso come operazioni di pulizia specifiche dell'applicazione che ci si potrebbe aspettare di liberare spazio potrebbe non funzionare come previsto (ad esempio, perché i token di firma di accesso condiviso usati per liberare spazio sono scaduti).

Il problema deriva dall'uso dell'emulatore di archiviazione per lo sviluppo o il test

In genere si usa l'emulatore di archiviazione durante lo sviluppo e il test per evitare il requisito per un account di archiviazione di Azure. I problemi comuni che possono verificarsi quando si usa l'emulatore di archiviazione sono:

La funzionalità "X" non funziona nell'emulatore di archiviazione

L'emulatore di archiviazione non supporta tutte le funzionalità dei servizi di archiviazione di Azure, ad esempio il servizio file. Per altre informazioni, vedere Usare l'emulatore di archiviazione di Azure per lo sviluppo e i test.

Per le funzionalità non supportate dall'emulatore di archiviazione, usare il servizio di archiviazione di Azure nel cloud.

Errore "Il valore per una delle intestazioni HTTP non è nel formato corretto" quando si usa l'emulatore di archiviazione

Si sta testando l'applicazione che usa la libreria client di archiviazione sull'emulatore di archiviazione locale e le chiamate al metodo, ad CreateIfNotExists esempio fail, con il messaggio di errore "Il valore per una delle intestazioni HTTP non è nel formato corretto". Ciò indica che la versione dell'emulatore di archiviazione in uso non supporta la versione della libreria client di archiviazione in uso. La libreria client di archiviazione aggiunge l'intestazione x-ms-version a tutte le richieste eseguite. Se l'emulatore di archiviazione non riconosce il valore nell'intestazione x-ms-version , rifiuta la richiesta.

È possibile usare i log client della libreria di archiviazione per visualizzare il valore dell'oggetto x-ms-version header che sta inviando. È anche possibile visualizzare il valore di x-ms-version header se si usa Fiddler per tracciare le richieste dall'applicazione client.

Questo scenario si verifica in genere se si installa e si usa la versione più recente della libreria client di archiviazione senza aggiornare l'emulatore di archiviazione. È consigliabile installare la versione più recente dell'emulatore di archiviazione o usare l'archiviazione cloud anziché l'emulatore per lo sviluppo e il test.

L'esecuzione dell'emulatore di archiviazione richiede privilegi amministrativi

Quando si esegue l'emulatore di archiviazione, vengono richieste le credenziali di amministratore. Ciò si verifica solo quando si inizializza l'emulatore di archiviazione per la prima volta. Dopo aver inizializzato l'emulatore di archiviazione, non sono necessari privilegi amministrativi per eseguirlo di nuovo.

Per altre informazioni, vedere Usare l'emulatore di archiviazione di Azure per lo sviluppo e i test. È anche possibile inizializzare l'emulatore di archiviazione in Visual Studio, che richiederà anche privilegi amministrativi.

Si verificano problemi durante l'installazione di Azure SDK per .NET

Quando si tenta di installare l'SDK, non riesce durante il tentativo di installare l'emulatore di archiviazione nel computer locale. Il log di installazione contiene uno dei messaggi seguenti:

  • CAQuietExec: Errore: Impossibile accedere all'istanza di SQL
  • CAQuietExec: Errore: Impossibile creare il database

La causa è un problema con l'installazione di LocalDB esistente. Per impostazione predefinita, l'emulatore di archiviazione usa LocalDB per rendere persistenti i dati quando simula i servizi di archiviazione di Azure. È possibile reimpostare l'istanza di LocalDB eseguendo i comandi seguenti in una finestra del prompt dei comandi prima di provare a installare l'SDK.

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

Il delete comando rimuove eventuali file di database precedenti dalle installazioni precedenti dell'emulatore di archiviazione.

Si è verificato un problema diverso con un servizio di archiviazione

Se le sezioni precedenti per la risoluzione dei problemi non includono il problema riscontrato con un servizio di archiviazione, è consigliabile adottare l'approccio seguente per la diagnosi e la risoluzione del problema.

  • Controllare le metriche per verificare se sono presenti modifiche rispetto al comportamento previsto della baseline. Dalle metriche è possibile determinare se il problema è temporaneo o permanente e quali operazioni di archiviazione interessano.
  • È possibile usare le informazioni sulle metriche per eseguire ricerche nei dati di log sul lato server per ottenere informazioni più dettagliate sugli eventuali errori che si verificano. Queste informazioni possono essere utili per risolvere il problema.
  • Se le informazioni nei log sul lato server non sono sufficienti per risolvere correttamente il problema, è possibile usare i log lato client della libreria client di archiviazione per analizzare il comportamento dell'applicazione client e degli strumenti come Fiddler e Wireshark per analizzare la rete.

Per altre informazioni sull'uso di Fiddler, vedere Appendice 1: Uso di Fiddler per acquisire il traffico HTTP e HTTPS.

Per altre informazioni sull'uso di Wireshark, vedere Appendice 2: Uso di Wireshark per acquisire il traffico di rete.

Appendici

Le appendici descrivono diversi strumenti che potrebbero risultare utili durante la diagnosi e la risoluzione dei problemi relativi ad Archiviazione di Azure e ad altri servizi. Questi strumenti non fanno parte di Archiviazione di Azure e alcuni sono prodotti di terze parti. Di conseguenza, gli strumenti descritti in queste appendici non sono coperti da alcun contratto di supporto disponibile con Microsoft Azure o Archiviazione di Azure. Pertanto, come parte del processo di valutazione, è necessario esaminare le opzioni di licenza e supporto disponibili dai provider di questi strumenti.

Appendice 1: Uso di Fiddler per acquisire il traffico HTTP e HTTPS

Fiddler è uno strumento utile per analizzare il traffico HTTP e HTTPS tra l'applicazione client e il servizio di archiviazione di Azure in uso.

Nota

Fiddler può decodificare il traffico HTTPS. È consigliabile leggere attentamente la documentazione di Fiddler per comprendere in che modo esegue questa operazione e le relative implicazioni per la sicurezza.

Questa appendice offre una breve procedura dettagliata su come configurare Fiddler per acquisire il traffico tra il computer locale in cui è stato installato Fiddler e i servizi di archiviazione di Azure.

Dopo aver avviato Fiddler, inizierà ad acquisire il traffico HTTP e HTTPS nel computer locale. Di seguito sono riportati alcuni comandi utili per controllare Fiddler:

  • Arrestare e avviare l'acquisizione del traffico. Nel menu principale passare a File e quindi selezionare Acquisisci traffico per attivare e disattivare l'acquisizione.
  • Salvare i dati del traffico acquisiti. Nel menu principale passare a File, selezionare Salva e quindi selezionare Tutte le sessioni. In questo modo è possibile salvare il traffico in un file di archivio sessione. È possibile ricaricare un archivio sessioni in un secondo momento per l'analisi o inviarlo se richiesto al supporto tecnico Microsoft.

Per limitare la quantità di traffico acquisita da Fiddler, è possibile usare i filtri configurati nella scheda Filtri . Lo screenshot seguente mostra un filtro che acquisisce solo il traffico inviato all'endpoint contosoemaildist.table.core.windows.net di archiviazione:

Screenshot che mostra un filtro che acquisisce solo il traffico inviato all'endpoint di archiviazione contosoemaildist.table.core.windows.net.

Appendice 2: Uso di Wireshark per acquisire il traffico di rete

Wireshark è un analizzatore di protocollo di rete che consente di visualizzare informazioni dettagliate sui pacchetti per un'ampia gamma di protocolli di rete.

La procedura seguente illustra come acquisire informazioni dettagliate sui pacchetti per il traffico dal computer locale in cui è stato installato Wireshark al servizio tabelle nell'account di archiviazione di Azure.

  1. Avviare Wireshark nel computer locale.

  2. Nella sezione Start selezionare l'interfaccia di rete locale o le interfacce connesse a Internet.

  3. Selezionare Opzioni di acquisizione.

  4. Aggiungere un filtro alla casella di testo Capture Filter (Filtro acquisizione ). Ad esempio, host contosoemaildist.table.core.windows.net configurerà Wireshark per acquisire solo i pacchetti inviati da o verso l'endpoint del servizio tabelle nell'account di archiviazione contosoemaildist . Vedere l'elenco completo dei filtri di acquisizione.

    Screenshot che mostra come aggiungere un filtro alla casella di testo Capture Filter (Acquisisci filtro).

  5. Selezionare Start. Wireshark acquisirà ora tutti i pacchetti inviati da o verso l'endpoint del servizio tabelle quando si usa l'applicazione client nel computer locale.

  6. Al termine, selezionare Arresta acquisizione> nel menu principale.

  7. Per salvare i dati acquisiti in un file Wireshark Capture, selezionare Salva file> dal menu principale.

WireShark evidenzia eventuali errori presenti nella finestra packetlist . È anche possibile usare la finestra Informazioni esperti (selezionare Analizza informazioni>esperti) per visualizzare un riepilogo di errori e avvisi.

Screenshot che mostra la finestra Expert Info in cui è possibile visualizzare un riepilogo di errori e avvisi.

È anche possibile scegliere di visualizzare i dati TCP come vengono visualizzati dal livello applicazione facendo clic con il pulsante destro del mouse sui dati TCP e selezionando Segui tcp Stream. Questa operazione è utile se il dump è stato acquisito senza un filtro di acquisizione. Per altre informazioni, vedere Seguire i flussi TCP.

Screenshot che mostra come visualizzare i dati TCP quando vengono visualizzati dal livello applicazione.

Nota

Per altre informazioni sull'uso di Wireshark, vedere la Guida per gli utenti di Wireshark.

Appendice 4: Uso di Excel per visualizzare le metriche e i dati di log

Molti strumenti consentono di scaricare i dati delle metriche di archiviazione dall'archiviazione tabelle di Azure in un formato delimitato che semplifica il caricamento dei dati in Excel per la visualizzazione e l'analisi. I dati di registrazione archiviazione da Archiviazione BLOB di Azure sono già in un formato delimitato che è possibile caricare in Excel. Tuttavia, è necessario aggiungere intestazioni di colonna appropriate in base alle informazioni disponibili in formato di log Analisi archiviazione e schema di tabella delle metriche Analisi archiviazione.

Per importare i dati di registrazione archiviazione in Excel dopo il download dall'archiviazione BLOB:

  • Nel menu Dati selezionare Da testo.
  • Passare al file di log che si vuole visualizzare e selezionare Importa.
  • Nel passaggio 1 dell'Importazione guidata testo selezionare Delimitato.

Nel passaggio 1 dell'Importazione guidata testo selezionare Punto e virgola come unico delimitatore e scegliere virgolette doppie come qualificatore Testo. Selezionare quindi Fine e scegliere dove inserire i dati nella cartella di lavoro.

Appendice 5: Monitoraggio con Application Insights per Azure DevOps

È anche possibile usare la funzionalità Application Insights per Azure DevOps come parte del monitoraggio delle prestazioni e della disponibilità. Questo strumento può:

  • Assicurarsi che il servizio Web sia disponibile e reattivo. Se l'app è un sito Web o un'app per dispositivi che usa un servizio Web, può testare l'URL ogni pochi minuti da località in tutto il mondo e segnalare se si è verificato un problema.
  • Diagnosticare rapidamente eventuali problemi di prestazioni o eccezioni nel servizio Web. Scoprire se la CPU o altre risorse vengono estese, ottenere le tracce dello stack dalle eccezioni e cercare facilmente le tracce di log. Se le prestazioni dell'app diminuiscono al di sotto dei limiti accettabili, Microsoft può inviare un messaggio di posta elettronica. È possibile monitorare i servizi Web .NET e Java.

Per altre informazioni , vedere Informazioni su Application Insights.

Passaggi successivi

Per altre informazioni sull'analisi in Archiviazione di Azure, vedere queste risorse:

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

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.