Comprendre le monitoring 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 présentées dans les tableaux de bord "Utilisation" et 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 explique comment utiliser les métriques, découvrir le tableau de bord des métriques personnalisées et configurer 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, présentées dans un tableau de bord ou utilisées pour créer des alertes. Chaque ressource possède également un ensemble de libellés de ressources, qui sont des paires clé/valeur contenant des informations supplémentaires sur la ressource. Les libellés de ressources 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 à l'aide des ressources suivantes :

Ressources Description Mode de base de données compatible
firestore.googleapis.com/Database (recommandé) Type de ressource surveillée qui fournit des détails pour project, location* et database_id . Le libellé database_id sera (default) pour les bases de données créées sans nom spécifique. S'applique aux deux modes.
firestore_instance Type de ressource surveillée pour les projets Firestore. Ne fournit pas de répartition pour les bases de données. S'applique à Firestore en mode natif
datastore_request Type de ressource surveillée pour les projets Datastore. Ne fournit pas de répartition pour les bases de données. S'applique aux deux modes.

Métriques

Firestore est disponible dans deux modes différents : Firestore en mode natif et Firestore en mode Datastore. Pour comparer les fonctionnalités de ces deux modes, consultez Choisir entre les modes de base de données.

Pour obtenir la liste complète des métriques pour les deux modes, consultez les liens suivants :

Métriques d'exécution du service

Les métriques serviceruntime fournissent 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 entraîne un lissage des 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. Il est possible que la méthode SDK que vous appelez ne porte pas le même nom 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 en fonction du nom de la méthode RPC.

Si vous avez besoin de connaître la méthode RPC sous-jacente pour une méthode de 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 fournit le nombre de requêtes traitées, en fonction du protocole(protocole de requête, tel que HTTP, gRPC, etc.), du code de réponse (code de réponse HTTP), de response_code_class (classe de code de réponse, telle que 2xx, 4xx, etc.) et de grpc_status_code (code de réponse gRPC numérique). Utilisez cette métrique pour observer la requête d'API globale et calculer le taux d'erreur.

métrique api/request_count qui renvoie un code 2xx.
Figure 1 : métrique api/request_count (cliquez pour agrandir).

La figure 1 montre les requêtes qui renvoient un code 2xx, regroupées par service et par méthode. Les codes 2xx sont des codes d'état HTTP qui indiquent que la requête a abouti.

métrique api/request_count qui renvoie un code 2xx.
Figure 2 : métrique api/request_count renvoyant un code 2xx (cliquez pour agrandir).

La figure 2 montre les commits regroupés par response_code. 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 des distributions de latence pour toutes les requêtes traitées.

Firestore enregistre les métriques du composant Service Firestore. Les métriques de latence incluent le temps écoulé entre la réception de la requête par Firestore et l'envoi de la réponse par Firestore, y compris les interactions avec la couche de stockage. Par conséquent, la latence aller-retour (rtt) entre le client et le service Firestore n'est pas incluse dans ces métriques.

api/request_latencies pour calculer la distribution de la latence
Figure 4.api/request_latencies pour calculer la distribution de la latence.
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). Ces informations peuvent être utiles pour comprendre les charges de travail d'écriture qui envoient de grandes quantités de données ou les requêtes trop larges qui renvoient des charges utiles volumineuses.

Métriques api/request_sizes et api/response_sizes
Figure 5 : Métriques api/request_sizes et api/response_sizes (cliquez pour agrandir).

La figure 5 montre une carte de densité des 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 une taille globale comprise entre 10 et 100 octets. Notez que la taille de la charge utile est toujours mesurée en octets non compressés, à l'exclusion des frais généraux de contrôle de la transmission.

Métriques sur les opérations liées aux documents

Firestore fournit des nombres de lectures, d'écritures et de suppressions. La métrique d'écriture fournit une répartition entre les opérations de création et de mise à jour. 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 axée sur la lecture ou l'écriture, ainsi que le taux de nouveaux documents par rapport aux documents supprimés.

  • document/delete_ops_count : nombre de suppressions de documents réussies.
  • document/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.
Créer un ratio entre les documents lus et les documents écrits
Figure 6. Créez un ratio entre les documents lus et les documents écrits (cliquez pour agrandir).

La figure 6 montre comment créer un ratio qui indique le rapport entre les documents lus et les documents écrits. Dans cet exemple, le nombre de documents lus est environ 6 % supérieur au nombre de documents écrits.

Métriques sur les opérations liées aux documents

Ces métriques fournissent des distributions en octets des tailles 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 est que les métriques sur les opérations sur les documents fournissent un échantillonnage plus précis, mais des répartitions moins précises.

Par exemple, les métriques sur les opérations de document utilisent la ressource surveillée datastore_request. Il n'y a donc pas de répartition par service ni par méthode.

  • entity/read_sizes : distribution des tailles des documents lus.
  • entity/write_sizes : distribution des tailles 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 déploiement d'index.

  • index/write_count : nombre d'écritures d'index.
Taux d'écriture dans l'index par rapport au taux d'écriture dans les documents
Figure 7. Comparaison entre le taux d'écriture dans l'index et le taux d'écriture dans les documents (cliquez pour agrandir).

La figure 7 montre comment le taux d'écriture d'index peut être comparé au taux d'écriture de documents. Dans cet exemple, pour chaque écriture de document, il y a environ six écritures d'index, ce qui correspond à un taux de dispersion d'index relativement faible.

Clients connectés directement à la base de données à l'aide des SDK Firebase

Deux métriques de type "gauge" sont disponibles pour suivre l'activité des clients connectés directement aux bases de données Firestore via des SDK mobiles, des SDK Web ou les deux. Ces métriques incluent une fonctionnalité liée aux écouteurs d'instantanés en temps réel, où 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 donné. Chaque client Web ou mobile compte comme 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 dans la console Firebase.

Métriques permettant de suivre l'activité des clients connectés à Firestore
Figure 8. Métriques permettant de suivre l'activité des clients connectés à Firestore.

Métriques TTL

Les métriques TTL sont disponibles pour les bases de données Firestore en mode natif et Firestore en mode Datastore. Utilisez ces métriques pour surveiller l'effet de la stratégie TTL appliquée.

  • document/ttl_deletion_count : nombre total de documents supprimés par les services TTL.
Nombre total de documents supprimés par les services TTL
Figure 9. Nombre total de documents supprimés par les services TTL (cliquez pour agrandir).

La figure 9 montre 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 du délai avant suppression (TTL) d'un document et sa suppression effective.
Temps nécessaire en secondes pour que Firestore supprime les documents avec des règles TTL
Figure 10. Temps nécessaire en secondes pour que Firestore supprime les documents avec des règles TTL (cliquez pour agrandir).

La figure 10 montre que cette métrique fournit une distribution du temps en secondes qu'il a fallu à Firestore pour supprimer les documents avec des règles TTL. Il faut moins de 0,5 seconde pour supprimer les documents dont le délai avant expiration est dépassé au 99e centile. Cela signifie que le système fonctionne normalement. Firestore supprime généralement les documents expirés dans les 24 heures, mais cela n'est pas garanti. Si vous constatez que l'opération prend plus de 24 heures, contactez l'assistance.

Étapes suivantes