Surveiller et déboguer à l’aide d’insights dans Azure Cosmos DB
S’APPLIQUE À : 
NoSQL MongoDB Cassandra Gremlin Table
Azure Cosmos DB fournit des insights concernant le débit, le stockage, la cohérence, la disponibilité et la latence. Le portail Azure fournit une vue agrégée de ces métriques. Vous pouvez également consulter des métriques Azure Cosmos DB à partir de l’API Azure Monitor. Les valeurs de dimension des métriques, comme le nom du conteneur, ne respectent pas la casse. Ainsi, vous devez utiliser une comparaison ne respectant pas la casse lorsque vous comparez des chaînes sur ces valeurs de dimension. Pour savoir comment afficher les métriques à partir d’Azure Monitor, consultez Surveiller Azure Cosmos DB.
Cet article présente des cas d’utilisation courants et montre comment utiliser les insights d’Azure Cosmos DB pour analyser et déboguer ces problèmes. Par défaut, les insights de métriques sont collectées toutes les cinq minutes et sont pendant sept jours.
Les sections suivantes décrivent des scénarios courants où vous pouvez utiliser les métriques Azure Cosmos DB.
Remarque
Lorsque vous filtrez par base de données ou collections dans les métriques, il est possible que vous voyiez « __Empty » ou « <Empty> » comme nom de la ressource. Cela est dû au fait que les données de métriques sont collectées au niveau du compte pour cette demande en particulier. Par conséquent, il n’existe aucune base de données ou collection associée comme valeur de métrique.
Connaître le nombre de requêtes ayant abouti ou ayant provoqué une erreur
Pour commencer, accédez au portail Azure, puis au volet Insights. Dans ce volet, ouvrez l’onglet Requêtes. Celui-ci affiche un graphique présentant le nombre total de requêtes segmentées par code d’état et par type d’opération. Pour plus d’informations sur les codes d’état HTTP, consultez Codes d’état HTTP pour Azure Cosmos DB.
Le code d’état d’erreur le plus courant est 429 (limitation du débit). Cette erreur signifie que les requêtes envoyées à Azure Cosmos DB sont supérieures au débit provisionné. Dans ce cas, la solution la plus courante consiste à effectuer une montée en puissance des unités de requête pour une collection donnée. Pour plus d’informations, consultez Présentation du débit approvisionné dans Azure Cosmos DB
Déterminer la consommation de débit par une plage de clés de partition
Il est essentiel d’avoir une bonne cardinalité des clés de partition pour vos applications évolutives. Pour déterminer la distribution du débit d’un conteneur partitionné, ventilée par ID de plage de clés de partition, accédez au volet Insights. Ouvrez l’onglet Débit. La consommation normalisée d’unités de requête par seconde à travers les différentes plages de clés de partition est présentée dans le graphique.
Ce graphique vous permet de déterminer s’il existe une partition chaude. PartitionKeyRangeIDs correspond aux partitions physiques. La consommation normalisée de RU est une valeur comprise entre 0 et 100 % qui permet de mesurer l’utilisation du débit provisionné d’une base de données ou d’un conteneur. Une distribution inégale du débit peut provoquer des partitions chaudes. Cela peut entraîner des limitations de requêtes et nécessiter un repartitionnement. Une fois que vous avez identifié la clé de partition à l’origine du déséquilibre de distribution, il est possible que vous deviez repartitionner votre conteneur avec une clé de partition plus distribuée. Pour plus d’informations sur le partitionnement dans Azure Cosmos DB, consultez Partitionnement et mise à l’échelle horizontale dans Azure Cosmos DB.
Déterminer l’utilisation des données et des index
Il est important de déterminer la distribution du stockage de tout conteneur partitionné par utilisation de données, d’index et de documents. Vous pouvez réduire l’utilisation des index, maximiser l’utilisation des données et optimiser vos requêtes. Pour obtenir ces données, accédez au volet Insights et ouvrez l’onglet Stockage.
Comparer la taille des données et la taille de l’index
Dans Azure Cosmos DB, la consommation totale de stockage correspond à la somme de la taille des données et de la taille de l’index. En règle générale, la taille de l’index correspond à une fraction de la taille des données. Pour plus d’informations, consultez l’article Taille de l’index. Dans le volet Métriques du portail Azure, l’onglet Stockage présente la répartition de la consommation de stockage basée sur les données et l’index.
// Measure the document size usage (which includes the index size)
ResourceResponse<DocumentCollection> collectionInfo = await client.ReadDocumentCollectionAsync(UriFactory.CreateDocumentCollectionUri("db", "coll"));
Console.WriteLine("Document size quota: {0}, usage: {1}", collectionInfo.DocumentQuota, collectionInfo.DocumentUsage);
Si vous souhaitez conserver de l’espace d’index, vous pouvez ajuster la stratégie d’indexation.
Déboguer les requêtes lentes
Dans les SDK de l’API pour NoSQL, Azure Cosmos DB fournit des statistiques relatives à l’exécution des requêtes.
IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName),
"SELECT * FROM c WHERE c.city = 'Seattle'",
new FeedOptions
{
PopulateQueryMetrics = true,
MaxItemCount = -1,
MaxDegreeOfParallelism = -1,
EnableCrossPartitionQuery = true
}).AsDocumentQuery();
FeedResponse<dynamic> result = await query.ExecuteNextAsync();
// Returns metrics by partition key range Id
IReadOnlyDictionary<string, QueryMetrics> metrics = result.QueryMetrics;
QueryMetrics fournit des informations détaillées sur la durée d’exécution de chaque composant de la requête. Les analyses sont la cause racine la plus courante des longues exécutions de requêtes. Cela signifie que la requête n’a pas pu appliquer les index. Ce problème peut être résolu avec une meilleure condition de filtre.
Superviser les demandes de plan de contrôle
Azure Cosmos DB applique des limites au nombre de demandes de métadonnées qui peuvent être effectuées à intervalles consécutifs de 5 minutes. Les demandes de plan de contrôle qui dépassent ces limites peuvent subir une limitation. Dans certains cas, les demandes de métadonnées peuvent consommer un débit par rapport à une master partition au sein d’un compte qui contient toutes les métadonnées d’un compte. Les demandes de plan de contrôle qui dépassent la quantité de débit subissent une limitation du débit (429 s).
Pour commencer, accédez au portail Azure, puis au volet Insights. Dans ce volet, ouvrez l’onglet Système. L’onglet Système affiche deux graphiques. Un qui affiche toutes les demandes de métadonnées pour un compte. Le second montre la consommation de débit des demandes de métadonnées à partir du master partition du compte qui stocke les métadonnées d’un compte.
Le graphique Demande de métadonnées par code d’état ci-dessus agrège les demandes à une granularité accrue à mesure que vous augmentez l’intervalle de temps. Le plus grand intervalle de temps que vous pouvez utiliser pour une classe de temps de 5 minutes est de 4 heures. Pour superviser les demandes de métadonnées sur un intervalle de temps plus large avec une granularité spécifique, utilisez les métriques Azure. Créez un graphique et sélectionnez la métrique Demandes de métadonnées. Dans le coin supérieur droit, sélectionnez une granularité temporelle de 5 minutes, comme indiqué ci-dessous. Les métriques permettent également aux utilisateurs de créer des alertes sur eux, ce qui les rend plus utiles que les insights.
Étapes suivantes
Vous pouvez en savoir plus sur l’amélioration des performances de bases de données en lisant les articles suivants :