Gérer les coûts des alertes

À partir du 1er mai 2026 au plus tôt, Cloud Monitoring commencera à facturer l'utilisation des règles d'alerte. Pour en savoir plus sur le modèle de tarification, consultez la synthèse des tarifs de Cloud Monitoring.

Ce document décrit les stratégies que vous pouvez utiliser pour réduire les coûts liés aux alertes.

Consolider les règles d'alerte pour qu'elles s'appliquent à davantage de ressources

En raison du coût de 0,10 $par condition, il est plus rentable d'utiliser une seule règle d'alerte pour surveiller plusieurs ressources que d'utiliser une règle d'alerte pour chaque ressource. Prenons les exemples suivants :

Exemple 1

Données

  • 100 VM
  • Chaque VM émet une métrique, metric_name
  • metric_name comporte un libellé avec 10 valeurs.
Règle d'alerte
  • Une condition d'alerte
  • Les conditions sont agrégées au niveau de la VM
  • Période d'exécution de 30 secondes
Coûts résultants
  • Coût de la condition : 1 condition * 0,10 $ par mois = 0,10 $ par mois
  • Coût des séries temporelles : 100 séries temporelles renvoyées par période * 86 400 périodes par mois = 8,6 millions de séries temporelles renvoyées par mois * 0,35 $ par million de séries temporelles = 3,02 $ par mois
  • Coût total : 3,12$par mois

Exemple 2

Données

  • 100 VM
  • Chaque VM émet une métrique, metric_name
  • metric_name comporte un libellé avec 10 valeurs.
Règles d'alerte
  • 100 conditions
  • Chaque condition est filtrée et agrégée à une VM.
  • Période d'exécution de 30 secondes
Coûts résultants
  • Coût de la condition : 100 conditions * 0,10 $ par mois = 10 $par mois
  • Coût des séries temporelles : 100 conditions * 1 série temporelle renvoyée par condition et par période * 86 400 périodes par mois = 8,6 millions de séries temporelles renvoyées par mois * 0,35 $ par million de séries temporelles = 3,02 $ par mois
  • Coût total : 13,02$par mois

Dans les deux exemples, vous surveillez le même nombre de ressources. Toutefois, l'exemple 2 utilise 100 règles d'alerte, tandis que l'exemple 1 n'en utilise qu'une seule. Par conséquent, l'exemple 1 est presque 10 $moins cher par mois.

N'agrégez les données qu'au niveau pour lequel vous souhaitez configurer des alertes.

L'agrégation à des niveaux de précision plus élevés entraîne des coûts plus élevés que l'agrégation à des niveaux de précision plus faibles. Par exemple, l'agrégation au niveau du projet Google Cloud est moins coûteuse que l'agrégation au niveau du cluster, et l'agrégation au niveau du cluster est moins coûteuse que l'agrégation au niveau du cluster et de l'espace de noms.

Prenons les exemples suivants :

Exemple 1

Données

  • 100 VM
  • Chaque VM émet une métrique, metric_name
  • metric_name comporte un libellé avec 10 valeurs.
Règle d'alerte
  • Une condition d'alerte
  • Les conditions sont agrégées au niveau de la VM
  • Période d'exécution de 30 secondes
Coûts résultants
  • Coût de la condition : 1 condition * 0,10 $ par mois = 0,10 $ par mois
  • Coût des séries temporelles : 100 séries temporelles renvoyées par période * 86 400 périodes par mois = 8,6 millions de séries temporelles renvoyées par mois * 0,35 $ par million de séries temporelles = 3,02 $ par mois
  • Coût total : 3,12$par mois

Exemple 4

Données

  • 100 VM, chacune appartenant à un service
  • Cinq services au total
  • Chaque VM émet une métrique, metric_name
  • metric_name comporte un libellé avec 10 valeurs.
Règle d'alerte
  • Une condition
  • Agrégation des conditions au niveau du service
  • Période d'exécution de 30 secondes
Coûts résultants
  • Coût de la condition : 1 condition * 0,10 $ par mois = 0,10 $ par mois
  • Coût des séries temporelles : 5 séries temporelles renvoyées par période * 86 400 périodes par mois = 432 000 séries temporelles renvoyées par mois * 0,35 $ par million de séries temporelles = 0,14 $ par mois
  • Coût total : 0,24$par mois

Exemple 5

Données

  • 100 VM
  • Chaque VM émet une métrique, metric_name
  • metric_name comporte 100 étiquettes avec 1 000 valeurs chacune.
Règle d'alerte
  • Une condition
  • Les conditions sont agrégées au niveau de la VM
  • Période d'exécution de 30 secondes
Coûts résultants
  • Coût de la condition : 1 condition * 0,10 $ par mois = 0,10 $ par mois
  • Coût des séries temporelles : 100 séries temporelles renvoyées par période * 86 400 périodes par mois = 8,5 millions de séries temporelles renvoyées par mois * 0,35 $ par million de séries temporelles = 3,02 $ par mois
  • Coût total : 3,12$par mois

Comparez l'exemple 1 à l'exemple 4 : les deux exemples fonctionnent sur les mêmes données sous-jacentes et disposent d'une seule règle d'alerte. Toutefois, comme la règle d'alerte de l'exemple 4 agrège les données au niveau du service, elle est moins coûteuse que celle de l'exemple 1, qui agrège les données de manière plus précise au niveau de la VM.

De plus, comparez l'exemple 1 à l'exemple 5 : dans ce cas, la cardinalité de la métrique de l'exemple 5 est 10 000 fois supérieure à celle de l'exemple 1. Toutefois, comme les règles d'alerte des exemples 1 et 5 sont toutes deux agrégées à la VM, et que le nombre de VM est le même dans les deux exemples, les exemples sont équivalents en termes de prix.

Lorsque vous configurez vos règles d'alerte, choisissez les niveaux d'agrégation qui conviennent le mieux à votre cas d'utilisation. Par exemple, si vous souhaitez recevoir des alertes sur l'utilisation du processeur, vous pouvez agréger les données au niveau de la VM et du processeur. Si vous souhaitez recevoir des alertes sur la latence par point de terminaison, vous pouvez agréger les données au niveau du point de terminaison.

Ne pas créer d'alertes sur les données brutes et non agrégées

Monitoring utilise un système de métriques dimensionnelles, où chaque métrique a une cardinalité totale égale au nombre de ressources surveillées multiplié par le nombre de combinaisons de libellés sur cette métrique. Par exemple, si vous avez 100 VM qui émettent une métrique, et que cette métrique comporte 10 libellés avec 10 valeurs chacun, votre cardinalité totale est de 100 * 10 * 10 = 10 000.

En raison de la façon dont la cardinalité évolue, la création d'alertes sur les données brutes peut être extrêmement coûteuse. Dans l'exemple précédent, 10 000 séries temporelles sont renvoyées pour chaque période d'exécution. Toutefois, si vous agrégez les données au niveau de la VM, vous n'obtiendrez que 100 séries temporelles par période d'exécution, quelle que soit la cardinalité des libellés des données sous-jacentes.

Si vous configurez des alertes sur des données brutes, vous risquez également d'augmenter le nombre de séries temporelles lorsque vos métriques reçoivent de nouveaux libellés. Dans l'exemple précédent, si un utilisateur ajoute un libellé à votre métrique, la cardinalité totale passe à 100 * 11 * 10 = 11 000 séries temporelles. Dans ce cas, le nombre de séries temporelles renvoyées augmente de 1 000 à chaque période d'exécution,même si votre règle d'alerte reste inchangée. Si vous agrégez plutôt les données au niveau de la VM, vous n'obtiendrez que 100 séries temporelles, malgré l'augmentation de la cardinalité sous-jacente.

Filtrer les réponses inutiles

Configurez vos conditions pour n'évaluer que les données nécessaires à vos besoins en matière d'alertes. Si vous ne comptez pas prendre de mesures pour résoudre un problème, excluez-le de vos règles d'alerte. Par exemple, vous n'avez probablement pas besoin de configurer d'alerte pour la VM de développement d'un stagiaire.

Pour réduire les coûts et les incidents inutiles, vous pouvez filtrer les séries temporelles qui ne sont pas importantes. Vous pouvez utiliser des libellés de métadonnées Google Cloud pour ajouter des tags de catégories aux composants, puis filtrer les catégories de métadonnées inutiles.

Utiliser des opérateurs de flux principaux pour réduire le nombre de séries temporelles renvoyées

Si votre condition utilise une requête PromQL, vous pouvez utiliser un opérateur top-streams pour sélectionner un certain nombre de séries temporelles renvoyées avec les valeurs les plus élevées :

Par exemple, une clause topk(metric, 5) dans une requête PromQL limite le nombre de séries temporelles renvoyées à cinq pour chaque période d'exécution.

Si vous limitez le nombre de séries temporelles, vous risquez de manquer des données et de générer des incidents incorrects, par exemple :

  • Si plus de N séries temporelles dépassent votre seuil, vous manquerez des données en dehors des N premières séries temporelles.
  • Si une série temporelle non conforme se produit en dehors des N premières séries temporelles, vos incidents peuvent se fermer automatiquement même si la série temporelle exclue continue de dépasser le seuil.
  • Vos requêtes de conditions peuvent ne pas afficher de contexte important, comme des séries temporelles de référence qui fonctionnent comme prévu.

Pour atténuer ces risques, choisissez des valeurs élevées pour N et n'utilisez l'opérateur top-streams que dans les règles d'alerte qui évaluent de nombreuses séries temporelles, comme les incidents pour les conteneurs Kubernetes individuels.

Augmenter la durée de la période d'exécution (PromQL uniquement)

Si votre condition utilise une requête PromQL, vous pouvez modifier la durée de votre période d'exécution en définissant le champ evaluationInterval dans la condition.

Des intervalles d'évaluation plus longs entraînent un nombre de séries temporelles renvoyées par mois moins élevé. Par exemple, une requête de condition avec un intervalle de 15 secondes s'exécute deux fois plus souvent qu'une requête avec un intervalle de 30 secondes, et une requête avec un intervalle d'une minute s'exécute deux fois moins souvent qu'une requête avec un intervalle de 30 secondes.