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é pour vous.
La section 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 arrivés à expiration.
Lorsque tous les points d'une série temporelle ont expiré, Cloud Monitoring la supprime. 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 désigne le délai entre l'échantillonnage d'une métrique par Cloud Monitoring et le moment où le point de données de la métrique devient visible en tant que données de séries temporelles. La latence dépend de la nature de la métrique (provenant d'un service Google Cloud ou 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. La plupart de ces descriptions incluent une instruction comme celle-ci : "É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 indiquées dans le relevé varient en fonction de critères spécifiques. Cet 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, la récupération des données pour cette métrique peut prendre plus de temps (latence). Dans cet exemple, la latence peut atteindre 4 minutes. L'horodatage de l'heure de collecte peut donc dater de quatre minutes au maximum 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, 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 dans les trois à sept secondes, à l'exclusion de la latence réseau.
Dans certains cas, vous devrez peut-être ajuster la façon dont vous utilisez une métrique avec une 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 la gestion des ressources, par exemple 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 de 2 à 4 minutes.
Lorsque vous utilisez des règles d'alerte, sachez que la latence peut affecter le temps de création des incidents pour les règles d'alerte basées sur les métriques. Par exemple, si une métrique surveillée a une latence allant jusqu'à 180 secondes, Cloud Monitoring ne crée pas d'incident pendant une durée maximale de 180 secondes après que la métrique a enfreint le seuil de la condition de 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.