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.
Consolider les règles d'alerte pour qu'elles s'appliquent à davantage de ressources
Les alertes sont facturées par condition. C'est pourquoi, dans la mesure du possible, utilisez 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 une série temporelle pour le type de métrique my_metric. Voici deux façons différentes de surveiller la série temporelle :
Vous créez une règle d'alerte avec une seule condition. La condition surveille
my_metricet agrège les données au niveau de la VM. Après l'agrégation, il existe une série temporelle pour chaque VM. La condition surveille donc 100 séries temporelles.Vous créez 100 règles d'alerte, chacune contenant une condition. Chaque condition surveille la série temporelle
my_metricpour l'une des VM et agrège les données au niveau de la VM. Par conséquent, chaque condition surveille une série temporelle.
La deuxième option, qui crée 100 conditions, est plus coûteuse que la première, qui n'en crée qu'une. Les deux options surveillent 100 séries temporelles.
N'agrégez les données qu'au niveau pour lequel vous souhaitez configurer des alertes.
Chaque série temporelle surveillée par une règle d'alerte entraîne des frais. 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.
Par exemple, supposons que vous disposiez de 100 VM. Chaque VM génère une série temporelle 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, il existe une série temporelle pour chaque service. La condition surveille donc cinq séries temporelles.
Vous agrégez les données au niveau de la VM. Après l'agrégation, il existe une série temporelle pour chaque VM. La condition surveille donc 100 séries temporelles.
La deuxième option, qui surveille 100 séries temporelles, est plus coûteuse que la première, qui n'en surveille que cinq.
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'alertes sur 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 x 10 x 10 = 10 000.
En raison de la façon dont la cardinalité est mise à l'échelle, la configuration 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 :
- PromQL :
topk
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.
- Il est possible que vos requêtes de conditions ne vous fournissent pas de contexte important, comme les 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.