Cette page explique comment optimiser et surveiller vos coûts Google Cloud Observability. Pour en savoir plus sur la tarification, 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 le stockage de vos journaux
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 routage de certains journaux. Les filtres d'exclusion peuvent supprimer toutes les entrées de journal correspondant au filtre ou seulement un pourcentage des journaux. Lorsqu'une entrée de journal correspond à un filtre d'exclusion d'un récepteur, le récepteur n'achemine pas l'entrée de journal vers la destination. Les entrées de journaux exclues ne sont pas comptabilisées dans votre quota de stockage. Pour savoir comment configurer des filtres d'exclusion, consultez Exclusions de journaux.
Pour réduire vos coûts de stockage Cloud Logging, vous pouvez également acheminer les journaux hors de Cloud Logging vers une destination compatible. Cloud Logging ne facture pas le routage des journaux vers les destinations compatibles. Toutefois, des frais peuvent vous être facturés lorsque les journaux sont reçus par une destination :
Pour savoir comment acheminer des journaux en dehors de Cloud Logging, 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. Pour connaître le tarif actuel, consultez le tableau récapitulatif des tarifs de Managed Service pour Prometheus ou des tarifs de Monitoring.
Réduire votre utilisation des traces
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
À 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 Tarifs des alertes.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_namecomporte un libellé avec 10 valeurs.
- Une condition d'alerte
- Les conditions sont agrégées au niveau de la VM
- Période d'exécution de 30 secondes
- 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_namecomporte un libellé avec 10 valeurs.
- 100 conditions
- Chaque condition est filtrée et agrégée à une VM.
- Période d'exécution de 30 secondes
- 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 définir 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_namecomporte un libellé avec 10 valeurs.
- Une condition d'alerte
- Les conditions sont agrégées au niveau de la VM
- Période d'exécution de 30 secondes
- 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_namecomporte un libellé avec 10 valeurs.
- Une condition
- Agrégation des conditions au niveau du service
- Période d'exécution de 30 secondes
- 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_namecomporte 100 étiquettes avec 1 000 valeurs chacune.
- Une condition
- Les conditions sont agrégées au niveau de la VM
- Période d'exécution de 30 secondes
- 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 dans l'exemple 5 est 10 000 fois supérieure à celle de la métrique dans 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 é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 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 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 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 ou MQL, vous pouvez utiliser un opérateur de flux principaux 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 recevoir des alertes erronées, 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 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 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.
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 | Aucun |
| 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 à la page Définir des budgets et des alertes de budget.