Gérer les coûts d'alerte

Vous pouvez gérer les coûts de vos règles d'alerte Cloud Monitoring en regroupant les règles et en limitant le nombre de points de série temporelle renvoyés par vos requêtes. Pour réduire le nombre de points renvoyés, vous pouvez agréger et filtrer les séries temporelles surveillées, et ajuster les intervalles d'évaluation PromQL. Vous pouvez également consulter l'estimation de votre facture à mesure que vous modifiez les paramètres des règles.

Pour en savoir plus sur le modèle de tarification, consultez Tarifs de Google Cloud Observability et Exemples de tarifs pour les 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é change 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 la requête de la 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.

    Le langage MQL est obsolète. Les demandes d'assistance pour le débogage des problèmes de facturation peuvent être refusées par Cloud Customer Care.

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

Les alertes sont facturées en fonction du nombre de références de métriques. 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 ayez 100 VM. Chaque VM génère un point chaque minute pour le type de métrique my_metric. Voici deux façons différentes 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 renvoient 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 ayez 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 configurer d'alertes pour les données brutes 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 définition 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 définissez des alertes sur des données brutes, vous risquez également d'obtenir plus de points 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 à 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 alertes et les coûts 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 taguer les composants avec des catégories, 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 les plus élevés 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 de recevoir des alertes incorrectes, par exemple :

  • Si plus de N points dépassent votre seuil, vous manquerez des données en dehors des N premiers points.
  • Si un point non conforme se trouve en dehors des N premiers points, vos alertes peuvent se fermer automatiquement, même si les points exclus dépassent toujours le seuil.
  • Il est possible que vos requêtes de conditions ne vous fournissent pas de contexte important, comme des points de référence qui fonctionnent comme prévu.

Pour atténuer ces risques, choisissez de grandes valeurs 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 alertes 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 au moins 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.