Conservation et latence des données métriques

Savoir combien de temps Cloud Monitoring conserve les données de métriques et à quelle vitesse les points échantillonnés deviennent visibles vous aide à définir des intervalles de requête précis, à configurer l'autoscaling et à interpréter le moment où les alertes sont déclenchées. Les périodes de conservation et la latence d'ingestion varient selon le type et la source de la métrique. Pour connaître les seuils de stockage et d'ingestion associés, consultez Quotas et limites.

Conservation des données de métriques

Cloud Monitoring acquiert des données de métriques et les conserve dans la série temporelle des types de métriques pendant une période donnée. Cette période varie selon le type de métrique. Pour en savoir plus, consultez Conservation des données.

À la fin de cette période, Cloud Monitoring supprime les points de données arrivés à expiration.

Lorsque tous les points d'une série temporelle ont expiré, Cloud Monitoring supprime la série temporelle. Les séries temporelles supprimées n'apparaissent pas dans les graphiques Cloud Monitoring ni dans les résultats de l'API Monitoring.

Latence des données de métriques

La latence correspond au délai entre le moment où Cloud Monitoring échantillonne une métrique et celui où le point de données de la métrique devient visible en tant que données de série temporelle. La latence dépend du fait que la métrique provient d'un service Google Cloud ou qu'elle est définie par l'utilisateur :
  • Google Cloud metrics : la liste des métriquesGoogle Cloud inclut les types de métriques des services Google Cloud . Bon nombre de ces descriptions incluent une instruction telle que : "Échantillonné toutes les 60 secondes. Après échantillonnage, les données ne sont pas visibles pendant un délai pouvant atteindre 240 secondes."

    Les valeurs de l'instruction varient en fonction des métriques. L'exemple d'instruction signifie que Cloud Monitoring collecte une mesure par minute (intervalle d'échantillonnage), mais comme certaines de ces métriques font l'objet d'un traitement supplémentaire avant d'être exposées, il peut s'écouler un certain temps (latence) avant que vous puissiez récupérer les données de cette métrique. Dans cet exemple, la latence peut atteindre quatre minutes. Par conséquent, le code temporel enregistrant l'heure de collecte peut dater de quatre minutes pour cette métrique. Cette latence ne s'applique pas aux métriques définies par l'utilisateur.

  • Métriques définies par l'utilisateur : si vous écrivez des données dans des métriques définies par l'utilisateur, y compris des métriques personnalisées, des métriques collectées par OpenTelemetry, des métriques d'application collectées par l'agent Ops et des métriques Prometheus, les données de ces métriques sont généralement visibles et interrogeables en 3 à 7 secondes, hors latence du réseau.

Dans certains cas, vous devrez peut-être ajuster la façon dont vous utilisez une métrique en fonction de sa latence. Exemple :

  • Lorsque vous utilisez des bibliothèques clientes pour récupérer des données de métriques, vous devrez peut-être utiliser un décalage dans l'intervalle de requête pour tenir compte de la latence.

  • Lorsque vous utilisez une métrique pour gérer les ressources, par exemple l'autoscaling, la latence de la métrique peut affecter la réactivité de l'autoscaling. Par exemple, certaines métriques Pub/Sub ont des latences comprises entre deux et quatre minutes.

  • Lorsque vous utilisez des règles d'alerte, sachez que la latence peut affecter le temps de création des alertes pour les règles d'alerte basées sur des métriques. Par exemple, si une métrique surveillée présente une latence pouvant atteindre 180 secondes, Cloud Monitoring ne crée pas d'alerte pendant un délai pouvant atteindre 180 secondes après que la métrique a dépassé le seuil de la condition de la règle d'alerte. Cloud Monitoring tient automatiquement compte de la latence, le cas échéant, de la métrique sous-jacente lors de l'évaluation des règles d'alerte.

Ne vous fiez pas aux valeurs des libellés de métadonnées de ressources définis par le système ou l'utilisateur lorsque vous sélectionnez des séries temporelles pour des règles d'alerte sensibles ou pour d'autres opérations réactives telles que l'autoscaling. Utilisez plutôt les valeurs des libellés définis par les types de ressources surveillées.

Les étiquettes de métadonnées de ressources sont ajoutées de manière asynchrone aux séries temporelles et ne sont pas soumises aux mêmes attentes de latence que les valeurs des étiquettes définies par les types de métriques ou les types de ressources surveillées. Par conséquent, une règle d'alerte ou une autre opération réactive qui dépend de valeurs de métadonnées pour déclencher une action peut se comporter de manière erratique si le remplissage des libellés de métadonnées de ressource est retardé.