Monitoraggio, diagnosi e risoluzione dei problemi di Archiviazione di Microsoft Azure (versione classica)
Questa guida illustra come usare funzionalità come Archiviazione di Azure Analytics, la registrazione sul lato client nella libreria client Archiviazione di Azure e altri strumenti di terze parti per identificare, diagnosticare e risolvere i problemi correlati Archiviazione di Azure.
La guida è destinata in particolare agli sviluppatori dei servizi online che usano i servizi di archiviazione di Azure e ai professionisti IT responsabili della gestione di tali servizi online. Gli obiettivi della guida sono:
- Consentire all'utente di mantenere l'integrità e le prestazioni degli account di archiviazione di Azure.
- Fornire all'utente le procedure e gli strumenti necessari per decidere se un problema riscontrato in un'applicazione è correlato ad Archiviazione di Azure.
- Fornire all'utente indicazioni pratiche per la risoluzione dei problemi correlati all'Archiviazione di Azure.
Note
Questo articolo si basa sull'uso di metriche e log Analisi archiviazione definiti metriche e log classici. È consigliabile usare metriche e log 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 possono essere più complesse rispetto agli ambienti tradizionali. Le applicazioni possono essere distribuite in un'infrastruttura PaaS o IaaS, in locale, su un dispositivo mobile o in una combinazione di questi tipi di 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 documenti.
Per gestire correttamente tali applicazioni, è necessario monitorarle in modo proattivo e comprendere come diagnosticare e risolvere tutti gli aspetti di tali applicazioni e le relative tecnologie dipendenti. In qualità di utente di servizi di Archiviazione di Azure, è consigliabile monitorare continuamente i servizi di archiviazione usati dall'applicazione per eventuali modifiche impreviste nel comportamento (ad esempio tempi di risposta più lenti del solito) e usare la registrazione per raccogliere dati più dettagliati e analizzare un problema in modo approfondito. Le informazioni di diagnostica ottenute dal monitoraggio e dalla registrazione consentono di determinare la causa radice del problema riscontrato dall'applicazione. È possibile quindi identificare il problema e determinare le misure appropriate per correggerlo. 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. Include funzionalità che consentono di semplificare le attività di monitoraggio, diagnostica e risoluzione dei problemi di archiviazione nelle applicazioni basate su cloud.
Organizzazione di questa guida
La sezione Monitoraggio del servizio di archiviazione descrive come monitorare l'integrità e le prestazioni dei servizi Archiviazione di Azure usando 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 Archiviazione di Azure Analytics (registrazione archiviazione). Descrive anche come abilitare la registrazione 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 sulla risoluzione dei problemi fornisce indicazioni sulla risoluzione dei problemi relativi ad 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
Per chi ha familiarità con il monitoraggio delle prestazioni di Windows, le metriche di archiviazione di Azure corrispondono ai contatori di Windows Performance Monitor. 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 al servizio o la percentuale di richieste riuscite al servizio. Per l'elenco completo delle metriche disponibili, vedere Schema di tabella della metrica di Analisi di archiviazione. È possibile specificare se si vuole che il servizio di archiviazione raccolga e aggreghi le metriche ogni ora o ogni minuto. Per altre informazioni sulle modalità di abilitazione delle metriche e sul monitoraggio degli account di archiviazione, vedere Abilitazione di Metriche di archiviazione e visualizzazione dei dati di metrica.
È possibile scegliere quali metriche orarie visualizzare nel portale di Azure e configurare le regole che inviano una notifica agli amministratori ogni volta che una metrica oraria supera una soglia particolare. Per altre informazioni, vedere Ricevere notifiche di avviso.
È consigliabile consultare Monitoraggio di Azure per Archiviazione (anteprima). È una funzionalità di Monitoraggio di Azure che offre un monitoraggio completo degli account Archiviazione di Azure offrendo una visualizzazione unificata delle prestazioni, della capacità e della disponibilità dei servizi Archiviazione di Azure. Non richiede l'abilitazione o la configurazione di alcun elemento e è possibile visualizzare immediatamente queste metriche dai grafici interattivi predefiniti e da altre visualizzazioni incluse.
Il servizio di archiviazione tenta di raccogliere le metriche, ma potrebbe non registrare tutte le operazioni di archiviazione.
Nel portale di Azure sono visualizzate metriche come la disponibilità, le richieste totali e i numeri di latenza media per un account di archiviazione. È stata configurata anche 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 riuscita del servizio tabelle inferiore al 100%. Per altre informazioni, vedere la sezione Metriche che mostra un valore percentsuccess basso o le voci del log di analisi hanno operazioni con stato della transazione clientOtherErrors sezione.
È consigliabile monitorare continuamente le applicazioni Di Azure per assicurarsi che siano integre e funzionino come previsto:
- Definizione di alcune metriche di base per l'applicazione che consentirà 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, in molti casi, sono specifici dell'applicazione e devono essere stabiliti quando si esegue il test delle prestazioni dell'applicazione.
- Registrazione delle metriche dei minuti e uso di tali metriche per monitorare attivamente gli errori imprevisti e le anomalie, ad esempio picchi nei conteggi degli errori o nelle frequenze delle richieste.
- Registrare metriche orarie e usarle per monitorare valori medi, come la media dei conteggi degli errori e della frequenza delle richieste.
- Analisi dei potenziali problemi tramite gli strumenti di diagnostica, come descritto più avanti nella sezione Diagnosi dei problemi di archiviazione.
I grafici della figura seguente illustrano in che modo il calcolo della media delle metriche orarie può nascondere picchi di attività. Le metriche orarie sembrano indicare una frequenza costante delle richieste, mentre le metriche al minuto rivelano le fluttuazioni che si verificano effettivamente.
La parte rimanente di questa sezione descrive le metriche che è necessario monitorare e perché.
Monitoraggio dello stato del servizio
Usare il portale di Azure per visualizzare lo stato del servizio di archiviazione (e altri servizi di Azure) in tutte le aree Azure del 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 sugli incidenti che influiscono sui vari servizi di Azure.
Note
queste informazioni in precedenza erano disponibili, insieme ai dati cronologici, sul dashboard dei servizi di Azure. Per altre informazioni su Application Insights per Azure DevOps, vedere Appendice 5: Monitoraggio con Application Insights per Azure DevOps.
Monitoraggio della capacità
Le metriche di archiviazione archiviano solo le metriche di capacità per il servizio BLOB perché i BLOB in genere rappresentano 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 di analisi (valore analytics
). Ogni entità archiviata contiene informazioni sulla quantità di spazio di archiviazione usato (Capacity
misurato in byte) e sul numero corrente di contenitori () e BLOB (ContainerCount
ObjectCount
) in uso nell'account di archiviazione. Per altre informazioni sulle metriche della capacità archiviate nella $MetricsCapacityBlob
tabella, vedere Analisi archiviazione Schema di tabella delle metriche.
Note
È consigliabile monitorare questi valori per un avviso anticipato che si sta raggiungendo i limiti di capacità dell'account di archiviazione. Nella 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 i BLOB, vedere il post di blog Informazioni sulla fatturazione 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
, $MetricsMinutePrimaryTransactionsTable
$MetricsHourPrimaryTransactionsQueue
$MetricsHourPrimaryTransactionsTable
$MetricsMinutePrimaryTransactionsBlob
$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).
Eventuali valori inferiori al 100% indicano che alcune richieste di archiviazione hanno esito negativo. È possibile vedere 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. È consigliabile prevedere un calo temporaneo inferiore al Availability
100% per motivi come i timeout temporanei del server 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
.
Nella portale di Azure è possibile aggiungere regole di avviso per notificare se Availability
un servizio scende al di sotto di una soglia specificata.
La sezione Indicazioni sulla risoluzione dei problemi di questa guida descrive alcuni problemi comuni relativi alla disponibilità del servizio di archiviazione.
Monitoraggio delle prestazioni
Per monitorare le prestazioni dei servizi di archiviazione è possibile usare le seguenti metriche estratte dalle tabelle delle metriche orarie e al minuto.
- I valori nelle
AverageE2ELatency
colonne eAverageServerLatency
indicano il tempo medio usata dal servizio di archiviazione o dal tipo di operazione API 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 (pertanto include la latenza di rete quando la richiesta raggiunge il servizio di archiviazione);AverageServerLatency
è una misura del tempo di elaborazione e quindi 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 eTotalEgress
mostrano la quantità totale di dati, in byte, in ingresso e uscita 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 l'analisi.
Nella 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 sulla risoluzione dei problemi di questa guida descrive alcuni problemi comuni relativi alle prestazioni del servizio di archiviazione.
Diagnosi dei problemi di archiviazione
Esistono alcuni sintomi che indicano la presenza di un problema dell'applicazione, tra cui:
- Errore grave che causa l'arresto anomalo o l'arresto anomalo dell'applicazione.
- Modifiche significative dai valori di base nelle metriche monitorate come descritto nella sezione precedente Monitoraggio del servizio di archiviazione.
- Segnalazione da parte degli utenti dell'applicazione in merito al fatto che una determinata operazione non viene completata come previsto o che non è possibile usare una funzionalità.
- Errori generati all'interno dell'applicazione che appaiono nei file di log o vengono segnalati con altri metodi.
Normalmente i problemi correlati ai servizio di archiviazione di Azure rientrano in una delle seguenti quattro grandi categorie:
- L'applicazione presenta un problema di prestazioni, segnalato dagli utenti o rivelato dalle modifiche apportate alle metriche delle prestazioni.
- Si è verificato un problema con l'infrastruttura dell'Archiviazione di Azure in una o più aree.
- L'applicazione rileva 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; potrebbero verificarsi alcuni problemi correlati in modo specifico all'utilizzo dell'emulatore di archiviazione.
Le sezioni seguenti illustrano le procedure da adottare per la diagnosi e la risoluzione dei problemi in ciascuna delle quattro categorie. La sezione Indicazioni sulla risoluzione dei problemi più avanti in questa guida fornisce altri dettagli per alcuni problemi comuni che possono verificarsi.
Problemi di stato del servizio
I problemi di stato del servizio di solito sono al di fuori del controllo dell'utente. Il portale di Azure fornisce informazioni su eventuali problemi in corso con i servizi di Azure, inclusi i servizi di archiviazione. Se si è scelta un'archiviazione con ridondanza geografica e accesso in lettura durante la creazione dell'account di archiviazione, nel caso in cui i dati diventino non disponibili nella posizione primaria, l'applicazione può passare temporaneamente alla copia di sola lettura nella posizione secondaria. Per leggere dal database secondario, l'applicazione deve essere in grado di passare da un percorso di archiviazione primario a quello secondario e poter lavorare in una modalità di funzionalità ridotta con dati di sola lettura. Le librerie client del servizio di archiviazione Azure consentono di definire criteri di ripetizione per leggere i dati da un'archiviazione secondaria nel caso in cui quella primaria non funzioni. L'applicazione deve inoltre essere in grado di stabilire se i dati nella posizione secondaria risultano coerenti. Per altre informazioni, vedere il post del blog Opzioni di ridondanza di Archiviazione di Azure e Archiviazione con ridondanza geografica e accesso in lettura.
Problemi di prestazioni
Le prestazioni di un'applicazione possono essere soggettive, soprattutto dal punto di vista dell'utente. È quindi importante avere a disposizione metriche di base che consentano di localizzare e identificare i problemi di prestazioni. Sono molti i fattori che possono influire sulle prestazioni di un servizio di archiviazione Azure dal punto di vista dell'applicazione client. Questi fattori possono operare nel servizio di archiviazione, nel client o nell'infrastruttura di rete; pertanto, è importante avere una strategia per identificare l'origine del problema di prestazioni.
Dopo aver identificato l'origine probabile della causa del problema in base alle metriche, è possibile utilizzare i file di log per trovare informazioni dettagliate che consentano di diagnosticare e risolvere meglio il problema.
La sezione Indicazioni sulla risoluzione dei problemi più avanti in questa guida fornisce altre informazioni su alcuni problemi comuni relativi alle prestazioni che possono verificarsi.
Diagnostica degli errori
Gli utenti dell'applicazione possono notificare gli errori segnalati dall'applicazione client. Le metriche di archiviazione registrano anche il numero di tipi di errore diversi dai servizi di archiviazione, ad esempio NetworkError, ClientTimeoutError o AuthorizationError. Benché Metriche di archiviazione registrino solo i conteggi dei diversi tipi di errore, è possibile ottenere più dettagli sulle singole richieste esaminando i file di log di lato server, lato client e rete. In genere, il codice di stato HTTP restituito dal servizio di archiviazione fornisce un'indicazione del motivo dell'esito negativo della richiesta.
Note
Tenere presente che è consigliabile visualizzare alcuni errori intermittenti, ad esempio errori dovuti a condizioni di rete temporanee o errori dell'applicazione.
Le seguenti risorse sono utili per l'interpretazione dei codici di errore e di stato correlati all'archiviazione:
- Codici di errore comuni dell'API REST
- Codici di errore del servizio BLOB
- Codici di errore del servizio di accodamento
- Codici di errore del servizio tabelle
- Codici di errore del servizio file
Problemi dell'emulatore di archiviazione
L'SDK di Azure include un emulatore di archiviazione che può essere eseguito su 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 i servizi di archiviazione di Azure senza la necessità di una sottoscrizione di Azure e di un account di archiviazione di Azure.
La sezione Indicazioni sulla risoluzione dei problemi di questa guida descrive alcuni problemi comuni riscontrati con l'emulatore di archiviazione.
Strumenti di registrazione dell'archiviazione
La registrazione dell'archiviazione consente di registrare sul lato server le richieste di archiviazione presenti nell'account di archiviazione di Azure. Per altre informazioni sulle modalità di abilitazione della registrazione lato server e dell'accesso ai dati registrati, vedere Abilitazione di Registrazione archiviazione e accesso ai dati di log.
Storage Client Library per .NET consente di raccogliere i dati della registrazione lato client correlati alle operazioni di archiviazione eseguite dall'applicazione. Per altre informazioni, vedere Registrazione lato client con la libreria client di archiviazione .NET.
Note
In alcune circostanze, ad esempio in caso di mancata autorizzazione della firma di accesso condiviso, un utente può segnalare un errore per il quale non sono reperibili i dati della richiesta nei file di log dell'archiviazione lato server. È possibile utilizzare le funzionalità di registrazione di Storage Client Library per verificare se la causa del problema è sul client o utilizzare gli strumenti di monitoraggio della rete per esaminare la rete.
Uso degli strumenti di registrazione in rete
È possibile acquisire il traffico tra client e server per fornire informazioni dettagliate sui dati scambiati da client e server e sulle condizione della rete sottostante. Sono disponibili alcuni strumenti utili per la registrazione in rete:
- Fiddler è un proxy di debug Web gratuito che consente di esaminare le intestazioni e i dati di payload dei messaggi HTTP e HTTPS di richiesta e risposta. Per ulteriori informazioni, vedere Appendice 1: Uso di Fiddler per l'acquisizione del traffico HTTP e HTTPS.
- Microsoft Network Monitor (Netmon) e Wireshark sono strumenti gratuiti per l'analisi dei protocolli di rete che consentono di visualizzare informazioni dettagliate sui pacchetti per un'ampia gamma di protocolli di rete. Per altre informazioni su Wireshark, vedere Appendice 2: Uso di Wireshark per acquisire il traffico di rete.
- Per eseguire un test di base delle connessioni per verificare che il computer client sia in grado di connettersi al servizio di archiviazione Azure in rete, non è possibile utilizzare il normale strumento ping sul client. Tuttavia, è possibile utilizzare lo strumento tcping per verificare la connettività.
In molti casi, i dati di log provenienti dalla registrazione dell'archiviazione e da Storage Client Library saranno sufficienti per diagnosticare un problema, ma in alcune situazione può essere necessario disporre di informazioni più dettagliate rispetto a quelle fornite da questi strumenti. Ad esempio, l'utilizzo di Fiddler per visualizzare i messaggi HTTP e HTTPS consente di visualizzare i dati di intestazione e di payload inviati e ricevuti dai servizi di archiviazione e quindi di esaminare il modo in cui un'applicazione client ritenti le operazioni di archiviazione. Gli strumenti di analisi dei protocolli, come Wireshark, funzionano a livello di pacchetto e consentono di visualizzare i dati TCP, quindi di risolvere i problemi dovuti alla perdita di pacchetti e a errori di connessione.
Traccia end-to-end
La funzionalità di traccia end-to-end basata sull'utilizzo di una varietà di file di log è una tecnica utile per l'analisi dei potenziali problemi. È possibile usare le informazioni sulla data/ora dei dati delle metriche per indicare dove iniziare a cercare nei file di log informazioni dettagliate per facilitare la risoluzione del problema.
Correlazione dei dati di log
Quando si visualizzano i log dalle applicazioni client, dalle tracce di rete e dalla registrazione dell'archiviazione lato server, è fondamentale poter correlare le richieste nei diversi file di log. I file di log includono diversi campi che possono essere utili come identificatori di correlazioni. L'ID richiesta client è il campo più utile per usare le voci correlate nei vari log. In alcuni casi, tuttavia, può essere utile usare l'ID richiesta del server o i timestamp. Le sezioni che seguono forniscono ulteriori dettagli su queste opzioni.
ID richiesta client
La libreria client di archiviazione genera automaticamente un ID richiesta client univoco per ogni richiesta.
- Nel log 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 dell'archiviazione lato server l'ID richiesta client viene visualizzato nella colonna relativa.
Note
È possibile che più richieste convidano 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 esegue ulteriori tentativi, 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 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 lato client creato dalla libreria client di archiviazione, l'ID richiesta server viene visualizzato nella
Operation Text
colonna per la voce di log che mostra i dettagli della risposta del server.
Note
Il servizio di archiviazione assegna sempre un ID richiesta server univoco a ogni richiesta che riceve, quindi ogni nuovo tentativo del client e ogni operazione inclusa in un batch hanno 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
È possibile utilizzare i timestamp per individuare le voci di log correlate, ma è importante fare attenzione a eventuali sfasamenti di orario tra il client e il server. Cercare voci corrispondenti sul lato server con 15 minuti in più o in meno in base al timestamp sul client. Ricordare che i metadati BLOB per gli oggetti BLOB contenenti metriche indicano l'intervallo di tempo per le metriche archiviate nell'oggetto BLOB. Questo intervallo di tempo è utile se si usano molti oggetti BLOB di metriche per lo stesso minuto o la stessa ora.
Guida alla risoluzione dei problemi
Questa sezione fornisce un supporto per la diagnosi e la risoluzione di alcuni dei problemi più comuni che si possono verificare nell'applicazione usando i servizi di archiviazione Azure. Usare l'elenco che segue per individuare le informazioni pertinenti a un problema specifico.
Albero delle decisioni per la risoluzione dei problemi
Il problema riguarda le prestazioni di uno dei servizi di archiviazione?
- Le metriche mostrano un valore AverageE2ELatency elevato e un valore AverageServerLatency basso.
- Le metriche mostrano un valore AverageE2ELatency basso e un valore AverageServerLatency basso, ma il client riscontra una latenza elevata.
- Le metriche mostrano un valore AverageServerLatency elevato.
- Si verificano ritardi imprevisti nel recapito dei messaggi in una coda.
Il problema riguarda la disponibilità di uno dei servizi di archiviazione?
- Le metriche mostrano un aumento di PercentThrottlingError.
- Le metriche mostrano un aumento di PercentTimeoutError.
- Le metriche mostrano un aumento di PercentNetworkError.
L'applicazione client riceve una risposta HTTP 4XX (ad esempio 404) da un servizio di archiviazione?
- Il client riceve messaggi HTTP 403 (Accesso negato).
- Il client riceve messaggi HTTP 404 (non trovati).
- Il client riceve messaggi HTTP 409 (Conflitto).
Le metriche della capacità mostrano un aumento imprevisto dell'utilizzo della capacità di archiviazione.
Il problema si verifica dall'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 indicano un valore AverageE2ELatency alto e un valore AverageServerLatency basso
L'illustrazione dello strumento di monitoraggio del portale di Azure mostra un esempio in cui il valore AverageE2ELatency è notevolmente superiore al valore 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. Pertanto, una differenza tra AverageE2ELatency e AverageServerLatency potrebbe essere dovuta al rallentamento della risposta dell'applicazione client o a causa di condizioni nella rete.
Note
È anche possibile visualizzare i valori E2ELatency e ServerLatency per le singole operazioni di archiviazione nei dati del log della registrazione dell'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 di risorse come 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, oppure usando una macchina virtuale più grande (con più core e più memoria).
Per i servizi tabelle e code, l'algoritmo Nagle può anche causare un valore AverageE2ELatency elevato rispetto a AverageServerLatency. Per altre informazioni, vedere L'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 alla tabella o ai servizi di accodamento nell'applicazione perché ciò non influisce sulle connessioni già aperte. L'esempio Application_Start
seguente deriva dal 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 nelle 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 temporanei e 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 indicano un valore AverageE2ELatency basso e un valore AverageServerLatency basso, ma il client riscontra una latenza elevata
In questo scenario, la causa più probabile è un ritardo nelle richieste di archiviazione che arrivano al servizio di archiviazione. È necessario verificare perché le richieste del client non riescono a passare attraverso il servizio BLOB.
Un motivo possibile per cui il client ritarda l'invio delle richieste riguarda il numero limitato di connessioni o thread disponibili.
Controllare anche se il client sta eseguendo più tentativi e analizzare il motivo se lo è. Per determinare se il client sta effettuando più tentativi, è possibile:
- Esaminare i log dell'analisi dell'archiviazione. Se si stanno verificando più tentativi, verranno visualizzate più operazioni con lo stesso ID richiesta client, ma con ID richiesta server diversi.
- Esaminare i log del client. I log dettagliati indicheranno 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, laRequestResults
proprietà includerà più ID richiesta server univoci. È inoltre possibile controllare l'ora di inizio e fine di ogni richiesta. Per altre informazioni, vedere l'esempio di codice nella sezione ID richiesta server.
Se non si riscontrano problemi nel client, occorre verificare la presenza di potenziali problemi della 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 indicano un valore AverageServerLatency alto
Nel caso in cui il valore AverageServerLatency sia elevato per le richieste di download di BLOB, è necessario utilizzare il file di log della registrazione dell'archiviazione per verificare se esistono richieste ripetute per lo stesso oggetto BLOB (o insieme di oggetti BLOB). Per le richieste di caricamento dei BLOB, è necessario esaminare le dimensioni del blocco che il client sta usando (ad esempio, i blocchi di dimensioni inferiori a 64 K possono comportare sovraccarichi a meno che le letture non si trovino anche in blocchi inferiori a 64 K) e se più client caricano blocchi nello stesso BLOB in parallelo. È anche necessario 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 Metriche che mostrano un aumento di PercentTimeoutError.
Se viene visualizzata un'elevata averageServerLatency per le richieste di download blob quando sono presenti richieste ripetute per lo stesso BLOB o set di BLOB, è consigliabile memorizzare nella cache questi BLOB usando Cache di Azure o la rete CDN (Azure rete per la distribuzione di contenuti). Per le richieste di caricamento, è possibile ottimizzare la velocità utilizzando blocchi di dimensioni maggiori. Per le query sulle 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 elevati di AverageServerLatency possono essere anche sintomo della presenza di tabelle o query progettate in modo non corretto, che causano operazioni di scansione o seguono l'antipattern append/prepend. Per altre informazioni, vedere Metriche che mostrano un aumento di PercentThrottlingError.
Note
È possibile trovare un elenco di controllo completo per le prestazioni qui: elenco di controllo per le prestazioni e la scalabilità Archiviazione di Microsoft Azure.
Si stanno verificando ritardi imprevisti nel recapito dei messaggi di una coda
Se si verifica un ritardo tra il momento in cui un'applicazione aggiunge un messaggio a una coda e il momento 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 di riuscire. I file di log di Storage Client Library mostrano tutti i tentativi ripetuti delle operazioni di archiviazione. - Verificare che non vi sia un'asimmetria dell'orologio 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 lo rende come se si verificasse un ritardo nell'elaborazione.
- Verificare se il ruolo di lavoro che legge i messaggi dalla coda presenta degli errori. Se un client della coda chiama il
GetMessage
metodo ma non risponde con un riconoscimento, il messaggio rimarrà invisibile nella coda fino alla scadenza delinvisibilityTimeout
periodo. A questo punto, il messaggio diventa di nuovo disponibile per l'elaborazione. - Verificare se la lunghezza della coda aumenta con il tempo. Ciò può verificarsi se non sono disponibili ruoli di lavoro sufficienti per elaborare tutti i messaggi inseriti da altri ruoli di lavoro nella coda. Controllare anche le metriche per verificare se le richieste di eliminazione hanno esito negativo e il conteggio della coda sui messaggi, che potrebbero indicare tentativi ripetuti non riusciti di eliminare il messaggio.
- Esaminare i file di log della registrazione dell'archiviazione per verificare se esistono operazioni di accodamento con valori E2ELatency e ServerLatency su un periodo di tempo più lungo del normale.
Le metriche indicano un aumento di PercentThrottlingError
Gli errori di limitazione si verificano quando si superano gli obiettivi di scalabilità di un servizio di archiviazione. In questo modo il servizio di archiviazione viene limitato per assicurare che nessun client o tenant possa usare il servizio a spese di altri. Vedere Obiettivi di scalabilità e prestazioni per gli account di archiviazione standard per maggiori dettagli sugli obiettivi di scalabilità per gli account di archiviazione e gli 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 esaminare 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 esegue inizialmente il test di carico dell'applicazione. L'aumento si può manifestare anche nel client come messaggio di stato HTTP "503 Server Busy" o "500 Operation Timeout" delle 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 ridurre i picchi di traffico. Per altre informazioni sulle modalità di implementazione dei criteri di ripetizione con la libreria del client di archiviazione, vedere la sezione relativa allo spazio dei nomi Microsoft.Azure.Storage.RetryPolicies.
Note
È anche possibile che vengano visualizzati picchi nel valore di PercentThrottlingError che non coincidono con periodi di attività elevata per l'applicazione. La causa più probabile è lo spostamento delle partizioni dal servizio di archiviazione per migliorare il bilanciamento del carico.
Aumento permanente di PercentThrottlingError
Se viene visualizzato un valore costantemente elevato per PercentThrottlingError dopo un aumento permanente dei volumi delle transazioni o quando si eseguono i test di carico iniziali nell'applicazione, è necessario valutare come 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 conteggiato come 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 di chiave di partizione. Una causa comune di questo problema è l'anti-pattern anteporto/accodamento in cui si seleziona la data come chiave di partizione e quindi tutti i dati in un determinato giorno vengono scritti in una partizione: in fase di caricamento, questo può comportare un collo di bottiglia di scrittura. Prendere in considerazione una progettazione diversa della partizione o valutare se l'utilizzo dell'archiviazione BLOB non sia una soluzione migliore. Controllare anche se la limitazione si verifica a causa di picchi nel traffico e analizzare i modi per uniformare il modello di richieste.
Se si distribuiscono le transazioni in più partizioni, tenere presenti i limiti di scalabilità impostati per l'account di archiviazione. Ad esempio, se sono state usate dieci code, ognuna delle quali elabora il massimo di 2.000 messaggi da 1 KB 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à hanno un impatto sui casi in cui il servizio di archiviazione limita i client. Se sono presenti richieste ed entità di dimensioni maggiori, è possibile che venga limitata prima.
Anche una progettazione insufficiente delle query può causare il raggiungimento dei limiti di scalabillità per le partizioni delle tabelle. Ad esempio, una query con un filtro che seleziona solo l'uno per cento delle entità di una partizione ma esegue la scansione di tutte le entità della partizione dovrà accedere a ogni entità. Ogni lettura di entità viene aggiunta al calcolo del numero totale delle transazioni di quella partizione, quindi si possono raggiungere facilmente gli obiettivi di scalabilità.
Nota
I test delle prestazioni dovrebbero rivelare eventuali progettazioni inefficaci delle query nell'applicazione.
Le metriche indicano un aumento di PercentTimeoutError
Le metriche indicano un aumento di PercentTimeoutError per uno dei servizi di archiviazione. Allo stesso tempo, il client riceve una grande quantità di messaggi di stato HTTP "500 Operation Timeout" dalle operazioni di archiviazione.
Nota
È possibile che vengano temporaneamente visualizzati errori di timeout perché il servizio di archiviazione bilancia il carico delle richieste spostando una partizione su un nuovo server.
La metrica PercentTimeoutError è una combinazione delle metriche seguenti: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError e SASServerTimeoutError.
I timeout del server sono causati da un errore del server. I timeout del client si verificano perché un'operazione sul 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 deve essere esaminato. È possibile usare le metriche per verificare se si stanno raggiungendo i limiti di scalabilità per il servizio e identificare eventuali picchi di traffico che potrebbero causare questo problema. Se il problema è intermittente, può 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, è consigliabile generare un problema di supporto. Per i timeout del client, è necessario decidere se il timeout è impostato su un valore appropriato nel client e modificare il valore di timeout impostato nel client o esaminare come è possibile migliorare le prestazioni delle operazioni nel servizio di archiviazione, ad esempio ottimizzando le query di tabella o riducendo le dimensioni dei messaggi.
Le metriche indicano un aumento di PercentNetworkError
Le metriche indicano un aumento di PercentNetworkError per uno dei servizi di archiviazione. La metrica PercentNetworkError è una combinazione delle metriche seguenti: NetworkError, AnonymousNetworkError e SASNetworkError. L'errore si verifica se il servizio di archiviazione rileva un errore della rete quando il client esegue una richiesta di archiviazione.
La causa più comune dell'errore è la disconnessione del client prima della scadenza del timeout nel servizio di archiviazione. Esaminare il codice nel client per capire 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 sta ricevendo messaggi HTTP 403 (Accesso negato)
Se l'applicazione client genera errori HTTP 403 (Accesso negato), probabilmente il client sta utilizzando una firma di accesso condiviso (SAS, Shared Access Signature) scaduta per inviare una richiesta di archiviazione (benché esistano altre cause possibili, come sfasamento di orario, chiavi non valide e intestazioni vuote). Se una chiave di firma di accesso condiviso scaduta è la causa, non verranno visualizzate voci nei dati del log di registrazione archiviazione sul lato server. La tabella che segue mostra un esempio del file di log lato client generato da Storage Client Library in cui è illustrato il problema in corso:
Origine | Livello di dettaglio | Livello di 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 verificare perché il token SAS scade prima che il client invii il token al server:
- In genere, non è consigliabile impostare un'ora di inizio quando si crea una firma di accesso condiviso per l'uso immediato da parte di un client. Se sono presenti piccole differenze di clock tra l'host che genera la firma di accesso condiviso usando l'ora corrente e il servizio di archiviazione, è possibile che il servizio di archiviazione riceva una firma di accesso condiviso non ancora valida.
- Non impostare una scadenza molto breve in una firma di accesso condiviso. 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 di firma di accesso condiviso (ad esempio,
sv
=2015-04-05) corrisponde alla versione della libreria client di archiviazione in uso? Si consiglia di usare sempre la versione più recente di Storage Client Library. - Se si rigenerano le chiavi di accesso alle risorse di archiviazione, tutti i token SAS esistenti potrebbero essere invalidati. Questo problema può verificarsi se si generano token SAS con tempo di scadenza lungo per le applicazioni client da memorizzare nella cache.
Se si usa la libreria client di archiviazione per generare token di firma di accesso condiviso, è facile compilare un token valido. Tuttavia, se si usa l'API REST di archiviazione e si creano manualmente i token di firma di accesso condiviso, vedere Delega dell'accesso con una firma di accesso condiviso.
Il client sta ricevendo messaggi HTTP 404 (Non trovato)
Se l'applicazione client riceve un messaggio HTTP 404 (Non trovato) dal server, ciò implica che l'oggetto che il client stava tentando di usare (ad esempio un'entità, una tabella, un BLOB, un contenitore o una coda) non esiste nel servizio di archiviazione. I motivi possono essere diversi, ad esempio:
- Il client o un altro processo ha eliminato l'oggetto in precedenza.
- Problema di autorizzazione della firma di accesso condiviso.
- Il codice JavaScript lato client non dispone dell'autorizzazione per accedere all'oggetto.
- Errore di rete.
Il client o un altro processo ha eliminato l'oggetto in precedenza
Negli scenari in cui il client tenta di leggere, aggiornare o eliminare dati in un servizio di archiviazione, in genere è facile identificare nei log lato server un'operazione precedente che ha eliminato l'oggetto in questione dal servizio di archiviazione. Spesso i dati del log indicano che un altro utente o processo ha eliminato l'oggetto. Nel file di log della registrazione dell'archiviazione sul lato server, le colonne del tipo di operazione e della chiave dell'oggetto richiesto indicano quando un client ha eliminato un oggetto.
Nello scenario in cui un client sta tentando di inserire un oggetto, potrebbe non essere immediatamente ovvio perché questo risultato in una risposta HTTP 404 (Non trovato), dato che il client sta creando un nuovo oggetto. Tuttavia, se il client sta creando un BLOB, deve essere in grado di trovare il contenitore BLOB. Se il client sta creando un messaggio, deve essere in grado di trovare una coda. E se il client aggiunge una riga, deve essere in grado di trovare la tabella.
Utilizzare il log lato client generato da Storage Client Library per avere maggiori dettagli sul momento in cui il client invia richieste specifiche al servizio di archiviazione.
Il log lato client seguente generato dalla libreria client di archiviazione illustra il problema quando il client non riesce a trovare il contenitore per il BLOB che sta creando. Il file di log include dettagli relativi alle seguenti operazioni di archiviazione:
ID richiesta | Operazione |
---|---|
07b26a5d-... | DeleteIfExists per eliminare il contenitore BLOB. Si noti che questa operazione include una HEAD richiesta di verifica dell'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 del 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 = "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 interleaving richieste dal CreateIfNotExists
metodo (ID richiesta e2d06d78...) con le richieste del UploadFromStream
metodo (de8b1c3c-...). Questa interleaving si verifica perché l'applicazione client richiama questi metodi in modo asincrono. Modificare il codice asincrono nel client per assicurarsi che crei il contenitore prima di tentare di caricare dati in un BLOB in tale contenitore. La soluzione migliore sarebbe creare prima tutti i contenitori.
Si è verificato un problema di autenticazione della firma di accesso condiviso
Se l'applicazione client tenta di usare una chiave di firma di accesso condiviso che non include le autorizzazioni necessarie per l'operazione, il servizio di archiviazione restituisce un messaggio HTTP 404 (Non trovato) al client. Allo stesso tempo, verrà visualizzato anche un valore diverso da zero per SASAuthorizationError
nelle metriche.
La tabella che segue mostra un esempio di messaggio del log lato server generato dal file di log della registrazione dell'archiviazione:
Nome | Valore |
---|---|
Orario di inizio richiesta | 2014-05-30T06:17:48.4473697Z |
Tipo di operazione | GetBlobProperties |
Stato richiesta | SASAuthorizationError |
Codice di stato HTTP | 404 |
Tipo di autenticazione | Sas |
Tipo di servizio | BLOB |
Richiesta URL | 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 dell'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 per cui non è stata concessa l'autorizzazione.
Il codice JavaScript lato client non dispone dell'autorizzazione per accedere all'oggetto
Se si usa un client JavaScript e il servizio di archiviazione restituisce messaggi HTTP 404, verificare la presenza degli errori JavaScript seguenti nel browser:
SEC7120: origine http://localhost:56309 non trovata nell'intestazione Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: Errore di rete 0x80070005, Accesso negato.
Note
È 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 lato client.
Tali errori si verificano poiché il Web browser implementa come restrizione di sicurezza il criterio della stessa origine che impedisce che una pagina Web esegua una chiamata a un'API in un dominio diverso da quello da cui proviene la pagina.
Per risolvere il problema di JavaScript, è possibile configurare la condivisione di risorse tra le origini (CORS) per il servizio di archiviazione a cui accede il client. Per altre informazioni, vedere Supporto della condivisione delle risorse tra le origini (CORS) per i servizi di archiviazione Azure.
L'esempio di codice che segue indica come configurare il servizio BLOB per consentire l'esecuzione di JavaScript nel dominio Contoso in modo da poter accedere a un BLOB nel servizio di archiviazione BLOB:
var connectionString = Constants.connectionString;
BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);
BlobServiceProperties sp = blobServiceClient.GetProperties();
// Set the service properties.
sp.DefaultServiceVersion = "2013-08-15";
BlobCorsRule bcr = new BlobCorsRule();
bcr.AllowedHeaders = "*";
bcr.AllowedMethods = "GET,POST";
bcr.AllowedOrigins = "http://www.contoso.com";
bcr.ExposedHeaders = "x-ms-*";
bcr.MaxAgeInSeconds = 5;
sp.Cors.Clear();
sp.Cors.Add(bcr);
blobServiceClient.SetProperties(sp);
Errore della rete
In alcune circostanze, la perdita di pacchetti di rete può causare la restituzione da parte del servizio di archiviazione di messaggi HTTP 404 per il client. Ad esempio, quando l'applicazione client elimina un'entità dal servizio tabelle, il client genera un'eccezione di archiviazione che segnala un messaggio di stato "HTTP 404 (Non trovato)" dal servizio tabelle. Quando si esamina la tabella nel servizio di archiviazione tabelle, si può notare che il servizio ha eliminato l'entità come richiesto.
I dettagli dell'eccezione nel client includono l'ID richiesta (7e84f12d...) assegnato dal servizio tabelle per la richiesta. È possibile usare queste informazioni per individuare i dettagli della richiesta nei log di archiviazione sul lato server eseguendo una ricerca nella request-id-header
colonna nel file di log. È inoltre possibile usare le metriche per identificare il momento in cui si verificano errori come questo e quindi eseguire una ricerca nei file di log in base all'orario in cui le metriche hanno registrato l'errore. Questa voce del file di log indica che l'eliminazione non è riuscita con messaggio di stato HTTP 404 (altro errore del client). La stessa voce di log include anche l'ID richiesta generato dal client nella client-request-id
colonna (813ea74f...).
Il log lato server include anche un'altra voce con lo stesso client-request-id
valore (813ea74f...) per un'operazione di eliminazione riuscita per la stessa entità e dallo stesso client. L'operazione di eliminazione corretta viene eseguita poco prima della richiesta di eliminazione non riuscita.
La causa più probabile di questo scenario è che il client ha inviato una richiesta di eliminazione per l'entità al servizio tabelle, che ha avuto esito positivo ma non ha ricevuto un riconoscimento dal server (forse a causa di un problema di rete temporaneo). Il client ritenta quindi automaticamente l'operazione (usando lo stesso client-request-id
) e questo nuovo tentativo non è riuscito perché l'entità era già stata eliminata.
Se questo problema si verifica di frequente, è necessario capire perché il client non riesce a ricevere le risposte di conferma dal servizio tabelle. Se il problema è intermittente, occorre bloccare l'errore "HTTP (404) Non trovato" e registrarlo nel log del client, ma consentire al client di continuare.
Il client sta ricevendo messaggi HTTP 409 (Conflitto)
La tabella seguente mostra un estratto dal log lato server per due operazioni client: DeleteIfExists
seguito immediatamente usando CreateIfNotExists
lo 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
.
Timestamp: | Operazione | Risultato | Nome 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 utilizzare nomi univoci per i contenitori ogni volta che crea nuovi contenitori se il pattern delete/recreate è comune.
Le metriche indicano un valore PercentSuccess basso o le voci del log di analisi contengono operazioni con stato della transazione ClientOtherErrors
La metrica PercentSuccess acquisisce la percentuale di operazioni eseguite correttamente in base al relativo codice di stato HTTP. Le operazioni con codici di stato 2XX vengono conteggiate come riuscite, mentre le operazioni con codici di stato in intervalli 3XX, 4XX e 5XX vengono conteggiate come non riuscite e abbassano il valore della metrica PercentSuccess . Nei file di log dell'archiviazione sul lato server, queste operazioni vengono registrate con 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 restituire codici di stato HTTP negativi sono:
- 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 HTTPIf-None-Match
per richiedere un'immagine solo se è stata aggiornata dall'ultima operazione.
È possibile trovare un elenco dei codici di errore comuni dell'API REST restituiti dai servizi di archiviazione nella pagina Codici di errore comuni dell'API REST.
Le metriche della capacità indicano un aumento imprevisto dell'uso della capacità di archiviazione
Se si verificano cambiamenti improvvisi e imprevisti 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 potrebbe essere necessario 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 è dovuto all'uso dell'emulatore di archiviazione per attività di sviluppo o 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.
- Errore "Il valore per una delle intestazioni HTTP non è nel formato corretto" quando si usa l'emulatore di archiviazione.
- L'esecuzione dell'emulatore di archiviazione richiede privilegi amministrativi.
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 sviluppo e test.
Per queste funzionalità non supportate dall'emulatore di archiviazione, usare il servizio di archiviazione di Azure nel cloud.
Un messaggio indica che il valore di 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 ai metodi, CreateIfNotExists
ad esempio l'esito negativo, viene visualizzato 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 che effettua. 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'invio x-ms-version header
. È anche possibile visualizzare il valore di x-ms-version header
se si usa Fiddler per tracciare le richieste dall'applicazione client.
Questa situazione di solito si verifica quando si installa e si usa la versione più recente di Storage Client Library senza aggiornare l'emulatore di archiviazione. È necessario 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 sviluppo e test. È anche possibile inizializzare l'emulatore di archiviazione in Visual Studio, che richiede anche privilegi amministrativi.
Si stanno verificando problemi di 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 seguenti messaggi:
- CAQuietExec: Error: Unable to access SQL instance
- CAQuietExec: Error: Unable to create database
La causa è un problema con l'installazione di LocalDB esistente. Per impostazione predefinita, l'emulatore di archiviazione utilizza LocalDB per mantenere persistenti i dati quando simula i servizio di archiviazione Azure. Per reimpostare l'istanza LocalDB, eseguire i comandi indicati di seguito 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 tutti i 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 diagnosticare e risolvere il 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 influiscono sul problema.
- Utilizzare le informazioni delle metriche per cercare nei dati dei log lato server informazioni più dettagliate su eventuali errori riscontrati. Queste informazioni possono essere utili per diagnosticare e risolvere il problema.
- Se le informazioni nei log 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, ad esempio 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 possono risultare utili durante la diagnosi e la risoluzione dei problemi relativi ai 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 illustrati in queste appendici non sono coperti da alcun contratto di supporto che si potrebbe avere 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 l'acquisizione del 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.
Note
Fiddler può decodificare il traffico HTTPS. È consigliabile leggere attentamente la documentazione di Fiddler per comprendere come esegue questa operazione e le relative implicazioni per la sicurezza.
Questa appendice descrive brevemente la procedura di configurazione di Fiddler per l'acquisizione del traffico tra il computer locale in cui è installato Fiddler e i servizi di archiviazione Azure.
Dopo l'avvio, Fiddler inizia ad acquisire il traffico HTTP e HTTPS sul computer locale. Di seguito sono riportati alcuni comandi utili per il controllo di Fiddler:
- Interruzione e avvio dell'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 di sessione 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:
Appendice 2: Uso di Wireshark per l'acquisizione del traffico di rete
Wireshark è uno strumento di analisi dei protocolli di rete che consente di visualizzare informazioni dettagliate sui pacchetti per un'ampia gamma di protocolli di rete.
La procedura che segue indica come acquisire informazioni dettagliate sui pacchetti per il traffico dal computer locale su cui è installato Wireshark al servizio tabelle nell'account di archiviazione Azure.
Avviare Wireshark sul computer locale.
Nella sezione Start , selezionare l'interfaccia (o le interfacce) di rete locale connessa a Internet.
Selezionare Opzioni di acquisizione.
Aggiungere un filtro nella casella di testo Capture Filter . Ad esempio,
host contosoemaildist.table.core.windows.net
configurerà Wireshark per acquisire solo i pacchetti inviati a o dall'endpoint del servizio tabelle nell'account di archiviazione contosoemaildist . Vedere l' elenco completo dei filtri di acquisizione.Selezionare Inizio. Wireshark acquisisce ora tutti i pacchetti inviati a o dall'endpoint del servizio tabelle quando si usa l'applicazione client nel computer locale.
Al termine, selezionare Arresta acquisizione > nel menu principale.
Per salvare i dati acquisiti in un file di acquisizione Wireshark, selezionare Salva file>nel menu principale.
WireShark evidenzia tutti gli errori presenti nella finestra packetlist . È anche possibile usare la finestra Expert Info (selezionare Analizza>info esperto) per visualizzare un riepilogo degli errori e degli avvisi.
È anche possibile scegliere di visualizzare i dati TCP nello stesso modo in cui vengono visualizzati dal livello dell'applicazione, facendo clic con il pulsante destro del mouse sui dati TCP e selezionando Follow TCP Stream (Segui flusso TCP). Ciò è utile se si acquisisce il dump senza un filtro di acquisizione. Per altre informazioni, vedere Seguire i flussi TCP.
Note
Per ulteriori informazioni sull'uso di Wireshark, vedere la guida dell'utente di Wireshark.
Appendice 4: Uso di Excel per la visualizzazione di metriche e dati di log
Molti strumenti consentono di scaricare i dati di Metriche di archiviazione dalle tabelle di archiviazione 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 in formato log Analisi archiviazione e Analisi archiviazione schema di tabella delle metriche.
Per importare i dati della registrazione dell'archiviazione in Excel dopo il download dall'archiviazione BLOB:
- Scegliere Da testo dal menu Dati.
- Passare al file di log da 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 di testo. Selezionare Quindi Fine e scegliere dove inserire i dati nella cartella di lavoro.
Appendice 5: Monitoraggio con Application Insights per Azure DevOps
È possibile usare la funzionalità Application Insights per Azure DevOps come parte del monitoraggio delle prestazioni e della disponibilità. Questo strumento consente di:
- 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 dalle località in tutto il mondo e segnalare se si è verificato un problema.
- Diagnosticare rapidamente eventuali problemi di prestazioni o eccezioni del servizio Web. Sapere se la CPU o altre risorse vengono estese, ricavare analisi dello stack dalle eccezioni ed eseguire facilmente la ricerca delle tracce nei log. Se le prestazioni dell'app scendono al di sotto di limiti accettabili, Microsoft può inviare un messaggio di posta elettronica. L'utente può monitorare i servizi Web sia .NET che Java.
Per altre informazioni, vedere Informazioni su Azure Application Insights.
Passaggi successivi
Per altre informazioni sull'analisi in Archiviazione di Azure, vedere queste risorse:
- Monitorare un account di archiviazione nel portale di Azure
- Analisi Archiviazione
- Metriche di Analisi archiviazione
- Schema di tabella delle metriche di Analisi archiviazione
- Log di Analisi archiviazione
- Formato log Analisi archiviazione
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.