Come monitorare le UR/sec normalizzate per un contenitore di Azure Cosmos DB o un account

SI APPLICA A: Nosql Mongodb Cassandra Gremlin Tabella

Monitoraggio di Azure per Azure Cosmos DB offre una visualizzazione delle metriche per monitorare l'account e creare dashboard. Le metriche di Azure Cosmos DB vengono raccolte per impostazione predefinita, questa funzionalità non richiede l'abilitazione o la configurazione di alcun elemento in modo esplicito.

Definizione metrica

La metrica Normalized UR Consumption è una metrica compresa tra il 0% e il 100% usata per misurare l'utilizzo della velocità effettiva con provisioning in un database o in un contenitore. La metrica viene generata a intervalli di 1 minuto ed è definita come utilizzo massimo di UR/s in tutti gli intervalli di chiavi di partizione nell'intervallo di tempo. Ogni intervallo di chiavi di partizione esegue il mapping a una partizione fisica e viene assegnato per contenere i dati per un intervallo di valori hash possibili. In generale, maggiore è la percentuale di UR normalizzata, più è stata usata la velocità effettiva di cui è stato effettuato il provisioning. La metrica può essere usata anche per visualizzare l'utilizzo dei singoli intervalli di chiavi di partizione in un database o in un contenitore.

Si supponga, ad esempio, di avere un contenitore in cui si imposta la velocità effettiva massima di scalabilità automatica di 20.000 UR/sec (scalabilità compresa tra 2000 e 20.000 UR/sec) e si dispone di due intervalli di chiavi di partizione (partizioni fisiche) P1 e P2. Poiché Azure Cosmos DB distribuisce equamente la velocità effettiva con provisioning in tutti gli intervalli di chiavi di partizione, P1 e P2 possono essere ridimensionati tra 1000 e 10.000 UR/sec. Si supponga che in un intervallo di 1 minuto, in un secondo specificato P1 abbia utilizzato 6000 unità richiesta e P2 abbia utilizzato 8000 unità richiesta. Il consumo normalizzato di UR di P1 è del 60% e dell'80% per P2. Il consumo complessivo di UR normalizzate dell'intero contenitore è MAX(60%, 80%) = 80%.

Se si è interessati a visualizzare il consumo di unità richiesta a un intervallo di secondo, insieme al tipo di operazione, è possibile usare la funzionalità di consenso esplicito Log di diagnostica ed eseguire una query sulla tabella PartitionKeyRUConsumption . Per ottenere una panoramica generale delle operazioni e del codice di stato eseguite dall'applicazione nella risorsa di Azure Cosmos DB, è possibile usare la metrica Richieste totali di Monitoraggio di Azure predefinite (API per NoSQL), Richieste Mongo, Richieste Gremlin o Richieste Cassandra. In seguito è possibile filtrare queste richieste in base al codice di stato 429 e suddividerle in base al tipo di operazione.

Cosa aspettarsi e fare quando le UR/sec normalizzate sono superiori

Quando il consumo normalizzato di UR raggiunge il 100% per un determinato intervallo di chiavi di partizione e se un client effettua ancora richieste nell'intervallo di tempo di 1 secondo a tale intervallo di chiavi di partizione specifico, riceve un errore limitato di frequenza (429).

Questo non significa necessariamente che ci sia un problema con la risorsa. Per impostazione predefinita, gli SDK client di Azure Cosmos DB e gli strumenti di importazione dei dati, ad esempio Azure Data Factory e la libreria dell'executor bulk, riprovano automaticamente le richieste su 429. In genere vengono rieseguiti fino a 9 volte. Di conseguenza, anche se potrebbero essere presenti 429 metriche, questi errori potrebbero anche non essere stati restituiti all'applicazione.

In generale, per un carico di lavoro di produzione, se viene visualizzato tra l'1 e il 5% delle richieste con errori 429 e la latenza end-to-end è accettabile, si tratta di un segno positivo che le UR/sec vengono completamente usate. In questo caso, la metrica di consumo normalizzato delle UR raggiunge il 100% significa solo che in un determinato secondo, almeno un intervallo di chiavi di partizione ha usato tutta la velocità effettiva con provisioning. Questo è accettabile perché il tasso complessivo di errori 429 è ancora basso. Non è richiesta alcuna azione ulteriore.

Per determinare quale percentuale delle richieste al database o al contenitore ha generato 429s, dal pannello dell'account Azure Cosmos DB passare a Informazioni dettagliate>Richieste totali richieste>per codice di stato. Filtrare in base a un database e a un contenitore specifici. Per l'API per Gremlin, usare la metrica Richieste Gremlin.

Se la metrica di consumo di UR normalizzata è costantemente del 100% tra più intervalli di chiavi di partizione e la velocità di 429 è maggiore del 5%, è consigliabile aumentare la velocità effettiva. È possibile scoprire quali operazioni sono pesanti e quali sono i picchi di utilizzo usando le metriche di monitoraggio di Azure e i log di diagnostica di Monitoraggio di Azure. Seguire le Procedure consigliate per il dimensionamento della velocità effettiva con provisioning (UR/sec).

Non è sempre il caso in cui venga visualizzato un errore di limitazione della frequenza di 429 solo perché l'UR normalizzata ha raggiunto il 100%. Ciò è dovuto al fatto che l'UR normalizzata è un singolo valore che rappresenta l'utilizzo massimo su tutti gli intervalli di chiavi di partizione. Un intervallo di chiavi di partizione può essere occupato, ma gli altri intervalli di chiavi di partizione possono gestire le richieste senza problemi. Ad esempio, una singola operazione, ad esempio una stored procedure che utilizza tutte le UR/sec in un intervallo di chiavi di partizione, comporterà un breve picco nella metrica di consumo di UR normalizzata. In questi casi, non ci saranno errori di limitazione immediata della frequenza se la frequenza complessiva delle richieste è bassa o le richieste vengono effettuate ad altre partizioni in intervalli di chiavi di partizione diversi.

Altre informazioni su come interpretare ed eseguire il debug di errori di limitazione della frequenza 429.

Come monitorare le partizioni ad accesso frequente

La metrica normalizzata per il consumo di UR può essere usata per monitorare se il carico di lavoro ha una partizione ad accesso frequente. Una partizione ad accesso frequente si verifica quando una o poche chiavi di partizione logiche utilizzano una quantità sproporzionata di UR/sec totali a causa di un volume di richieste superiore. Ciò può essere causato da una progettazione della chiave di partizione che non distribuisce uniformemente le richieste. Ciò comporta l'indirizzamento di molte richieste a un piccolo subset di partizioni logiche (che implica intervalli di chiavi di partizione) che diventano "ad accesso frequente". Poiché tutti i dati per una partizione logica si trovano in un intervallo di chiavi di partizione e le UR/sec totali vengono distribuiti uniformemente tra tutti gli intervalli di chiavi di partizione, una partizione ad accesso frequente può portare a 429 e un uso inefficiente della velocità effettiva.

Come identificare se è presente una partizione ad accesso frequente

Per verificare se è presente una partizione ad accesso frequente, passare a Insights Throughput>>Normalized UR Consumption (%) By PartitionKeyRangeID (Utilizzo normalizzato UR normalizzato%) per PartitionKeyRangeID. Filtrare in base a un database e a un contenitore specifici.

Ogni PartitionKeyRangeId esegue il mapping a una partizione fisica. Se è presente un valore PartitionKeyRangeId con un consumo di UR normalizzato significativamente superiore rispetto ad altri (ad esempio, uno è costantemente al 100%, ma altri sono al 30% o meno), questo può essere un segno di una partizione ad accesso frequente.

Per identificare le partizioni logiche che utilizzano la maggior parte delle UR/sec, nonché le soluzioni consigliate, vedere l'articolo Diagnosticare e risolvere i problemi delle eccezioni di frequenza delle richieste di Azure Cosmos DB troppo grandi (429).

Consumo di UR normalizzato e scalabilità automatica

La metrica di consumo di UR normalizzata verrà visualizzata come 100% se almeno 1 intervallo di chiavi di partizione usa tutte le UR/sec allocate in un secondo specificato nell'intervallo di tempo. Una domanda comune che si verifica è, perché il consumo di UR normalizzato al 100%, ma Azure Cosmos DB non ha ridimensionato le UR/s alla velocità effettiva massima con scalabilità automatica?

Nota

Le informazioni seguenti descrivono l'implementazione corrente della scalabilità automatica e possono essere soggette a modifiche in futuro.

Quando si usa la scalabilità automatica, Azure Cosmos DB ridimensiona solo le UR/s fino alla velocità effettiva massima quando il consumo normalizzato di UR è del 100% per un periodo di tempo costante e continuo in un intervallo di 5 secondi. Questa operazione viene eseguita per garantire che la logica di ridimensionamento sia conveniente per l'utente, in quanto garantisce che i singoli picchi momentanei non portino a un ridimensionamento non necessario e a costi più elevati. Quando si verificano picchi momentanei, il sistema in genere aumenta fino a un valore superiore a quello precedentemente ridimensionato alle UR/sec, ma inferiore al numero massimo di UR/sec.

Si supponga, ad esempio, di avere un contenitore con velocità effettiva massima di scalabilità automatica pari a 20.000 UR/sec (scalabilità compresa tra 2000 e 20.000 UR/sec) e 2 intervalli di chiavi di partizione. Ogni intervallo di chiavi di partizione può essere ridimensionato tra 1000 e 10.000 UR/sec. Poiché la scalabilità automatica effettua il provisioning iniziale di tutte le risorse necessarie, è possibile usare fino a 20.000 UR/sec in qualsiasi momento. Si supponga di avere un picco intermittente del traffico, dove per un singolo secondo, l'utilizzo di uno degli intervalli di chiavi di partizione è di 10.000 UR/sec. Per i secondi successivi, l'utilizzo torna indietro a 1000 UR/sec. Poiché la metrica di consumo di UR normalizzata mostra l'utilizzo più elevato nel periodo di tempo in tutte le partizioni, verrà visualizzato il 100%. Tuttavia, poiché l'utilizzo è stato solo del 100% per 1 secondo, la scalabilità automatica non verrà ridimensionata automaticamente al massimo.

Di conseguenza, anche se la scalabilità automatica non è stata ridimensionata al massimo, è ancora possibile usare le UR/sec totali disponibili. Per verificare il consumo di UR/sec, è possibile usare la funzionalità di consenso esplicito Log di diagnostica per eseguire query sul consumo complessivo di UR/sec a un livello al secondo in tutti gli intervalli di chiavi di partizione.

CDBPartitionKeyRUConsumption
| where TimeGenerated >= (todatetime('2022-01-28T20:35:00Z')) and TimeGenerated <= todatetime('2022-01-28T20:40:00Z')
| where DatabaseName == "MyDatabase" and CollectionName == "MyContainer"
| summarize sum(RequestCharge) by bin(TimeGenerated, 1sec), PartitionKeyRangeId
| render timechart

In generale, per un carico di lavoro di produzione che usa la scalabilità automatica, se viene visualizzato tra il 1 e il 5% delle richieste con 429 e la latenza end-to-end è accettabile, si tratta di un segno integro che le UR/s vengono usate completamente. Anche se il consumo normalizzato di UR raggiunge occasionalmente il 100% e la scalabilità automatica non aumenta fino al numero massimo di UR/sec, questo è ok perché il tasso complessivo di 429s è basso. Non è richiesta alcuna azione.

Suggerimento

Se si usa la scalabilità automatica e si rileva che il consumo di UR normalizzate è costantemente del 100% e si viene ridimensionati in modo coerente al numero massimo di UR/sec, questo è un segno che l'uso della velocità effettiva manuale può essere più conveniente. Per determinare se la scalabilità automatica o la velocità effettiva manuale è ottimale per il carico di lavoro, vedere come scegliere tra velocità effettiva con provisioning a scalabilità automatica (standard) e scalabilità automatica. Azure Cosmos DB invia anche raccomandazioni di Azure Advisor in base ai modelli di carico di lavoro per consigliare la velocità effettiva manuale o a scalabilità automatica.

Visualizzare la metrica di utilizzo delle unità richiesta normalizzata

1. Accedi al portale di Azure.

2. Nel menu di spostamento a sinistra selezionare Monitoraggio e quindi selezionare Metriche.

   

3. Nel riquadro >Metriche Selezionare una risorsa> scegliere la sottoscrizione richiesta e il gruppo di risorse. Per Tipo di risorsa selezionare Account Azure Cosmos DB, scegliere uno degli account Azure Cosmos DB esistenti e selezionare Applica.

   

4. È quindi possibile selezionare una metrica dall'elenco delle metriche disponibili. È possibile selezionare metriche specifiche per unità richiesta, archiviazione, latenza, disponibilità, Cassandra e altre. Per informazioni dettagliate su tutte le metriche disponibili in questo elenco, vedere l'articolo Metriche per categoria. In questo esempio viene selezionata la metrica Normalizzazione del consumo di UR e Max come valore di aggregazione.

   Oltre a questi dettagli, è anche possibile selezionare l'Intervallo di tempo e la Granularità temporale delle metriche. Al massimo, è possibile visualizzare le metriche degli ultimi 30 giorni. Dopo aver applicato il filtro, viene visualizzato un grafico in base al filtro.

   

Filtri per la metrica di consumo di UR normalizzata

È anche possibile filtrare le metriche e il grafico visualizzato da uno specifico CollectionName, DatabaseName, PartitionKeyRangeID e Region. Per filtrare le metriche, selezionare Aggiungi filtro e scegliere la proprietà richiesta, ad esempio CollectionName e il valore corrispondente a cui si è interessati. Il grafico visualizza quindi la metrica normalizzata per il consumo di UR per il contenitore per il periodo selezionato.

È possibile raggruppare le metriche usando l'opzione Applicare separazione. Per i database con velocità effettiva condivisa, la metrica delle UR normalizzate mostra solo i dati con granularità del database, non visualizza dati per raccolta. Pertanto, per il database con velocità effettiva condivisa, non verranno visualizzati dati quando si applica la suddivisione in base al nome della raccolta.

La metrica di consumo delle unità richiesta normalizzata per ogni contenitore viene visualizzata come illustrato nell'immagine seguente:

Passaggi successivi

• Monitorare i dati di Azure Cosmos DB usando le impostazioni di diagnostica in Azure.
• Controllare le operazioni del piano di controllo di Azure Cosmos DB
• Diagnosticare e risolvere i problemi di Azure Cosmos DB relativi alla frequenza troppo elevata delle richieste (eccezioni 429)