Cette page explique comment optimiser et surveiller vos coûts Google Cloud Observability. Pour en savoir plus sur les tarifs, consultez la page Tarifs de Google Cloud Observability.
Les documents suivants peuvent également vous intéresser :
- Estimer vos factures
- Exemples de tarification
- Optimisez les coûts avec l'explorateur de coûts. L'explorateur de coûts fournit des visualisations actuelles et historiques des données de coûts et des métriques d'utilisation. Les données vous aident donc à identifier les opportunités d'optimisation.
Optimiser
Cette section fournit des conseils sur la façon de réduire ou d'optimiser les coûts associés à Cloud Logging, Cloud Trace et Google Cloud Managed Service pour Prometheus.
Réduire vos coûts Cloud Logging
Pour réduire les coûts de stockage Cloud Logging, configurez des filtres d'exclusion sur vos récepteurs de journaux afin d'empêcher le streaming des entrées de journaux à faible valeur dans vos buckets de journaux. Vous pouvez configurer un récepteur de journaux pour exclure toutes les entrées de journal correspondant à un filtre d'exclusion, ou pour n'en exclure qu'un pourcentage. Les entrées de journal exclues ne sont pas diffusées dans vos buckets de journaux et ne sont pas comptabilisées dans votre quota de stockage. Pour en savoir plus, consultez Filtres de récepteur de journaux.
Les coûts de stockage Cloud Logging ne s'appliquent qu'aux données de journaux stockées dans des buckets de journaux. Vous pouvez configurer vos collecteurs de journaux afin que les données de journaux ne soient pas stockées dans des buckets de journaux, mais qu'elles soient plutôt acheminées vers l'une des destinations suivantes :
Cloud Logging ne facture pas le routage des entrées de journal vers les destinations listées. Toutefois, des frais peuvent vous être facturés lorsque des entrées de journal sont reçues par une destination.
Pour en savoir plus sur le routage des données de journaux, consultez Acheminer les journaux vers des destinations compatibles.
Optimiser les coûts de Managed Service pour Prometheus
La tarification de Managed Service pour Prometheus est conçue pour être contrôlable. Étant donné que vous êtes facturé par échantillon, vous pouvez exploiter les leviers suivants pour contrôler les coûts :
Période d'échantillonnage : passer la période de scraping de métriques de 15 secondes à 60 secondes permet de réduire les coûts de 75 %, sans sacrifier la cardinalité. Vous pouvez configurer des périodes d'échantillonnage par tâche, par cible ou à l'échelle mondiale.
Filtrage : vous pouvez utiliser le filtrage pour réduire le nombre d'échantillons envoyés au datastore global du service. Pour en savoir plus, consultez Filtrer les métriques exportées. Utilisez des configurations de libellés de métriques dans votre configuration de scraping Prometheus pour supprimer des métriques au moment de l'ingestion, en fonction des correspondances d'étiquettes.
Conservez les données locales à faible valeur et à cardinalité élevée. Vous pouvez exécuter la version standard de Prometheus en même temps que le service géré, en utilisant les mêmes configurations de scraping, et conserver localement les données qui ne valent pas la peine d'être envoyées au datastore global du service.
La tarification de Managed Service pour Prometheus est conçue pour être prédictible.
Vous n'êtes pas pénalisé en cas d'histogrammes creux. Les échantillons ne sont comptabilisés que pour la première valeur non nulle, puis lorsque la valeur du bucket n est supérieure à celle du bucketn-1. Par exemple, un histogramme présentant les valeurs
10 10 13 14 14 14compte pour trois échantillons, qui correspondent respectivement au premier, au troisième et au quatrième buckets.Selon le nombre d'histogrammes que vous utilisez et ce pour quoi vous les utilisez, l'exclusion des buckets non modifiés de la tarification peut généralement entraîner une diminution de 20 à 40 % du nombre d'échantillons comptabilisés à des fins de facturation par rapport à ce qu'indiquerait le nombre absolu de buckets d'histogramme.
La facturation par échantillon fait que vous n'êtes pas pénalisé pour les conteneurs qui sont préemptifs, éphémères, ou soumis à une succession rapide de scalings à la hausse et à la baisse, tels que ceux créés par HPA ou GKE Autopilot.
Si Managed Service pour Prometheus était facturé par métrique, vous payeriez pour la cardinalité d'un mois complet, en une seule fois, à chaque fois qu'un nouveau conteneur est lancé. Grâce à la tarification par échantillon, vous ne payez que lorsque le conteneur est en cours d'exécution.
Requêtes, y compris les requêtes d'alerte
Toutes les requêtes émises par l'utilisateur, y compris celles émises lors de l'exécution des règles d'enregistrement Prometheus, sont facturées via les appels d'API Cloud Monitoring.
Réduire votre utilisation de Trace
Pour contrôler le volume d'ingestion des délais Trace, vous pouvez gérer votre taux d'échantillonnage de traces afin d'équilibrer le nombre de traces dont vous avez besoin pour l'analyse des performances et le coût que vous pouvez supporter.
Pour les systèmes à fort trafic, la plupart des clients peuvent effectuer un échantillonnage à un taux de 1 transaction sur 1 000, voire 1 transaction sur 10 000, tout en bénéficiant de suffisamment d'informations pour l'analyse des performances.
Le taux d'échantillonnage est configuré avec les bibliothèques clientes Cloud Trace.
Réduire votre facture d'alertes
Cette section 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,ORetUNLESS. - 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.
- Divisez votre requête en clauses distinctes en la fractionnant à chaque opérateur
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_metricet 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_metricpour 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 :
- PromQL :
topk
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.
Surveiller
Cette section explique comment surveiller vos coûts en créant des règles d'alerte. Une règle d'alerte peut surveiller les données de métriques et vous avertir lorsque ces données dépassent un seuil.
Surveiller les octets de journaux mensuels ingérés
Pour créer une règle d'alerte qui se déclenche lorsque le nombre d'octets de journaux écrits dans vos buckets de journaux dépasse la limite définie par l'utilisateur pour Cloud Logging, utilisez les paramètres suivants.
| ChampNouvelle condition |
Valeur |
|---|---|
| Ressource et métrique | Dans le menu Ressources, sélectionnez Global. Dans le menu Catégories de métriques, sélectionnez Métrique basée sur les journaux. Dans le menu Métriques, sélectionnez Octets de journaux ingérés par mois. |
| Filter | Aucune. |
| Dans toutes les séries temporelles Agrégation de séries temporelles |
sum |
| Fenêtre glissante | 60 m |
| Fenêtrage glissant | max |
| Champ Configurer le déclencheur d'alerte |
Valeur |
|---|---|
| Type de condition | Threshold |
| Déclencheur d'alerte | Any time series violates |
| Position du seuil | Above threshold |
| Valeur du seuil | Vous définissez la valeur acceptable. |
| Fenêtre du nouveau test | La valeur minimale acceptable est de 30 minutes. |
Surveiller le nombre total de métriques ingérées
Vous ne pouvez pas créer d'alerte basée sur les métriques mensuelles ingérées. Vous pouvez toutefois en créer une pour vos frais Cloud Monitoring. Pour en savoir plus, consultez Configurer une alerte de facturation.
Surveiller les délais de trace mensuels ingérés
Pour créer une règle d'alerte qui se déclenche lorsque les délais mensuels ingérés dans Cloud Trace dépassent la limite définie par l'utilisateur, utilisez les paramètres suivants.
| ChampNouvelle condition |
Valeur |
|---|---|
| Ressource et métrique | Dans le menu Ressources, sélectionnez Global. Dans le menu Catégories de métriques, sélectionnez Facturation. Dans le menu Métriques, sélectionnez Nombre de périodes de trace mensuelles ingérées. |
| Filter | |
| Dans toutes les séries temporelles Agrégation de séries temporelles |
sum |
| Fenêtre glissante | 60 m |
| Fenêtrage glissant | max |
| Champ Configurer le déclencheur d'alerte |
Valeur |
|---|---|
| Type de condition | Threshold |
| Déclencheur d'alerte | Any time series violates |
| Position du seuil | Above threshold |
Threshold value |
Vous définissez la valeur acceptable. |
| Fenêtre du nouveau test | La valeur minimale acceptable est de 30 minutes. |
Configurer une alerte de facturation
Pour être averti si vos frais facturables ou prévus dépassent un certain budget, créez une alerte sur la page Budgets et alertes de la console Google Cloud :
-
Dans la console Google Cloud , accédez à la page Facturation :
Vous pouvez également accéder à cette page à l'aide de la barre de recherche.
Si vous possédez plusieurs compte de facturation Cloud, effectuez l'une des opérations suivantes :
- Pour gérer la facturation Cloud pour le projet en cours, sélectionnez Accéder au compte de facturation associé.
- Pour trouver un autre compte de facturation Cloud, sélectionnez Gérer les comptes de facturation et choisissez le compte pour lequel vous souhaitez définir un budget.
- Dans le menu de navigation "Facturation", sélectionnez Budgets et alertes.
- Cliquez sur Créer un budget.
- Saisissez les détails du budget dans la boîte de dialogue qui s'affiche. Elle vous permet de sélectionner des projets Google Cloud et des produits, puis de créer un budget pour cette combinaison. Par défaut, vous êtes averti lorsque vous atteignez 50 %, 90 % et 100 % du budget. Pour consulter la documentation complète, accédez à Définir des budgets et des alertes de budget.