Gérer les coûts d'alerte

Ce document décrit les stratégies que vous pouvez utiliser pour réduire les coûts liés aux alertes. Pour en savoir plus sur le modèle de tarification, consultez Tarifs de Google Cloud Observability et Exemples de tarification des alertes.

Consulter votre facture estimée à l'aide du simulateur de coût intégré à l'interface utilisateur

Lorsque vous créez ou modifiez une règle d'alerte, Cloud Alerting affiche le coût estimé de la règle. Vous pouvez utiliser ce simulateur pour voir comment votre coût estimé évolue lorsque vous modifiez les paramètres de votre règle d'alerte.

Utiliser l'explorateur de métriques pour vérifier le nombre de points renvoyés

Le nombre de points renvoyés par la requête de la règle d'alerte dépend principalement de la cardinalité de la sortie de votre requête de règle d'alerte. Pour afficher la cardinalité estimée de votre règle d'alerte :

  • Pour une condition d'alerte basée sur un seuil de métrique, utilisez l'explorateur de métriques pour créer une requête identique. Ajoutez une transformation secondaire Série temporelle du nombre par Aucun.
  • Pour une condition d'alerte PromQL, copiez la requête dans l'explorateur de métriques, puis procédez comme suit :
    • Divisez votre requête en clauses distinctes en la fractionnant à chaque opérateur >, <, >=, <=, ==, !=, AND, OR et UNLESS.
    • Supprimez toute clause qui ne contient pas de métrique, comme une valeur seuil numérique.
    • Encapsulez chaque clause dans une fonction count().
    • Additionnez les résultats.

  • Pour une condition d'alerte MQL, copiez la requête dans l'explorateur de métriques. Supprimez la ligne | condition. Ajoutez une ligne | group_by [], .count à la fin.

    MQL est obsolète. Les demandes d'aide pour résoudre les problèmes de facturation peuvent être refusées par Cloud Customer Care.

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

Les alertes sont facturées au coût par référence de métrique. Chaque règle de seuil de métrique comporte une référence de métrique par condition. C'est pourquoi, dans la mesure du possible, nous vous recommandons d'utiliser une seule règle d'alerte pour surveiller plusieurs ressources au lieu de créer une règle d'alerte pour chaque ressource.

Par exemple, supposons que vous disposiez de 100 VM. Chaque VM génère un point par minute pour le type de métrique my_metric. Voici deux façons de surveiller les points renvoyés :

  • Vous créez une règle d'alerte qui comporte une condition et donc une référence de métrique. La condition surveille my_metric et agrège les données au niveau de la VM. Après l'agrégation, un point est renvoyé pour chaque VM. Par conséquent, la condition génère 100 points renvoyés par évaluation.

  • Vous créez 100 règles d'alerte, chacune contenant une condition et donc une référence de métrique. Chaque condition surveille la série temporelle my_metric pour l'une des VM et agrège les données au niveau de la VM. Par conséquent, chaque condition renvoie un point par évaluation.

La deuxième option, qui crée 100 conditions (100 références de métriques), est plus coûteuse que la première, qui ne crée qu'une seule condition (une référence de métrique). Les deux options rapportent 100 points par évaluation.

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

Un point est renvoyé pour chaque série temporelle surveillée par une règle d'alerte. 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 projetGoogle 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.

Par exemple, supposons que vous disposiez de 100 VM. Chaque VM génère un point pour le type de métrique my_metric. Chacune de vos VM appartient à l'un des cinq services. Vous décidez de créer une règle d'alerte avec une condition qui surveille my_metric. Voici deux options d'agrégation différentes :

  • Vous agrégez des données au service. Après l'agrégation, chaque exécution de règle d'alerte renvoie un point pour chaque service. La condition renvoie donc cinq points par exécution.

  • Vous agrégez les données au niveau de la VM. Après l'agrégation, chaque exécution de règle d'alerte renvoie un point pour chaque VM. La condition renvoie donc 100 points par exécution.

La deuxième option, qui renvoie 100 points par exécution, est plus coûteuse que la première, qui ne renvoie que cinq points par exécution.

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 service, vous pouvez agréger les données au niveau du service.

Ne pas créer d'alerte 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 émettant 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 configuration d'alertes sur les données brutes peut être extrêmement coûteuse. Dans l'exemple précédent, 10 000 points sont renvoyés 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 points 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'obtenir un nombre de points plus élevé 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 points renvoyés 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 points renvoyés

Si votre condition utilise une requête PromQL, vous pouvez utiliser un opérateur de flux principaux pour sélectionner un certain nombre de points renvoyés avec les valeurs les plus élevées :

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

Si vous limitez le nombre de points, vous risquez de manquer des données et d'obtenir des incidents incorrects, par exemple :

  • Si plus de N points dépassent votre seuil, vous manquerez des données en dehors des N points les plus élevés.
  • Si un point non conforme se trouve en dehors des N points les plus élevés, vos incidents peuvent se fermer automatiquement même si les points exclus dépassent toujours le seuil.
  • Vos requêtes sur les conditions peuvent ne pas afficher de contexte important, comme les points 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, telles que 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 points renvoyés par mois plus faible. 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.

Ne pas utiliser "Ressource non spécifiée" (métriques basées sur les journaux uniquement)

Les conditions d'alerte qui utilisent des métriques basées sur les journaux vous permettent de définir "Ressource non spécifiée" comme type de ressource surveillée. Dans ce cas, votre condition d'alerte lance une requête distincte pour chaque type de ressource surveillée dans Cloud Monitoring. Étant donné que chaque requête facture un minimum d'un point renvoyé, le fait de ne pas spécifier le type de ressource entraîne une facture élevée pour les points renvoyés.

Pour réduire votre facture, choisissez un type de ressource spécifique au lieu d'utiliser "Ressource non spécifiée". Cela fonctionne, car la plupart des métriques basées sur les journaux n'apparaissent que dans un seul type de ressource. Si votre métrique basée sur les journaux apparaît dans plusieurs types de ressources, vous pouvez créer plusieurs règles d'alerte ou utiliser plusieurs conditions dans une même règle d'alerte.