Comprendre la surveillance des performances dans Firestore
Cloud Monitoring collecte des métriques, des événements et des métadonnées provenant des produits Google Cloud. Les données consignées dans le tableau de bord d'utilisation et l'utilisation des règles de sécurité sont également accessibles via Cloud Monitoring pour une analyse plus détaillée. Cloud Monitoring vous permet également de configurer des tableaux de bord personnalisés et des alertes d'utilisation.
Ce document vous aide à utiliser les métriques, à vous familiariser avec le tableau de bord des métriques personnalisées et à définir des alertes.
Ressources surveillées
Dans Cloud Monitoring, une ressource surveillée représente une entité logique ou physique, telle qu'une machine virtuelle, une base de données ou une application. Les ressources surveillées contiennent un ensemble unique de métriques qui peuvent être explorées, signalées via un tableau de bord ou utilisées pour créer des alertes. Chaque ressource possède également un ensemble de libellés de ressource, qui sont des paires clé/valeur contenant des informations supplémentaires sur la ressource. Les libellés de ressource sont disponibles pour toutes les métriques associées à la ressource.
À l'aide de l'API Cloud Monitoring, les performances de Firestore sont surveillées avec les ressources suivantes:
| Ressources | Description | Mode de base de données compatible |
firestore.googleapis.com/Database (recommandée) | Type de ressource surveillée qui fournit des répartitions pour project, location* et database_id . Le libellé database_id sera (default) pour les bases de données créées sans nom spécifique. | Toutes les métriques sont compatibles avec les deux modes, à l'exception des métriques suivantes qui ne sont pas compatibles avec Firestore en mode Datastore :
|
firestore_instance | Type de ressource surveillée pour les projets Firestore et ne fournit pas de répartition pour les bases de données. | S'applique à Firestore Native |
datastore_request | Type de ressource surveillée pour les projets Datastore et ne fournit pas de répartition pour les bases de données. | S'applique aux deux modes. |
Métriques
Firestore est disponible en deux modes différents : Firestore natif et Firestore en mode Datastore. Pour comparer les fonctionnalités de ces deux modes, consultez la section Choisir entre les modes de base de données.
Pour obtenir la liste complète des métriques des deux modes, consultez les liens suivants:
Métriques d'exécution du service
Les métriques serviceruntime offrent une vue d'ensemble du trafic d'un projet. Ces métriques sont disponibles pour la plupart des API Google Cloud. Le type de ressource surveillée consumed_api contient ces métriques courantes. Ces métriques sont échantillonnées toutes les 30 minutes, ce qui permet de lisser les données.
method est un libellé de ressource important pour les métriques serviceruntime. Ce libellé représente la méthode RPC sous-jacente appelée. La méthode SDK que vous appelez ne peut pas nécessairement être nommée de la même manière que la méthode RPC sous-jacente. En effet, le SDK fournit une abstraction d'API de haut niveau. Toutefois, lorsque vous essayez de comprendre comment votre application interagit avec Firestore, il est important de comprendre les métriques basées sur le nom de la méthode RPC.
Pour connaître la méthode RPC sous-jacente d'une méthode SDK donnée, consultez la documentation de l'API.
Utilisez les métriques d'exécution de service suivantes pour surveiller votre base de données.
api/request_count
Cette métrique indique le nombre de requêtes terminées pour tous les protocoles(protocole de requête tel que http, gRPC, etc.), le code de réponse (code de réponse HTTP), response_code_class (classe de code de réponse, telle que 2xx, 4xx, etc.) et grpc_status_code (code de réponse gRPC numérique). Utilisez cette métrique pour observer la requête API globale et calculer le taux d'erreur.
La figure 1 montre les requêtes qui renvoient un code 2xx groupé par service et par méthode. Les codes 2xx sont des codes d’état HTTP qui indiquent que la requête a abouti.
Dans la figure 2, les commits regroupés par response_code sont visibles. Dans cet exemple, nous ne voyons que des réponses HTTP 200, ce qui implique que la base de données est opérationnelle.
api/request_latencies
La métrique api/request_latencies fournit la répartition de la latence entre toutes les requêtes terminées.
Firestore enregistre les métriques du composant Service Firestore. Les métriques de latence incluent le moment où Firestore reçoit la requête jusqu'au moment où Firestore a fini d'envoyer la réponse, y compris les interactions avec la couche de stockage. C'est pourquoi la latence aller-retour (rtt) entre le client et le service Firestore n'est pas prise en compte dans ces métriques.
api/request_sizes et api/response_sizes
Les métriques api/request_sizes et api/response_sizes fournissent respectivement des informations sur la taille des charges utiles (en octets). Elles peuvent être utiles pour comprendre les charges de travail d'écriture qui envoient de grandes quantités de données ou de requêtes trop larges, et renvoient des charges utiles volumineuses.
La figure 5 présente une carte de densité pour les tailles de réponse pour la méthode RunQuery.
Nous pouvons voir que les tailles sont stables, avec une médiane de 50 octets, et entre 10 octets et 100 octets. Notez que la taille des charges utiles est toujours mesurée en octets non compressés, à l'exception des frais généraux du contrôle de transmission.
Métriques des opérations sur le document
Firestore indique le nombre de lectures, d'écritures et de suppressions. La métrique d'écriture fournit une répartition entre les opérations "CREATE" et "UPDATE". Ces métriques sont alignées sur les opérations CRUD.
Les métriques suivantes peuvent être utilisées pour déterminer si votre base de données est gourmande en lecture ou en écriture, ainsi que le taux de nouveaux documents par rapport à celui de documents supprimés.
document/delete_ops_count: nombre de documents supprimésdocument/read_ops_count: nombre de lectures de documents réussies à partir de requêtes ou de recherches.document/write_ops_count: nombre d'écritures de documents réussies
La figure 6 vous montre comment créer un ratio indiquant le ratio de documents lus par rapport au nombre de documents écrits. Dans cet exemple, le nombre de documents lus est environ 6% supérieur au nombre de documents écrits.
Métriques des opérations sur le document
Ces métriques fournissent des distributions en octets de charge utile pour les lectures (recherches et requêtes) et les écritures dans une base de données Firestore. Les valeurs représentent
la taille totale de la charge utile. Par exemple, tous les résultats renvoyés par une requête.
Ces métriques sont semblables aux métriques api/request_sizes et api/response_sizes, la principale différence étant que les métriques des opérations sur les documents fournissent un échantillonnage plus précis, mais des répartitions moins précises.
Par exemple, les métriques des opérations du document utilisent la ressource surveillée datastore_request. Il n'y a donc pas de répartition des services ou des méthodes.
entity/read_sizes: répartition de la taille des documents lus.entity/write_sizes: répartition de la taille des documents écrits.
Métriques d'index
Les taux d'écriture d'index peuvent être comparés à la métrique document/write_ops_count pour comprendre le ratio de distribution de l'index.
index/write_count: nombre d'écritures d'index.
Dans la figure 7, vous pouvez comparer le taux d'écriture de l'index au taux d'écriture du document. Dans cet exemple, chaque écriture de document compte environ 6 écritures d'index, ce qui représente un taux de distribution ramifiée relativement faible.
Clients connectés directement à la base de données à l'aide des SDK Firebase
Deux métriques de jauge sont disponibles pour suivre l'activité des clients connectés directement aux bases de données Firestore via les SDK pour mobile, les SDK Web ou les deux. Ces métriques incluent une fonctionnalité liée aux écouteurs d'instantanés en temps réel lorsque les modifications pertinentes apportées à la base de données sont immédiatement renvoyées aux clients.
network/active_connections: nombre de connexions actives à un moment précis. Chaque client Web ou mobile possède une connexion.network/snapshot_listeners: nombre d'écouteurs d'instantanés actuellement enregistrés sur tous les clients connectés. Il peut y avoir plusieurs connexions par client.
Vous pouvez afficher ces métriques dans l'onglet Usage de la base de données Firestore de la console Firebase.
Métriques TTL
Les métriques TTL sont disponibles pour les bases de données Firestore natives et en mode Datastore. Utilisez ces métriques pour surveiller l'effet de la règle TTL appliquée.
document/ttl_deletion_count: nombre total de documents supprimés par les services TTL.
La figure 9 indique le taux de documents supprimés chaque minute sur une période de plusieurs jours.
document/ttl_expiration_to_deletion_delays: temps écoulé entre l'expiration d'un document doté d'une valeur TTL et sa suppression effective.
Dans la figure 10, vous pouvez voir que cette métrique fournit une répartition du temps en secondes nécessaire à Firestore pour supprimer les documents avec des stratégies TTL. La suppression des documents expirés par la valeur TTL au 99e centile prend moins de 0,5 seconde. Cela implique que le système fonctionne normalement. Firestore supprime généralement les documents arrivés à expiration dans un délai de 24 heures, mais cela n'est pas garanti. Si vous constatez que cela prend plus de 24 heures, contactez l'assistance.
Étapes suivantes
- Découvrez comment utiliser le tableau de bord Cloud Monitoring pour afficher les métriques.
- Surveillez l'utilisation pour identifier les lectures, les écritures et les suppressions de documents au fil du temps.