Eseguire il monitoraggio e il debug con informazioni dettagliate in Azure Cosmos DB
SI APPLICA A: 
NoSQL MongoDB Cassandra Gremlin Tabella
Azure Cosmos DB offre informazioni dettagliate per velocità effettiva, archiviazione, coerenza, disponibilità e latenza. Il portale di Azure offre una visualizzazione aggregata di queste metriche. È anche possibile visualizzare le metriche di Azure Cosmos DB nell'API di Monitoraggio di Azure. I valori delle dimensioni per le metriche, ad esempio il nome del contenitore, non fanno distinzione tra maiuscole e minuscole. È quindi necessario usare un confronto senza distinzione tra maiuscole e minuscole per i confronti tra stringhe su questi valori di dimensione. Per informazioni su come visualizzare le metriche da Monitoraggio di Azure, vedere Monitorare Azure Cosmos DB.
Questo articolo illustra dettagliatamente i casi d'uso comuni e come usare le informazioni dettagliate di Azure Cosmos DB per analizzare ed eseguire il debug di questi problemi. Per impostazione predefinita, le informazioni dettagliate sulle metriche vengono raccolte ogni cinque minuti e vengono conservate per sette giorni.
Nelle sezioni seguenti vengono descritti scenari comuni in cui è possibile usare le metriche di Azure Cosmos DB.
Nota
Quando si filtrano in base al database o alle raccolte nelle metriche, è possibile che sia visualizzato "__Empty" o "<Vuoto>" come resourceName. Ciò è dovuto al fatto che i dati delle metriche vengono raccolti a livello di account per la richiesta specifica. Di conseguenza, non esiste un database o una raccolta associati come valore della metrica.
Scoprire il numero di richieste che riesce o causa errori
Per iniziare, accedere al portale di Azure e passare al pannello Informazioni dettagliate. In questo riquadro aprire la scheda Richieste. La scheda Richieste mostra un grafico contenente le richieste totali suddivise per codice di stato e tipo di operazione. Per altre informazioni sui codici di stato HTTP, vedere HTTP Status Codes for Azure Cosmos DB (Codici di stato HTTP per Azure Cosmos DB).
Il codice di stato di errore più comune è 429 (limitazione della velocità/limitazione). Questo errore indica che le richieste ad Azure Cosmos DB sono maggiori rispetto alle UR di cui è stato effettuato provisioning. La soluzione più comune per questo problema consiste nell'aumentare il numero di UR per la raccolta specificata. Per altre informazioni, vedere Introduzione alla velocità effettiva con provisioning in Azure Cosmos DB
Determinare il consumo di velocità effettiva in base a un intervallo di chiavi di partizione
Avere una buona cardinalità delle chiavi di partizione è essenziale per qualsiasi applicazione scalabile. Per determinare la distribuzione della velocità effettiva di un contenitore partizionato, suddiviso in base agli ID degli intervalli di chiavi di partizione, passare al riquadro Informazioni dettagliate. Aprire la scheda Velocità effettiva. Nel grafico è illustrato il consumo di UR/sec normalizzate in intervalli di chiavi di partizione.
Con l'aiuto di questo grafico, è possibile identificare se è presente una partizione ad accesso frequente. PartitionKeyRangeIDs corrisponde alle partizioni fisiche. La metrica Normald UR Consumption è un valore compreso tra 0% e 100% che consente di misurare l'utilizzo della velocità effettiva con provisioning in un database o in un contenitore. Una distribuzione non uniforme della velocità effettiva può generare partizioni critiche, che possono ridurre le richieste e potrebbero richiedere una nuova ripartizione. Dopo aver identificato la chiave di partizione che riduce la distribuzione, è possibile che sia necessario ripartizionare il contenitore con una chiave di partizione più distribuita. Per altre informazioni sul partizionamento in Azure Cosmos DB, vedere l'articolo Partizionamento e ridimensionamento orizzontale in Azure Cosmos DB.
Determinare il consumo di dati e indici
È importante determinare la distribuzione di archiviazione di qualsiasi contenitore partizionato in base al consumo di dati, indici e documenti. È possibile ridurre al minimo il consumo degli indici, aumentare al massimo il consumo dei dati e ottimizzare le query. Per ottenere questi dati, passare al riquadro Informazioni dettagliate e aprire la scheda Archiviazione.
Confrontare le dimensioni dei dati e le dimensioni dell'indice
In Azure Cosmos DB lo spazio di archiviazione totale usato risulta dalla combinazione delle dimensioni dei dati e delle dimensioni dell'indice. In genere, le dimensioni dell'indice sono una frazione delle dimensioni dei dati. Per altre informazioni, vedere l'articolo Dimensioni dell'indice. Nel riquadro Metriche del portale di Azure, la scheda Archiviazione mostra la suddivisione dell'uso dello spazio di archiviazione in base ai dati e all'indice.
// Measure the document size usage (which includes the index size)
ResourceResponse<DocumentCollection> collectionInfo = await client.ReadDocumentCollectionAsync(UriFactory.CreateDocumentCollectionUri("db", "coll"));
Console.WriteLine("Document size quota: {0}, usage: {1}", collectionInfo.DocumentQuota, collectionInfo.DocumentUsage);
Se si desidera risparmiare spazio degli indici, è possibile modificare i criteri di indicizzazione.
Eseguire il debug di query lente
Negli SDK dell'API per NoSQL, Azure Cosmos DB presenta le statistiche di esecuzione delle query.
IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName),
"SELECT * FROM c WHERE c.city = 'Seattle'",
new FeedOptions
{
PopulateQueryMetrics = true,
MaxItemCount = -1,
MaxDegreeOfParallelism = -1,
EnableCrossPartitionQuery = true
}).AsDocumentQuery();
FeedResponse<dynamic> result = await query.ExecuteNextAsync();
// Returns metrics by partition key range Id
IReadOnlyDictionary<string, QueryMetrics> metrics = result.QueryMetrics;
QueryMetrics offre informazioni dettagliate sulla durata dell'esecuzione di ogni componente della query. La causa radice più comune per le query con esecuzione prolungata è rappresentata dalle analisi, che indicano che la query non è riuscita ad applicare gli indici. Questo problema può essere risolto con una condizione di filtro migliore.
Monitorare le richieste del piano di controllo
Azure Cosmos DB applica limiti specifici al numero di richieste di metadati che possono essere effettuate in intervalli consecutivi di 5 minuti. Le richieste del piano di controllo che superano questi limiti possono riscontrare alcune limitazioni. In alcuni casi, le richieste di metadati possono consumare la velocità effettiva di una master partition all'interno di un account contenente tutti i metadati dell'account. Le richieste del piano di controllo che superano questa velocità effettiva subiranno una limitazione della frequenza (429s).
Per iniziare, accedere al portale di Azure e passare al pannello Informazioni dettagliate. In questo riquadro aprire la scheda Sistema, in cui sono presenti due grafici. Nel primo sono illustrate tutte le richieste di metadati di un account, mentre nel secondo viene visualizzato il consumo di velocità effettiva per richieste di metadati da parte della master partition dell'account in cui sono archiviati i metadati dell'account.
Nel grafico Richiesta di metadati per codice di stato sopra riportato, le richieste vengono aggregate con una granularità sempre più elevata man mano che viene aumentato l'intervallo di tempo. L'intervallo di tempo più ampio che è possibile usare per un contenitore temporale di 5 minuti è di 4 ore. Per monitorare richieste di metadati a intervalli di tempo maggiori con granularità specifica, usare Metriche di Azure. Creare un nuovo grafico e selezionare la metrica Richieste di metadati. Nell'angolo in alto a destra impostare Granularità temporale su 5 minuti, come illustrato di seguito. Le metriche consentono inoltre agli utenti di Creare avvisi su di esse, che diventano così più utili rispetto alle informazioni dettagliate.
Passaggi successivi
È possibile leggere gli articoli seguenti per scoprire di più su come migliorare le prestazioni del database: