Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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 consommation normalisée de RU est une métrique comprise entre 0% et 100% utilisée pour 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 unités de requête par seconde (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 façon égale sur toutes les plages de clés de partition, P1 et P2 peuvent chacun évoluer entre 1000 et 10 000 RU/s. Supposons dans un intervalle de 1 minute, dans une seconde donnée, P1 a consommé 6 000 ru et P2 consommé 8 000 RU. 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 l’unité de requête à un intervalle par seconde, ainsi que le type d’opération, vous pouvez utiliser les journaux de diagnostic volontaires 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 Requêtes totales Azure Monitor intégrées (API pour NoSQL), Requêtes Mongo, Demandes Gremlin ou Requêtes Cassandra . Plus tard, vous pouvez filtrer ces demandes par le code d’état 429 et les fractionner par 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 atteint 100% pour une plage de clés de partition donnée et si un client effectue toujours des requêtes dans cette fenêtre de temps de 1 seconde à cette plage de clés de partition spécifique, elle reçoit une erreur limitée par débit (429).
Cela ne signifie pas nécessairement qu’il y a un problème avec votre ressource. Par défaut, les kits SDK clients 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 demandes sur les 429. Ils réessaient généralement jusqu’à neuf fois. Par conséquent, même si vous pouvez voir 429s dans les métriques, ces erreurs n’ont peut-être même pas été retournées à votre application.
En général, pour une charge de travail de production, si vous voyez entre 1 et 5 % des requêtes avec des erreurs 429 et que votre latence de bout en bout est acceptable, il s’agit d’un signe d’intégrité indiquant que les unités de requête/s sont entièrement 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. Pour en savoir plus sur les meilleures pratiques, consultez les meilleures pratiques pour la mise à l’échelle du débit provisionné (RU/s).
Il n’est pas toujours le cas que vous voyez une erreur de limitation de taux 429 juste parce que l’unit de requête normalisée a atteint 100 %. Cela est dû au fait que la RU normalisée est une valeur unique qui représente l’utilisation maximale sur 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 seule opération telle qu’une procédure stockée qui consomme toutes les unités de requête/s sur une plage de clés de partition entraîne un court pic dans la métrique de consommation d’unité de requête normalisée. Dans ce cas, il n’existe aucune erreur de limitation de débit immédiate si le taux de requêtes global est faible ou si les requêtes sont adressées à d’autres partitions sur différentes plages de clés de partition.
Pour plus d’informations, consultez Diagnostiquer et dépanner 429 exceptions.
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. De nombreuses requêtes sont dirigées vers un petit sous-ensemble de partitions logiques (ce qui implique des plages de clés de partition) qui deviennent chaudes. Étant donné que toutes les données d'une partition logique résident sur une seule plage de clés de partition et que le nombre total de RU/s est uniformément réparti entre toutes les plages de clés de partition, une partition à chaud peut provoquer des erreurs 429 et une utilisation inefficace du débit.
Comment identifier 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, consultez Comment identifier la partition à chaud.
Consommation d’unités de requête normalisées et mise à l’échelle automatique
La métrique de consommation de RU normalisée indique 100% si au moins une plage de clés de partition utilise toutes ses RU/s allouées dans 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 ?
Remarque
Les informations suivantes décrivent l’implémentation actuelle de la mise à l’échelle automatique et peuvent être susceptibles de changer à 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 conviviale pour l’utilisateur, car elle garantit que les pics momentanés uniques ne mènent pas à une mise à l’échelle inutile et à 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 disposez d’un conteneur avec un débit maximal en autoscaling de 20 000 RU/s (s’échelonnant entre 2 000 et 20 000 RU/s) et deux 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 :
Pendant une seconde, la partition 1 atteint un pic de 10 000 RU/s, puis tombe à 1 000 RU/s pendant les quatre secondes suivantes.
Simultanément, la partition 2 atteint un pic de 8 000 RU/s, puis chute à 1 000 RU/s pendant les quatre secondes suivantes.
Voici comment les métriques se comportent :
La consommation normalisée des RU (qui indique l’utilisation maximale sur l'ensemble des partitions sur l'intervalle donné) affiche une utilisation de 100%, car la partition 1 a atteint son pic pendant une seconde.
Toutefois, le débit approvisionné et les métriques d’unité de requête mises à l’échelle ne sont pas mis à l’échelle jusqu’à un nombre maximal d’unités de requête/s 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 précédent, 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 d’unités de requête/s, vous pouvez utiliser la fonctionnalité des journaux de diagnostic volontaires pour interroger la consommation globale d’unités de requête/s à un niveau par seconde sur 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 utilisant la mise à l’échelle automatique, si vous voyez entre 1 et 5 % des requêtes avec des erreurs 429 et que votre latence de bout en bout est acceptable, il s’agit d’un signe d’intégrité indiquant que les unités de requête/s sont entièrement utilisées. Même si la consommation d’unités de requête normalisées atteint occasionnellement 100 % et que la mise à l’échelle automatique n’est pas mise à l’échelle pour atteindre le nombre maximal d’unités de requête, ce n’est pas grave, car le taux global des erreurs 429 est faible. Aucune action n'est requise.
Conseil
Si vous utilisez la mise à l’échelle automatique et constatez que la consommation d’unités de requête normalisées est de 100 % et que vous êtes constamment mis à l’échelle vers le nombre maximal d’unités de requête/s, il est possible qu’il s’agisse d’un signe indiquant que l’utilisation du débit manuel est plus économique. 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 provisionné de mise à l’échelle automatique. Azure Cosmos DB envoie également des recommandations de coût basées sur 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 Ajouter un filtre et choisissez la propriété requise telle que CollectionName et 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 :
