Comment surveiller les EF normalisées pour un conteneur Azure Cosmos DB ou un compte
S’APPLIQUE À : 
NoSQL MongoDB Cassandra Gremlin Table
Azure Monitor pour Azure Cosmos DB fournit une vue de métriques pour surveiller votre compte et créer des tableaux de bord. Cette fonctionnalité ne vous oblige pas à activer ou à configurer quoi que ce soit explicitement, car ces métriques Azure Cosmos DB sont collectées par défaut.
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 par intervalle de 1 minute et est définie comme l’utilisation maximale de 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 que, dans un intervalle de 1 minute, à une seconde donnée, P1 ait consommé 6 000 unités de requête et que P2 ait consommé 8 000 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 adressées à votre base de données ou conteneur a donné lieu à des erreurs 429, à partir de votre panneau de 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’afficher une erreur de limitation du taux d’erreur 429 simplement parce que la RU normalisée 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. Si un PartitionKeyRangeId présente une consommation RU normalisée nettement plus élevée que les autres (par exemple, l’une d’entre elles est toujours à 100 %, alors que les autres sont à 30 % ou moins), cela peut être le signe d’une partition active.
Pour identifier les partitions logiques qui consomment le plus de RU/s, ainsi que les solutions recommandées, consultez l’article Diagnostiquer et résoudre des problèmes liés aux exceptions Taux de requêtes Azure Cosmos DB trop élevé (429).
Consommation de RU normalisée et mise à l’échelle automatique
La métrique de consommation de RU normalisée s’affiche à 100 % si au moins 1 plage de clés de partition utilise toutes ses RU/s allouées à une seconde donnée dans 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 que vous ayez un pic intermittent du trafic, où, pour une seconde, l’utilisation de l’une des plages de clés de partition est de 10 000 RU/s. Pendant les secondes suivantes, l’utilisation revient à 1 000 RU/s. Étant donné que la métrique de consommation de RU normalisée affiche l’utilisation la plus élevée dans la période sur toutes les partitions, on observe une valeur de 100 %. Toutefois, étant donné que l’utilisation n’était que de 100 % pour 1 seconde, la mise à l’échelle automatique ne sera pas automatiquement mise à l’échelle au maximum.
Par conséquent, même si la mise à l’échelle automatique n’a pas été mise à l’échelle maximale, vous avez toujours été en mesure d’utiliser le total des RU/s disponibles. 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
Connectez-vous au portail Azure.
Sélectionnez Surveillance dans la barre de navigation gauche, puis sélectionnez Métriques.
À 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.
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)