Conservation et latence des données métriques

Cette page fournit des informations sur la durée pendant laquelle Cloud Monitoring conserve vos données de métriques, ainsi que sur la latence entre la collecte des données et leur visibilité.

La page Quotas et limites fournit des informations supplémentaires sur les limites des données de métriques.

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 en fonction du type de métrique. Pour en savoir plus, consultez la section Conservation des données.

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

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

Latence : 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 de la métrique, qui peut être issue d'un service Google Cloud ou d'une métrique définie par l'utilisateur :
  • Métriques Google Cloud : la liste des métriques Google Cloud inclut les types de métriques des services Google Cloud. Nombre d'entre elles les descriptions incluent une déclaration comme celle-ci : "Échantillonné chaque 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 pour certaines métriques. L'exemple d'instruction signifie que Cloud Monitoring collecte une mesure par minute (l'intervalle d'échantillonnage), mais comme certaines de ces métriques reçoivent un traitement supplémentaire avant d'être exposées, la récupération des données pour cette métrique peut prendre plus de temps (latence). Dans cet exemple, la latence peut atteindre quatre minutes. L'horodatage de la collecte peut donc remonter jusqu'à 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 sous trois à sept secondes, sans compter la latence réseau.

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

  • Lorsque vous utilisez des bibliothèques clientes pour récupérer des données de métrique, 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, comme lors de 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 2 et 4 minutes.

  • Lorsque vous utilisez des règles d'alerte, sachez que la latence peut avoir une incidence sur les de création des règles d'alerte basées sur les métriques. Par exemple, si une métrique surveillée a une latence maximale de 180 secondes, Cloud Monitoring ne crée pas d'incident pendant 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, du la métrique sous-jacente lors de l'évaluation des règles d'alerte.