Comment surveiller les EF normalisées pour un conteneur Azure Cosmos DB ou un compte

S’APPLIQUE À : NoSQL MongoDB Cassandre Gremlin Tableau

Azure Monitor pour Azure Cosmos DB fournit une vue de métriques pour surveiller votre compte et créer des tableaux de bord. Les métriques Azure Cosmos DB sont collectées par défaut. Cette fonctionnalité ne vous oblige pas à activer ou à configurer quoi que ce soit explicitement.

Définition des métriques

La métrique Consommation de RU normalisée est une métrique comprise entre 0 % et 100 % permettant de mesurer l’utilisation du débit approvisionné sur une base de données ou un conteneur. La métrique est émise à intervalles de 1 minute et est définie comme l’utilisation maximale des RU/s sur toutes les plages de clés de partition dans l’intervalle de temps. Chaque plage de clés de partition correspond à une partition physique et est assigné pour contenir des données pour une plage de valeurs de hachage possibles. En général, plus le pourcentage de RU normalisé est élevé, plus vous avez utilisé votre débit approvisionné. La métrique peut également être utilisée pour afficher l’utilisation des plages de clés de partition individuelles sur une base de données ou un conteneur.

Par exemple, supposons que vous disposiez d’un conteneur où vous définissez le débit maximal de mise à l’échelle automatique de 20 000 RU/s (mise à l’échelle entre 2 000 et 20 000 RU/s) et que vous disposiez de deux plages de clés de partition (partitions physiques) P1 et P2. Étant donné qu’Azure Cosmos DB distribue le débit approvisionné de manière égale sur toutes les plages de clés de partition, P1 et P2 peuvent être mis à l’échelle entre 1 000 et 10 000 RU/s. Supposons dans un intervalle de 1 minute, dans une seconde donnée, P1 a consommé 6000 unités de requête et P2 consommé 8000 unités de requête. La consommation normalisée de RU de P1 sera de 60 % et de 80 % pour P2. La consommation globale de RU normalisée de l’ensemble du conteneur est MAX(60%, 80%) = 80 %.

Si vous souhaitez voir la consommation de RU à un intervalle par seconde, ainsi que le type d’opération, vous pouvez utiliser les journaux de diagnostic des fonctionnalités d’acceptation et interroger la table PartitionKeyRUConsumption. Pour obtenir une vue d’ensemble générale des opérations et du code d’état que votre application effectue sur la ressource Azure Cosmos DB, vous pouvez utiliser la métrique Nombre total de requêtes intégrée à Azure Monitor (API for NoSQL), Requêtes Mongo, Requête Gremlin ou Requêtes Cassandra. Plus tard, vous pouvez filtrer ces requêtes par selon le code d’état 429 et les diviser selon le critère Operation Type (Type d’opération).

Ce qu’il faut attendre et faire quand les unités de requête normalisée par seconde sont plus élevés

Lorsque la consommation normalisée de RU/s atteint 100 % pour une plage de clés de partition donnée et qu’un client fait encore des demandes dans cette fenêtre de temps de 1 seconde pour cette plage de clés de partition spécifique, celui-ci reçoit une erreur de débit limité (429).

Cela ne signifie pas nécessairement qu’il y a un problème avec votre ressource. Par défaut, les Kits de développement logiciel (SDK) du client Azure Cosmos DB et les outils d’importation de données, tels qu’Azure Data Factory et la bibliothèque d’exécuteur en bloc, réessayent automatiquement les requêtes en cas d’erreur 429. Ils réessaient généralement jusqu’à neuf fois. Par conséquent, bien que vous puissiez voir des exceptions 429 dans les métriques, ces erreurs peuvent ne pas avoir été renvoyées à votre application.

En général, pour une charge de travail de production, si vous constatez entre 1 % et 5 % de requêtes avec des exceptions 429 et que la latence de bout en bout est acceptable, il s’agit d’un signe sain que les RU/s sont pleinement utilisées. Dans ce cas, la métrique de consommation de RU normalisée atteignant 100 % signifie uniquement que, à une seconde donnée, au moins une plage de clés de partition a utilisé tout son débit approvisionné. Cela est acceptable, car le taux global des erreurs 429 est encore faible. Aucune action supplémentaire n’est requise.

Pour déterminer le pourcentage de vos requêtes à votre base de données ou conteneur qui ont abouti au code 429, à partir de votre compte Azure Cosmos DB, accédez à Insights>Requests>Total Requests by Status Code. Filtrez sur une base de données et un conteneur spécifiques. Pour l'API pour Gremlin, utilisez la métrique des requêtes Gremlin.

Si la métrique de consommation de RU normalisée est de 100 % sur plusieurs plages de clés de partition et que le taux d’erreur 429 est supérieur à 5 %, il est recommandé d’augmenter le débit. Vous pouvez déterminer quelles opérations sont lourdes, ainsi que leurs pics d’utilisation en utilisant les métriques et les journaux de diagnostic d’analyse d’Azure. Suivez les meilleures pratiques pour la mise à l’échelle du débit approvisionné (unités de requête par seconde).

Il n’est pas toujours possible d’obtenir une erreur de limitation de débit 429 simplement parce que le RU normalisé a atteint 100 %. En effet, le RU normalisé est une valeur unique qui représente l’utilisation maximale de toutes les plages de clés de partition. Une plage de clés de partition peut être occupée, mais les autres plages de clés de partition peuvent traiter les demandes sans problème. Par exemple, une opération unique, telle qu’une procédure stockée qui consomme l’ensemble des RU/s sur une plage de clés de partition, entraîne un pic dans la métrique de consommation de RU/s normalisée. Dans ce cas, il n’y aura pas d’erreurs de limitation de débit immédiates si le taux de requêtes global est faible ou si des requêtes sont effectuées sur d’autres partitions sur des plages de clés de partition différentes.

En savoir plus sur l’interprétation et le débogage des erreurs 429 de limitation de débit.

Comment surveiller les partitions actives

La métrique de consommation de RU normalisée peut être utilisée pour surveiller si votre charge de travail dispose une partition active. Une partition chaude se présente quand une ou plusieurs clés de partition logique consomment une quantité disproportionnée du nombre total de RU/s en raison d’un volume de requêtes plus élevé. Cela peut être dû à une conception de clé de partition qui ne distribue pas les requêtes de manière égale. Ainsi, de nombreuses requêtes sont redirigées vers un petit sous-ensemble de partitions logiques (ce qui implique des plages de clés de partition) devenues « hot ». Étant donné que toutes les données d’une partition logique résident sur une plage de clés de partition et que le nombre total de RU/s est réparti de façon égale entre toutes les plages de clés de partition, une partition « hot » (active) peut entraîner des erreurs 429 et une utilisation inefficace du débit.

Comment identifier s’il existe une partition active

Pour vérifier s’il existe une partition active, accédez à Insights>Débit>Consommation RU normalisée (%) par PartitionKeyRangeID. Filtrez sur une base de données et un conteneur spécifiques.

Chaque PartitionKeyRangeId correspond à une partition physique. S’il existe une partition PartitionKeyRangeId qui a une consommation de RU normalisée plus élevée que d’autres (par exemple, l’une est constamment à 100%, mais d’autres sont à 30% ou moins), cela peut être un signe d’une partition à chaud.

Pour identifier les partitions logiques qui consomment le plus de RU/s, ainsi que les solutions recommandées, consultez l'article Diagnostiquer et dépanner les exceptions de taux de requêtes trop élevé (429) d'Azure Cosmos DB.

Consommation de RU normalisée et mise à l’échelle automatique

La métrique de consommation normalisée des RU indique 100% si au moins un intervalle de clé de partition utilise toute sa capacité de RU/s allouée dans une seconde spécifique de l’intervalle de temps. Une question courante se pose alors : pourquoi la consommation de RU normalisée atteint-elle 100 %, mais qu’Azure Cosmos DB n’a pas mis à l’échelle la RU/s au débit maximal avec la mise à l’échelle automatique ?

Notes

Les informations ci-dessous décrivent l’implémentation actuelle de la mise à l’échelle automatique et peuvent être modifiées à l’avenir.

Lorsque vous utilisez la mise à l’échelle automatique, Azure Cosmos DB ne met à l’échelle le débit maximal de RU/s que lorsque la consommation de RU normalisée est de 100 % pendant une période prolongée et continue dans un intervalle de 5 secondes. Cela permet de s’assurer que la logique de mise à l’échelle est économique pour l’utilisateur, car elle garantit que les pics simples et momentanés ne conduisent pas à une mise à l’échelle inutile ou à un coût plus élevé. Lors des pics momentanés, le système est généralement mis à l’échelle jusqu’à une valeur supérieure à la valeur précédente de RU/s, mais inférieure au nombre maximal de RU/s.

Par exemple, supposons que vous disposiez d’un conteneur avec un débit maximal de mise à l’échelle automatique de 20 000 RU/s (mise à l’échelle entre 2 000 et 20 000 RU/s) et 2 plages de clés de partition. Chaque plage de clés de partition peut être mise à l’échelle entre 1 000 et 10 000 RU/s. Étant donné que la mise à l’échelle automatique approvisionne toutes les ressources requises, vous pouvez utiliser jusqu’à 20 000 RU/s à tout moment.

Supposons maintenant que vous avez un pic intermittent de trafic comme ci-dessous :

Pendant 1 seconde, la partition 1 atteint un pic à 10 000 RU/s, puis passe à 1 000 RU/s pour les 4 secondes suivantes.

Simultanément, la partition 2 monte à 8 000 RU/s, puis tombe à 1 000 RU/s pour les 4 secondes suivantes.

Voici comment les métriques se comportent :

La consommation normalisée des RU (qui indique l'utilisation maximale durant tout l'intervalle parmi toutes les partitions) affichera une utilisation de 100%, car la partition 1 a atteint son maximum pendant 1 seconde.

Toutefois, les métriques du débit approvisionné et les métriques RU à mise à l’échelle automatique ne sont pas mises à l’échelle jusqu’à un nombre maximal de RU/s simplement en raison d’un pic de 1 seconde. Il est ajusté en fonction d'une période de 5 secondes afin d'optimiser les coûts. Par conséquent, pour l’exemple ci-dessus, la consommation de partition 1 et de partition 2 RU n’atteint pas 10 000 RU/s en fonction de l’intervalle de 5 secondes.

Par conséquent, même si la mise à l’échelle automatique n’a pas été mise à l’échelle maximale, vous avez pu utiliser la totalité des RU/s disponibles pour la seconde en question. Pour vérifier votre consommation de RU/s, vous pouvez utiliser les journaux de diagnostic des fonctionnalités d’acceptation pour interroger la consommation globale de RU/s par seconde dans toutes les plages de clés de partition.

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

En général, pour une charge de travail de production à l’aide de la mise à l’échelle automatique, si vous constatez entre 1 % et 5 % de requêtes avec des erreurs 429 et que la latence de bout en bout est acceptable, il s’agit d’un signe sain que les RU/s sont pleinement utilisées. Même si la consommation normalisée de RU atteint parfois 100 % et que la mise à l’échelle automatique n’est pas mise à l’échelle jusqu’à la valeur de RU/s maximale, cela est correct, car le taux global des erreurs 429 est faible. Aucune action n'est requise.

Conseil

Si vous utilisez la mise à l’échelle automatique et que la consommation de RU normalisée est de 100 % et que vous êtes constamment mis à l’échelle vers le nombre maximal de RU/s, cela signifie que l’utilisation du débit manuel peut être plus rentable. Pour déterminer si la mise à l’échelle automatique ou le débit manuel est optimale pour votre charge de travail, consultez comment choisir entre le débit standard (manuel) et le débit approvisionné automatiquement. Azure Cosmos DB envoie également des recommandations Azure Advisor en fonction de vos modèles de charge de travail pour recommander le débit manuel ou de mise à l’échelle automatique.

Afficher la métrique de consommation d’unités de requête normalisée

1. Connectez-vous au portail Azure.

2. Sélectionnez Surveillance dans la barre de navigation gauche, puis sélectionnez Métriques.

   

3. À partir du volet Métriques>Sélectionner une ressource> choisissez l’abonnement exigé, puis Groupe de ressources. Pour le Type de ressource, sélectionnez Comptes Azure Cosmos DB, choisissez un de vos comptes Azure Cosmos DB existants, puis sélectionnez Appliquer.

   

4. Ensuite, vous pouvez sélectionner une métrique dans la liste des métriques disponibles. Vous pouvez sélectionner des métriques propres aux unités de requête, au stockage, à la latence, à la disponibilité, à Cassandra, etc. Pour découvrir de plus près toutes les métriques disponibles dans cette liste, consultez l’article Métriques par catégorie. Dans cet exemple, nous allons sélectionner la métrique Normalized RU Consumption (Consommation d’unités de requête normalisée) et la valeur d’agrégation Max.

   En plus de ces détails, vous pouvez également sélectionner l’intervalle de temps et la granularité temporelle des métriques. Au maximum, vous pouvez voir les métriques des 30 derniers jours. Une fois que vous avez appliqué le filtre, un graphique s’affiche.

   

Filtres pour la métrique de consommation de RU normalisée

Vous pouvez également filtrer les métriques et le graphique affiché par une valeur CollectionName, DatabaseName, PartitionKeyRangeID, et Region spécifique. Pour filtrer les métriques, sélectionnez Add filter (Ajouter un filtre), puis choisissez la propriété requise, par exemple CollectionName, ainsi que la valeur correspondante qui vous intéresse. Le graphique affiche ensuite les métriques de consommation d’unités de requête normalisée pour le conteneur pour la période sélectionnée.

Vous pouvez regrouper des métriques à l’aide de l’option Appliquer la division. Pour les bases de données à débit partagé, la métrique des RU normalisées indique uniquement les données à la granularité de la base de données, elle n’affiche aucune donnée par collection. Par conséquent, pour la base de données à débit partagé, vous ne verrez aucune donnée lorsque vous appliquerez le fractionnement par nom de collection.

La métrique de consommation des unités de requête normalisées pour chaque conteneur s’affiche comme indiqué dans l’image suivante :

Étapes suivantes

• Superviser les données d’Azure Cosmos DB en utilisant des paramètres de diagnostic dans Azure.
• Guide pratique pour auditer les opérations de plan de contrôle Azure Cosmos DB
• Diagnostiquer et résoudre des problèmes liés aux exceptions Taux de requêtes Azure Cosmos DB trop élevé (429)