Come monitorare l'UR/sec normalizzato per un contenitore o un account di Azure Cosmos DB

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, quindi per questa funzionalità non è necessario abilitare o configurare alcunché in modo esplicito.

Definizione di metrica

La metrica Consumo UR normalizzato è compresa tra lo 0% e il 100% e consente di misurare l'utilizzo della velocità effettiva di cui è stato effettuato il provisioning in un database o in un contenitore. La metrica viene generata a intervalli di 1 minuto e viene 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ò anche essere usata 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 di disporre 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 di UR normalizzato di P1 è del 60% e dell'80% per P2. Il consumo complessivo di UR normalizzato 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à attivabile di Log di diagnostica ed eseguire una query sulla tabella PartitionKeyRUConsumption . Per ottenere una panoramica generale delle operazioni e dello stato del codice eseguiti dall'applicazione nella risorsa di Azure Cosmos DB, è possibile usare le metriche predefinite di Monitoraggio di Azure Richieste totali (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 di UR normalizzato raggiunge il 100% per un determinato intervallo di chiavi di partizione e se un client effettua ancora richieste in quel intervallo di tempo di 1 secondo a tale intervallo di chiavi di partizione specifico, si riceve un errore di frequenza limitata (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 quali Azure Data Factory e la libreria di esecuzione bulk ritentano automaticamente le richieste in caso di codice di stato 429. In genere vengono rieseguiti fino a 9 volte. Di conseguenza, anche se nelle metriche potrebbero essere visualizzati errori 429, questi errori potrebbero persino 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, se la metrica di consumo di UR normalizzato raggiunge il 100%, significa solamente 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 errori 429, dal pannello dell'account Azure Cosmos DB passare a Informazioni dettagliate>Richieste>Richieste totali per codice di stato. Filtrare in base a un database e a un contenitore specifico. Per l'API per Gremlin, usare la metrica Richieste Gremlin.

Se la metrica di consumo di UR normalizzato è costantemente del 100% tra più intervalli di chiavi di partizione e la frequenza 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 succede sempre che viene visualizzato un errore di limitazione della frequenza di 429 solo perché l'UR normalizzato ha raggiunto il 100%. Ciò è dovuto al fatto che l'UR normalizzato è 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 normalizzato. In questi casi gli errori di limitazione della frequenza non si verificano subito se la frequenza generale delle richieste non è elevata o se le richieste vengono inviate 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 per il consumo di UR normalizzate può essere usata per monitorare se il carico di lavoro ha una partizione ad accesso frequente. Una partizione ad accesso frequente si genera quando una o alcune chiavi della partizione logica utilizzano una quantità sproporzionata di RU/sec totali a causa di un maggior volume di richieste. Ciò può essere causato da una progettazione della chiave di partizione che non distribuisce uniformemente le richieste e comporta l'indirizzamento di molte richieste a un piccolo subset di partizioni logiche (incluse gli intervalli di chiavi della partizione) che diventano "ad accesso frequente". Poiché tutti i dati di una partizione logica si trovano in un intervallo di chiavi della partizione e le UR/s totali vengono distribuite uniformemente tra tutti gli intervalli di chiavi della partizione, una partizione ad accesso frequente può portare a codici 429 e a un uso inefficiente della velocità effettiva.

Come identificare se è presente una partizione ad accesso frequente

Per verificare la presenza di una partizione ad accesso frequente, passare a Informazioni dettagliate>Velocità effettiva>Consumo UR normalizzato (%) per PartitionKeyRangeID. Filtrare in base a un database e a un contenitore specifico.

Ogni PartitionKeyRangeId è mappato a una partizione fisica. Se è presente un PartitionKeyRangeId che ha un consumo di UR normalizzato molto più elevato rispetto agli altri (ad esempio, uno è sempre al 100%, ma gli 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 normalizzato 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 è, 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 dimensiona solo le UR/s fino alla velocità effettiva massima quando il consumo di UR normalizzato è 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 dimensionamento sia conveniente per l'utente, in quanto garantisce che i singoli picchi momentanei non portino a un dimensionamento non necessario e a costi più elevati. Quando si verificano picchi momentanei, il sistema in genere aumenta le prestazioni fino a un valore superiore a quello delle UR/s raggiunto precedentemente, ma inferiore al numero massimo di UR/s.

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 normalizzato 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 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. Anche se il consumo di UR normalizzato raggiunge occasionalmente il 100% e la scalabilità automatica non aumenta fino al numero massimo di UR/sec, questo è ok perché il tasso complessivo di 429 è basso. Non è necessaria alcuna azione.

Suggerimento

Se si usa la scalabilità automatica e si rileva che il consumo di UR normalizzato è 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à standard (manuale) 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 normalizzate

1. Accedere 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 e il gruppo di risorse richiesti. 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 Consumo di UR normalizzato 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 normalizzato

È anche possibile filtrare le metriche e il grafico visualizzato da uno specifico CollectionName, DatabaseName, PartitionKeyRangeID e Area. 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 Consumo di UR normalizzato 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 consumo di UR normalizzato 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 normalizzato 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)