Tarifs de Cloud Monitoring

Les tarifs de Google Cloud Observability vous permettent de contrôler votre utilisation et les dépenses. Les produits d'observabilité Google Cloud sont facturés en fonction du volume de données ou sur l'utilisation de l'IA générative. Vous pouvez utiliser les attributions gratuites de consommation des données pour vous lancer de frais ou d'engagements initiaux.

Les tableaux suivants récapitulent les informations tarifaires pour Cloud Logging, Cloud Monitoring et Cloud Trace.

Synthèse des tarifs Cloud Logging

Caractéristique	Prix^1	Attribution gratuite par mois
Stockage Logging^*	0,50 $/Gio Frais uniques pour la diffusion des journaux dans le stockage en bucket de journaux à des fins d'indexation, d'interrogation, et l'analyse ; et inclut jusqu'à 30 jours de stockage dans des buckets de journaux. Aucuns frais supplémentaires ne sont facturés pour l'interrogation et l'analyse des données de journaux.	50 premiers Gio/projet/mois
Conservation des données Logging^†	0,01 $ par Gio et par mois pour les journaux conservés plus de 30 jours. Facturation mensuelle en fonction de la durée de conservation.	Les journaux conservés pendant la durée de conservation par défaut n'entraînent aucuns frais de conservation.
Routeur de journaux^‡	Aucuns frais supplémentaires	Non applicable
Analyses de journaux^♣	Aucuns frais supplémentaires	Non applicable

^* Le volume de stockage comptabilise la taille réelle des entrées de journal avant l'indexation. Il n'y a aucuns frais de stockage pour les journaux stockés Bucket de journaux _Required.
^† Aucuns frais de conservation ne s'appliquent aux journaux stockés dans le bucket de journaux _Required. qui a une durée de conservation fixe de 400 jours.
^‡ Le routage des journaux consiste à transférer les journaux reçus via l'API Cloud Logging vers destination acceptée. Des frais de destination peuvent s'appliquer aux journaux acheminés.
^♣ Vous pouvez mettre à niveau un bucket de journaux pour utiliser l'Analyse de journaux ou émettre des requêtes SQL sans frais. sur la page Analyse de journaux.
Remarque: Le langage relatif aux tarifs de Cloud Logging a été modifié le 19 juillet 2023. Toutefois, les attributions gratuites et les tarifs n'ont pas changé. Votre facture peut faire référence à l'ancien langue de tarification.

Synthèse des tarifs Cloud Monitoring

Caractéristique	Tarif	Attribution gratuite par mois	Date d'entrée en vigueur
Toutes les données Monitoring à l'exception des données ingérées à l'aide de Managed Service pour Prometheus	0,2580 $/Mio^1 : 150 à 100 000 premiers Mio 0,1510 $/Mio : 100 000 à 250 000 Mio suivants 0,0610 $/Mio : > 250 000 Mio	Toutes les métriques Google Cloud non facturables 150 premiers Mio par compte de facturation pour métriques facturées par octets ingérés	1er juillet 2018
Métriques ingérées à l'aide de Google Cloud Managed Service pour Prometheus, y compris Métriques du plan de contrôle GKE	0,06 $/million d'échantillons^†: 0 à 50 milliards d'échantillons ingérés^† 0,048 $/million d'échantillons: les 50 à 250 milliards suivants d'échantillons ingérés 0,036 $/million d'échantillons: 250 à 500 milliards d'échantillons ingérés suivants 0,024 $/million d'échantillons : plus de 500 milliards d'échantillons ingérés	Non applicable	8 août 2023
Appels d'API Monitoring	0,01 $/1 000 appels d'API en lecture Les appels d'API en écriture sont gratuits.	Premier million d'appels d'API en lecture inclus (par compte de facturation)	1er juillet 2018
l'exécution de tests de disponibilité Monitoring ;	0,30 $/1 000 exécutions^‡	1 million d'exécutions par projet Google Cloud	1er octobre 2022
Exécution de Surveiller les moniteurs synthétiques	1,20 $/1 000 exécutions^*	100 exécutions par compte de facturation	1er novembre 2023
Règles d'alerte	1,50 $ par mois pour chaque condition d'une règle d'alerte 0,35 $ pour 1 000 000 de séries temporelles renvoyées par la requête d'une condition de règle d'alerte pour les métriques^♣	Non applicable	7 janvier 2025

^† Google Cloud Managed Service pour Prometheus utilise Stockage Cloud Monitoring pour les données de métriques créées en externe et leurs utilisations l'API Monitoring pour récupérer ces données. les outils de mesure Managed Service pour Prometheus basés sur des échantillons ingérés plutôt que sur d'octets pour s'aligner sur conventions. Pour en savoir plus sur la mesure basée sur les échantillons, consultez la section Tarifs pour la contrôlabilité et la prédictibilité. Pour obtenir des exemples de calcul, consultez la section Exemples de tarification basés sur les échantillons ingérés.
^# Les échantillons sont comptabilisés par compte de facturation.
^‡ Les exécutions sont facturées sur le compte de facturation dans lequel elles sont définies. Pour en savoir plus, consultez Tarification de l'exécution des tests de disponibilité.
^* Les exécutions sont facturées sur le compte de facturation dans lequel elles sont définies. Pour chaque exécution, des frais supplémentaires peuvent vous être facturés par d'autres services Google Cloud, y compris des services tels que Cloud Functions, Cloud Storage et Cloud Logging. Pour en savoir plus sur ces frais supplémentaires, consultez la documentation sur les tarifs du service Google Cloud concerné.
^♣ Pour en savoir plus, consultez Tarifs pour les alertes.

Synthèse des tarifs Cloud Trace

Caractéristique	Tarif	Attribution gratuite par mois	Date d'entrée en vigueur
Ingestion Trace	0,20 $/million de délais	2,5 premiers millions de segments par compte de facturation	1er novembre 2018

Pour en savoir plus sur les coûts des produits d'observabilité Google Cloud, consultez la page les sections suivantes de cette page:

• Cloud Logging
• Cloud Monitoring
• Error Reporting
• Cloud Profiler
• Cloud Trace

Pour en savoir plus sur les tarifs de GKE Enterprise, consultez GKE Enterprise

Afficher les données d'utilisation

Pour consulter votre utilisation actuelle, accédez à la page Rapports Cloud Billing. de la console Google Cloud

Accéder à Cloud Billing

En fonction de ces données d'utilisation, vous pouvez estimer le montant de vos factures à l'aide du Simulateur de coût.

Prenons l'exemple d'une configuration dans laquelle chaque instance de VM Compute Engine génère 10 Gio de journaux payants et 20 Mio de métriques facturables par mois. Le Simulateur de coût vous permet de prévoir les coûts liés à Cloud Monitoring et Cloud Logging :

	1 VM	10 VM	100 VM	1 000 VM
Coût des métriques par mois	0,00 $	12,90 $	477,30 $	5 121,30 $
Coût de la journalisation par mois	0,00 $	25,00 $	475,00 $	4 975,00 $
Coût total	0,00 $	37,90 $	952,30 $	10 096,30 $

Configurer une alerte de facturation

Pour être averti si vos frais facturables ou prévus dépassent un budget, Créez une alerte depuis la page Budgets et alertes de la console Google Cloud:

1. Dans la console Google Cloud, accédez à la page Facturation.

   Accéder à 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.
2. Dans le menu de navigation "Facturation", sélectionnez Budgets et alertes.
3. Cliquez sur  Créer un budget.
4. Saisissez les détails du budget dans la boîte de dialogue qui s'affiche. Elle vous permet de sélectionner des projets et des produits Google Cloud, 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.
   Remarque:Dans la boîte de dialogue de facturation, utilisez les paramètres suivants:

   • Pour créer une alerte sur l'utilisation de Cloud Logging, sélectionnez Cloud Logging.
   • Pour créer une alerte sur l'utilisation de Cloud Monitoring, sélectionnez Stackdriver Monitoring.
   • Pour créer une alerte sur l'utilisation de Cloud Trace, sélectionnez Stackdriver Trace.

Cloud Logging

Les buckets de journaux sont les conteneurs Logging qui stockent les données de journaux. Logging facture le volume de données de journaux stocké dans le bucket de journaux _Default et dans les buckets de journaux définis par l'utilisateur, lorsque ce volume dépasse attribution mensuelle gratuite. Pour le bucket de journaux _Default et pour les buckets de journaux définis par l'utilisateur, Logging facture également lorsque les journaux sont conservées plus longtemps que la durée de conservation par défaut, qui est de 30 jours.

Logging ne facture pas de frais supplémentaires pour acheminer les journaux, pour utiliser l'API Cloud Logging, ou, pour les journaux stockés dans le bucket de journaux _Required, qui a une durée de conservation fixe de 400 jours.

Cette section fournit des informations sur les sujets suivants:

• Modèle de stockage Cloud Logging
• Tarifs du stockage
• Tarifs de conservation
• Réduire le stockage des journaux
• Tarifs des métriques basées sur les journaux
• Créer une règle d'alerte sur les octets de journaux mensuels ingérés

Pour obtenir un résumé des informations tarifaires, consultez Récapitulatif des tarifs de Cloud Logging

Pour connaître les limites qui s'appliquent à votre utilisation de Logging, y compris celles concernant la durée de conservation des données, consultez la page Quotas et limites.

Pour afficher et comprendre vos données d'utilisation Cloud Logging, consultez la page Estimer vos factures.

Modèle de stockage Cloud Logging

Pour chaque projet Google Cloud, Logging crée deux buckets de journaux: _Required et _Default. Pour ces deux buckets, Logging crée automatiquement des récepteurs de journaux nommé _Required et _Default, qui acheminent les journaux vers l'instance les buckets de journaux. Vous ne pouvez ni désactiver, ni modifier le récepteur _Required. Vous pouvez désactiver ou modifier le récepteur _Default pour empêcher le bucket _Default de le stockage de nouveaux journaux.

Vous pouvez Créer des buckets de journaux définis par l'utilisateur dans n'importe lequel de vos projets Google Cloud. Vous pouvez aussi configurer des récepteurs n'importe quelle combinaison de journaux, même sur les projets Google Cloud de votre organisation Google Cloud à ces buckets de journaux.

Pour le bucket de journaux _Default et pour les buckets de journaux définis par l'utilisateur, vous pouvez configurer une durée de conservation personnalisée.

Vous pouvez mettre à niveau vos buckets de journaux Analyse de journaux : La mise à niveau d'un bucket de journaux pour utiliser l'Analyse de journaux n'entraîne aucuns frais.

Pour en savoir plus sur les buckets et récepteurs Cloud Logging, consultez la page Présentation du routage et du stockage

Tarifs de stockage

Logging ne facture pas les journaux stockés dans le bucket _Required. Vous ne pouvez pas supprimer le bucket _Required ni modifier le récepteur _Required. Le bucket _Required stocke les journaux suivants:

• Journaux d'audit pour les activités d'administration
• Journaux d'audit d'événements système
• Journaux d'audit des administrateurs Google Workspace
• Journaux d'audit des groupes Enterprise
• Journaux d'audit de connexion
• Les journaux Access Transparency. Pour en savoir plus sur l'activation des journaux Access Transparency, consultez la Documentation sur les journaux Access Transparency

Remarque :Si vous acheminez des copies de journaux qui sont automatiquement stockées dans _Required vers un autre bucket de journaux, puis stocker et des tarifs de conservation s'appliquent.

Logging facture le volume de données de journaux préindexé stocké dans le bucket de journaux _Default et dans des buckets de journaux définis par l'utilisateur, lorsque le volume total dépasse l'attribution mensuelle gratuite. Chaque écriture d'une entrée de journal dans le bucket de journaux _Default ou dans une le bucket de journaux défini par l'utilisateur est comptabilisé dans votre quota d'attribution de stockage. Par exemple, si vous disposez de récepteurs acheminant une entrée de journal vers l'entrée de journal est stockée trois fois.

Tarification de la conservation

Remarque : Efficace Coûts de conservation du 1er avril 2023 s'appliquent aux données de journaux conservées plus longtemps durée de conservation par défaut de le bucket _Default et les buckets de journaux définis par l'utilisateur. Pour en savoir plus sur les tarifs, consultez Récapitulatif des tarifs de Cloud Logging Pour vérifier l'espace de stockage facturable buckets de journaux, accédez à la page Stockage des journaux de la console Google Cloud.

Le tableau suivant répertorie les durées de conservation des données pour les journaux stockés dans les buckets de journaux:

Bucket	Durée de conservation par défaut	Conservation personnalisée
_Required	400 jours	Non configurable
_Default	30 jours	Configurable
Défini par l'utilisateur	30 jours	Configurable

Logging facture des coûts de conservation lorsque les journaux sont conservés plus longtemps que la durée de conservation par défaut. Vous ne pouvez pas configurer la durée de conservation pour le bucket de journaux _Required. Il n'y a aucun coût de conservation lorsque les journaux ne sont stockés la durée de conservation par défaut du bucket de journaux.

Si vous réduisez la durée de conservation d'un bucket de journaux, il existe un délai de sept jours délai de grâce pendant lequel les journaux arrivés à expiration ne sont pas supprimés. Vous ne pouvez pas interroger ni afficher les journaux arrivés à expiration. Cependant, au cours de ces sept jours, vous pouvez restaurer l'accès complet en prolongeant la durée de conservation du bucket de journaux. Les journaux stockés pendant le délai de grâce sont comptabilisés dans vos coûts de conservation.

Si vous acheminez une entrée de journal vers plusieurs buckets de journaux, des frais peuvent vous être facturés les coûts de stockage et de conservation plusieurs fois. Par exemple, supposons que vous acheminez une entrée de journal dans le bucket de journaux _Default et dans un bucket de journaux défini par l'utilisateur. Supposons également que vous ayez configuré une durée de conservation personnalisée pour les deux buckets. qui dure plus de 30 jours. Pour cette configuration, deux frais de stockage et deux frais de conservation.

Réduire le stockage des journaux

Logging vous permet d'identifier et d'exclure manuellement les entrées de journal stockés dans des buckets de journaux en configurant des filtres d'exclusion sur vos récepteurs. Les filtres d'exclusion vous permettent de réduire vos coûts de stockage. Par ailleurs, vous pouvez également envisager d'acheminer vos journaux hors de Cloud Logging.

Les filtres d'exclusion permettent de supprimer toutes les entrées de journal correspondant au filtre. ne peut supprimer qu'un pourcentage des journaux qui correspondent au filtre. Lorsqu'une entrée de journal correspond à un filtre d'exclusion pour un récepteur, celui-ci n'achemine pas l'entrée de journal vers la destination. Par conséquent, n'ingèrent pas l'entrée de journal. Les entrées de journal exclues ne sont pas comptabilisées par rapport à l'espace de stockage alloué. Pour obtenir des instructions sur la configuration des filtres d'exclusion, consultez Exclusions de journaux :

Pour conserver l'accès aux journaux qui ne sont pas stockés dans des buckets de journaux, vous pouvez également utiliser récepteurs de journaux pour acheminer les entrées de journal de Cloud Logging vers vers votre destination. Cloud Logging ne facture pas l'acheminement des journaux. Toutefois, les services Google Cloud qui reçoivent vos journaux vous facturent pour l'utilisation. Pour en savoir plus, consultez les documents suivants :

• Tarifs de Cloud Storage
• Tarifs de BigQuery
• Tarifs de Pub/Sub

Pour en savoir plus sur le routage des journaux hors de Cloud Logging, consultez la section Acheminez les journaux vers des destinations compatibles.

Tarifs des métriques basées sur les journaux

Les métriques basées sur les journaux définies par le système sont fournies pour tous les projets Google Cloud et ne sont pas facturables.

Les métriques basées sur les journaux définies par l'utilisateur sont une classe de métriques personnalisées Cloud Monitoring. Elles sont payantes. Pour plus de détails sur les tarifs, consultez la section Métriques facturables.

Pour en savoir plus, consultez la présentation des métriques basées sur les journaux.

Créer une règle d'alerte sur les octets de journaux mensuels ingérés

Pour créer une règle d'alerte qui se déclenche lorsque le nombre les octets de journaux écrits dans vos buckets de journaux dépassent la limite définie par l'utilisateur Cloud Logging, utilisez les paramètres suivants.

Procédure permettant de créer une règle d'alerte

Pour créer une règle d'alerte, procédez comme suit :

1. Dans la console Google Cloud, accédez à la page Alertes.

   Accéder à l'interface des alertes

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Surveillance.

2. Si vous n'avez pas créé vos canaux de notification et que vous souhaitez être averti, cliquez sur Modifier les canaux de notification et ajoutez vos canaux de notification. Revenez à la page Alertes après avoir ajouté vos canaux.
3. Sur la page Alertes, cliquez sur Créer une règle.
4. Pour sélectionner la ressource, la métrique et les filtres, développez le menu Sélectionner une métrique, puis utilisez les valeurs du tableau Nouvelle condition :
   1. (Facultatif) Pour limiter le menu aux entrées pertinentes, saisissez le nom de la ressource ou de la métrique dans la barre de filtre.
   2. Sélectionner un type de ressource Par exemple, sélectionnez Instance de VM.
   3. Sélectionnez une catégorie de métriques. Par exemple, sélectionnez instance.
   4. Sélectionnez une métrique. Par exemple, sélectionnez Utilisation du processeur.
   5. Sélectionnez Appliquer.
5. Cliquez sur Suivant, puis configurez le déclencheur de règle d'alerte. Pour renseigner ces champs, utilisez les valeurs du tableau Configurer le déclencheur d'alerte.
6. Cliquez sur Suivant.

7. Facultatif : Pour ajouter des notifications à votre règle d'alerte, cliquez sur Canaux de notification. Dans la boîte de dialogue, sélectionnez un ou plusieurs canaux de notification dans le menu, puis cliquez sur OK.

   Pour recevoir une notification en cas d'ouverture et de fermeture d'un incident, cochez la case Notifier en cas de fermeture des incidents. Par défaut, les notifications ne sont envoyées que lorsque des incidents sont ouverts.

8. (Facultatif) Mettez à jour la durée de fermeture automatique de l'incident. Ce champ détermine à quel moment Monitoring ferme les incidents en l'absence de données de métriques.
9. Facultatif : Cliquez sur Documentation, puis ajoutez les informations à inclure dans le message de notification.
10. Cliquez sur Nom de l'alerte et saisissez un nom pour la règle d'alerte.
11. Cliquez sur Créer une règle.

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 Monthly log bytes ingested.
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.

Cloud Monitoring

Monitoring facture les frais suivants :

• Métriques mesurées en octets ingérés, lorsque les données de métrique ingérées dépassent l'attribution mensuelle gratuite de métriques.

  Les métriques non facturables ne sont pas comptabilisées dans la limite d'attribution.

• Métriques mesurées par le nombre d'échantillons ingérés.

• Appels en lecture de l'API Cloud Monitoring qui dépassent l'attribution mensuelle gratuite d'API.

  Les appels en écriture de l'API Monitoring ne sont pas comptabilisés dans la limite d'attribution.

• l'exécution de tests de disponibilité ;

• Exécution de la surveillance synthétique

• Conditions des règles d'alerte mesurées par nombre de conditions actives par mois.

• Séries temporelles renvoyées par la requête d'une condition de règle d'alerte.

Dans Monitoring, l'ingestion fait référence au processus d'écriture de séries temporelles dans Monitoring. Chaque série temporelle inclut un certain nombre de points de données, lesquels constituent la base des frais d'ingestion. Pour en savoir plus sur les tarifs, consultez la page Tarifs de Cloud Monitoring.

Cette section fournit les informations suivantes :

• Définitions des métriques facturables et non facturables.
• Description des stratégies d'ingestion basées sur des octets et des échantillons.
• Exemples de tarification des métriques facturées par octets ingérés.
• Exemples de tarification pour les métriques facturées par échantillons ingérés.
• Exemples de tarification pour l'exécution de tests de disponibilité (Date d'entrée en vigueur: 1er octobre 2022)
• Exemples de tarification pour l'exécution de la surveillance synthétique (Date d'entrée en vigueur: 1er novembre 2023)
• Descriptions et exemples de tarification pour les alertes (Date d'entrée en vigueur: 7 janvier 2025)

Pour obtenir des informations sur la tarification actuelle, reportez-vous à la section Tarifs de Cloud Monitoring.

Pour connaître les limites qui s'appliquent à votre utilisation de Monitoring, consultez la page Quotas et limites.

Pour consulter votre utilisation actuelle, effectuez l'une des opérations suivantes:

• Dans la console Google Cloud, accédez à la page Facturation.

  Accéder à Facturation

  Vous pouvez également accéder à cette page à l'aide de la barre de recherche.

• Dans la console Google Cloud, accédez à la page  Paramètres de Monitoring :

  Accéder à la page Paramètres de Monitoring

  Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

En fonction de ces données d'utilisation, vous pouvez estimer le montant de vos factures.

Métriques non facturables

Les données issues des métriques Google Cloud, GKE Enterprise et Knative à facturer. Les métriques non facturables (gratuites) incluent les suivantes :

• Métriques Google Cloud. Pour en savoir plus, consultez la note de bas de page 2.
• Métriques GKE Enterprise Pour en savoir plus, consultez la note de bas de page 2.
• Métriques Istio
• Métriques Knative
• Métriques système Google Kubernetes Engine
• Métriques agent.googleapis.com/agent/

Métriques facturables

Toutes les données de métriques, à l'exception de celles indiquées dans la section Métriques non facturables, sont payantes. La plupart des ingestions de métriques sont facturées selon le nombre d'octets, mais certaines sont facturées selon le nombre d'échantillons. Ces modèles de tarification sont décrits dans les sections suivantes.

Les facteurs suivants contribuent aux coûts d'ingestion :

• Type de points de données (valeurs scalaires ou valeurs de distribution) collectés par les métriques.

  • Pour en savoir plus sur le type de données associé à un type de métrique spécifique, consultez la liste des métriques.
  • Pour plus d'informations sur les types de données scalaires et de distribution, consultez la section Types de valeurs.

• Nombre de points de données écrits dans les séries temporelles. Cette valeur dépend de la fréquence à laquelle les données sont échantillonnées et de la cardinalité de vos données. La cardinalité détermine le nombre de séries temporelles générées pour une combinaison de types de métriques et de ressources surveillées. Pour en savoir plus, consultez la section Cardinalité.

Les valeurs des libellés de métrique et de ressource qui font partie de votre série temporelle ne contribuent pas à vos frais.

Métriques facturées par octets ingérés

Les métriques suivantes sont payantes et facturées en fonction du nombre d'octets ingérés :

• Métriques d'agent sous agent.googleapis.com, sauf Groupe agent.googleapis.com/agent/

  À compter du 6 août 2021, les métriques agent.googleapis.com/processes/ seront facturées à 5 %  du tarif des autres métriques facturables. Par exemple, le coût d'ingestion de 100 Mio de métriques de processus est équivalent au coût d'ingestion de 5 Mio d'autres métriques facturables³.

• Métriques des intégrations tierces avec l'agent Ops. Ces métriques sont ingérés dans Cloud Monitoring avec des identifiants au format workload.googleapis.com/APPLICATION.METRIC; Par exemple, le type de métrique workload.googleapis.com/nginx.requests dans cette catégorie.

• les métriques OTLP (OpenTelemetry Protocol) ingérées dans Cloud Monitoring en tant que workload.googleapis.com par l'agent Ops. Il s'agit d'une configuration cette option ; Pour en savoir plus, consultez Formats d'ingestion pour OTLP métriques.

• Métriques AWS

• Métriques personnalisées y compris, mais sans s'y limiter, les métriques envoyées à l'aide du module l'API Cloud Monitoring ou les bibliothèques clientes spécifiques au langage, OpenCensus et OpenTelemetry.

• Métriques externes

• Métriques basées sur les journaux définies par l'utilisateur

À des fins de tarification, le volume d'ingestion est calculé comme suit :

• Pour un type de données scalaires : 8 octets pour chaque point de données écrit dans une série temporelle. Les métriques de compteur basées sur les journaux définies par l'utilisateur appartiennent à cette catégorie.
• Pour un type de données de distribution : 80 octets pour chaque point de données écrit dans une série temporelle

Pour en savoir plus sur les points de données des séries temporelles, consultez la section Séries temporelles : données issues d'une ressource surveillée.

Métriques facturées par échantillons ingérés

Les métriques suivantes sont payantes et facturées en fonction du nombre d'échantillons ingérés :

• Métriques provenant de Google Cloud Managed Service pour Prometheus : métriques prometheus.googleapis.com.

À des fins de tarification, le nombre d'échantillons est calculé comme suit :

• Pour un type de données scalaires : 1 pour chaque point écrit dans une série temporelle.
• Pour un type de données de distribution : 2 pour chaque point écrit dans une série temporelle, plus 1 pour chaque bucket d'histogrammes dont le nombre n'est pas nul.

Pour en savoir plus sur les points de données des séries temporelles, consultez la section Séries temporelles : données issues d'une ressource surveillée.

Créer des alertes sur les 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 la section Configurer une alerte de facturation.

Exemples de tarification basées sur les octets ingérés

Les exemples suivants montrent comment obtenir une estimation des coûts dans le cadre de la collecte des données de métriques facturées par octets ingérés. Ces exemples sont destinés à illustrer les calculs. Pour obtenir des estimations complètes, utilisez le Simulateur de coût. Si vous accédez à cet outil, utilisez produit d'observabilité Google Cloud pour saisir des données de métrique, de journalisation et de trace.

Le scénario de base est le suivant : vous disposez d'un certain nombre de ressources surveillées telles que Compute Engine, Google Kubernetes Engine ou App Engine, qui écrivent des données à partir d'un certain nombre de métriques chaque mois.

Les différents scénarios incluent les variables suivantes :

• Nombre de ressources
• Nombre de métriques
• Métriques Google Cloud ou non
• Fréquence à laquelle les données de métriques sont écrites

Les exemples de cette section illustrent les tarifs de Monitoring en vigueur depuis juillet 2020.

Contexte commun

Dans les exemples de tarification suivants, chaque point de données de métriques ingéré est du type double, int64 ou bool. Ces types comptent pour 8 octets dans la tarification. Un mois compte environ 730 heures (365 jours/12 mois x 24 heures), soit 43 800 minutes.

Pour une métrique d'écriture de données à la fréquence de 1 point de données par minute pour un mois :

• Nombre total de points de données : 43 800
• Volume total ingéré :
  • 350 400 octets (43 800 points de données x 8 octets)
  • 0,33416748 Mio (350 400 octets/1 048 576 octets/Mio)

Pour une métrique d'écriture de données à la fréquence de 1 point de données par heure pendant un mois :

• Nombre total de points de données : 730
• Volume total ingéré :
  • 5 840 octets (730 points de données x 8 octets)
  • 0,005569458 Mio (5 840 octets/1 048 576 octets/Mio)

Exemples

Scénario 1 : Vous avez 1 000 ressources, chacune écrivant 75 métriques. Il s'agit de métriques Google Cloud uniquement, écrites à la fréquence de 1 point de données par minute.

• Ingestion mensuelle : 25 063 Mio = 0,33416748 Mio pour 1 métrique x 75 000 (soit 1 000 ressources, 75 métriques)
• Coût approximatif par mois : 0,00 $ (les métriques Google Cloud sont incluses gratuitement)

	Mio ingérés	Tarif ($/Mio)	Coût ($)
	Illimité	0,00	0,00 $
Total	25 063		0,00 $

Scénario 2 : Vous avez 1 000 ressources, chacune écrivant 75 métriques personnalisées. Il s'agit de métriques facturables, écrites à la fréquence de 1 point de données par minute.

• Ingestion mensuelle : 25 063 Mio (comme ci-dessus)
• Coût approximatif par mois : 6 427,55 $

	Mio ingérés	Tarif ($/Mio)	Coût ($)
	150	0,00	0,00 $
	24 913	0,258	6 427,55 $
Total	25 063		6 427,55 $

Scénario 3 : Vous avez 1 000 ressources, chacune écrivant 75 métriques personnalisées. Il s'agit de métriques facturables, écrites à la fréquence de 1 point de données par heure.

• Ingestion mensuelle : 418 Mio = 0,005569458 Mio pour 1 métrique x 75 000
• Coût approximatif par mois : 69,14 $

	Mio ingérés	Tarif ($/Mio)	Coût ($)
	150	0,00	0,00 $
	267	0,258	69,14 $
Total	417		69,14 $

Scénario 4 : Vous avez 1 ressource écrivant 500 000 métriques. Il s'agit de métriques facturables, écrites à la fréquence de 1 point de données par minute.

• Ingestion mensuelle : 167 084 Mio = 0,33416748 Mio pour 1 métrique x 500 000
• Coût approximatif par mois : 35 890,98 $

	Mio ingérés	Tarif ($/Mio)	Coût ($)
	150	0,00	0,00 $
	99 850	0,258	25 761,30 $
	67 084	0,151	10 129,68 $
Total	167 084		35 890,98 $

Tarifs pour la contrôlabilité et la prédictibilité

La tarification de Managed Service pour Prometheus contrôlables. É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 data store local du service ; Pour en savoir plus, consultez Filtrer les métriques exportées Utilisez des configurations de modification des libellés de métriques dans votre La configuration de scraping Prometheus abandonne les métriques au moment de l'ingestion, en fonction sur les outils de mise en correspondance des libellés.

• Conservez les données à cardinalité élevée et à faible valeur en local. Vous pouvez exécuter la version standard de Prometheus parallèlement au service géré, en utilisant les mêmes configurations de cluster, et conservez les données en local qu'il n'est pas utile d'envoyer au data store global du service.

La tarification de Managed Service pour Prometheus prévisible.

• 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 bucket_n-1. Par exemple, un histogramme présentant les valeurs 10 10 13 14 14 14 compte 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 est facturé à la métrique, vous payez pour la cardinalité d'un mois complet, une 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 lorsque Prometheus des règles d'enregistrement sont exécutées et sont facturées via des 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.

Exemples de tarification basés sur les échantillons ingérés

Les exemples suivants montrent comment estimer les coûts liés à la collecte des métriques facturées sur la base des échantillons ingérés. Basé sur des échantillons est utilisée pour Google Cloud Managed Service pour Prometheus.

Ces exemples sont destinés à illustrer des techniques de calcul et non à fournir des données de facturation.

Le scénario de base est le suivant : vous avez un certain nombre de conteneurs ou de pods qui écrivent des points dans un certain nombre de séries temporelles chaque mois. Les données peuvent être constituées de valeurs scalaires ou de distributions.

Les différents scénarios incluent les variables suivantes :

• Nombre de conteneurs ou de pods
• Nombre de séries temporelles
• Type de données : valeurs scalaires, distributions ou les deux
• Fréquence d'écriture des données de métriques

Compter les échantillons

Pour pouvoir estimer les prix, vous devez savoir comment comptabiliser les échantillons. Le nombre d'échantillons comptabilisés pour une valeur dépend des éléments suivants :

• Type de la valeur : scalaire ou distribution
• Fréquence d'écriture des valeurs

Cette section explique comment estimer le nombre d'échantillons écrits pour une série temporelle sur la période de facturation mensuelle.

Un mois équivaut à environ 730 heures (365 jours / 12 mois x 24 heures), soit 43 800 minutes ou 2 628 000 secondes.

Si une série temporelle écrit des valeurs scalaires, chaque valeur est comptabilisée comme un échantillon. Le nombre d'échantillons écrits au cours d'un mois dépend uniquement de la fréquence d'écriture des valeurs. Prenons les exemples suivants :

• Pour des valeurs écrites toutes les 15 secondes :
  • Taux d'écriture : 1 valeur/15 s = 1 échantillon/15 s
  • Échantillons par mois : 175 200 (1 échantillon/15 s x 2 628 000 secondes/mois)
• Pour des valeurs écrites toutes les 60 secondes :
  • Taux d'écriture : 1 valeur/60 s = 1 échantillon/60 s
  • Échantillons par mois : 43 800 (1 échantillon/60 s x 2 628 000 secondes/mois)

Si une série temporelle écrit des valeurs de distribution, chaque valeur peut contenir deux + n échantillons, où n est le nombre de buckets dans l'histogramme. Le nombre d'échantillons écrits au cours d'un mois dépend du nombre de buckets de vos histogrammes et de la fréquence d'écriture des valeurs.

Par exemple, chaque instance d'un histogramme de 50 buckets peut contenir 52 échantillons. Si les valeurs sont écrites toutes les 60 secondes, un histogramme de 50 buckets écrit au maximum 2 277 600 échantillons par mois. Si l'histogramme comporte 100 buckets et des écritures toutes les 60 secondes, chaque histogramme peut contenir 102 échantillons et écrit au maximum 4 467 600 échantillons par mois.

La plupart des séries temporelles de distribution contiennent moins d'échantillons que le nombre maximal autorisé. En pratique, entre 20 et 40 % des buckets d'histogramme sont vides. Ce pourcentage est encore plus élevé pour les utilisateurs ayant des histogrammes creux, tels que ceux générés par Istio.

Lors du comptage des échantillons pour la tarification, seuls les buckets avec des valeurs non vides sont inclus. Le nombre maximal d'échantillons par histogramme est de 2 + n . Si 25 % de vos buckets sont vides, le nombre d'échantillons attendu est de 2 + 0,75n par histogramme. Si 40 % de vos buckets sont vides, le nombre d'échantillons attendu est de 2 + 0,60n par histogramme.

Les calculs suivants et le tableau récapitulatif présentent le nombre maximal d'échantillons et des valeurs plus réalistes de nombre d'échantillons attendu :

• Pour des valeurs d'histogramme avec 50 buckets écrites toutes les 15 secondes :

  • Taux d'écriture : 1 valeur/15 s
  • Nombre maximal d'échantillons :
    • Par histogramme : 52
    • Par mois : 9 110 400 (52 x 1 valeur/15 s x 2 628 000 secondes/mois)
  • Nombre d'échantillons attendu, en supposant que 25 % sont vides :
    • Par histogramme : 39,5 (2 + 0,75(50) ou 2 + (50 - 12,5))
    • Par mois : 6 920 400 (39,5 x 1 valeur/15 s x 2 628 000 secondes/mois)
  • Nombre d'échantillons attendu, en supposant que 40 % sont vides :
    • Par histogramme : 32 (2 + 0,6(50) ou 2 + (50 - 20))
    • Par mois : 5 606 400 (32 x 1 valeur/15 s x 2 628 000 secondes/mois)

• Pour des valeurs d'histogramme avec 50 buckets écrites toutes les 60 secondes :

  • Taux d'écriture : 1 valeur/60 s
  • Nombre maximal d'échantillons :
    • Par histogramme : 52
    • Par mois : 2 277 600 (52 x 1 valeur/60 s x 2 628 000 secondes/mois)
  • Nombre d'échantillons attendu, en supposant que 25 % sont vides :
    • Par histogramme : 39,5 (2 + 0,75(50) ou 2 + (50 - 12,5))
    • Par mois : 1 730 100 (39,5 x 1 valeur/60 s x 2 628 000 secondes/mois)
  • Nombre d'échantillons attendu, en supposant que 40 % sont vides :
    • Par histogramme : 32 (2 + 0,6(50) ou 2 + (50 - 20))
    • Par mois : 1 401 600 (32 x 1 valeur/60 s x 2 628 000 secondes/mois)

• Pour des valeurs d'histogramme avec 100 buckets écrites toutes les 15 secondes :

  • Taux d'écriture : 1 valeur/15 s
  • Nombre maximal d'échantillons :
    • Par histogramme : 102
    • Par mois : 17 870 400 (102 x 1 valeur/15 s x 2 628 000 secondes/mois)
  • Nombre d'échantillons attendu, en supposant que 25 % sont vides :
    • Par histogramme : 77 (2 + 0,75(100) ou 2 + (100 - 25))
    • Par mois : 13 490 400 (77 x 1 valeur/15 s x 2 628 000 secondes/mois)
  • Nombre d'échantillons attendu, en supposant que 40 % sont vides :
    • Par histogramme : 62 (2 + 0,6(100) ou 2 + (100 - 40))
    • Par mois : 10 862 400 (62 x 1 valeur/15 s x 2 628 000 secondes/mois)

• Pour des valeurs d'histogramme avec 100 buckets écrites toutes les 60 secondes :

  • Taux d'écriture : 1 valeur/60 s
  • Nombre maximal d'échantillons :
    • Par histogramme : 102
    • Par mois : 4 467 600 (102 x 1 valeur/60 s x 2 628 000 secondes/mois)
  • Nombre d'échantillons attendu, en supposant que 25 % sont vides :
    • Par histogramme : 77 (2 + 0,75(100) ou 2 + (100 - 25))
    • Par mois : 3 372 600 (77 x 1 valeur/60 s x 2 628 000 secondes/mois)
  • Nombre d'échantillons attendu, en supposant que 40 % sont vides :
    • Par histogramme : 62 (2 + 0,6(100) ou 2 + (100 - 40))
    • Par mois : 2 715 600 (62 x 1 valeur/60 s x 2 628 000 secondes/mois)

Ces informations sont récapitulées dans le tableau ci-dessous :

Nombre de buckets	Taux d'écriture	Échantillons par mois (max)	Échantillons par mois (25 % vides)	Échantillons par mois (40 % vides)
50	1 échantillon/15 s	9 110 400	6 920 400	5 606 400
50	1 échantillon/60 s	2 277 600	1 730 100	1 401 600
100	1 échantillon/15 s	17 870 400	13 490 400	10 862 400
100	1 échantillon/60 s	4 467 600	3 372 600	2 715 600

Exemples

Pour estimer les prix, comptez le nombre d'échantillons écrits sur un mois et appliquez les valeurs tarifaires. Les échantillons sont facturés par million, suivant des plages empilées, comme suit :

Plage d'ingestion	Service géré pour Prometheus	Maximum pour la plage
Jusqu'à 50 milliards (50 000 millions)	0,06 $/million	3 000,00 $
50 milliards à 250 milliards (250 000 millions)	0,048 $/million	9 600,00 $
250 milliards à 500 milliards (500 000 millions)	0,036 $/million	9 000,00 $
Plus de 500 milliards (500 000 millions)	0,024 $/million

Le reste de cette section passe en revue différents scénarios possibles.

Scénario 1 : Vous avez 100 conteneurs, chacun écrivant 1 000 séries temporelles.

Variante A : si chaque série temporelle est écrite toutes les 15 secondes (1 échantillon/15 s), le nombre d'échantillons écrits par mois est de 17 520 000 000 (175 200 échantillons/mois x 1 000 séries temporelles x 100 conteneurs), soit 17 520 millions.

Variante B : si chaque série temporelle est écrite toutes les 60 secondes (1 échantillon/60 s), le nombre d'échantillons écrits par mois est de 4 380 000 000 (43 800 échantillons/mois x 10 000 séries temporelles x 1 000 conteneurs), soit 4 380 millions.

Dans ces deux cas, moins de 50 000 millions échantillons, donc seul le premier taux s'applique. Aucun échantillon n'est facturé au d'autres tarifs.

Variante	Échantillons ingérés	Plage d'ingestion	Managed Service pour Prometheus (0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 échantillon/15 s) Total	17 520 millions 17 520 millions	Jusqu'à 50 000 millions Jusqu'à 250 000 millions Jusqu'à 500 000 millions Plus de 500 000 millions	1 051,20 $ 1 051,20$
B (1 échantillon/60 s) Total	4 380 millions 4 380 millions	Jusqu'à 50 000 millions Jusqu'à 250 000 millions Jusqu'à 500 000 millions Plus de 500 000 millions	262,80 $ 262,80$

Scénario 1 : Vous avez 1 000 conteneurs, chacun écrivant 1 000 séries temporelles.

Variante A : si chaque série temporelle est écrite toutes les 15 secondes (1 échantillon/15 s), le nombre d'échantillons écrits par mois est de 175 200 000 000 ou 175 200 millions :

• Les 50 000 premiers millions d'échantillons sont facturés au premier tarif.
• Les 125 200 millions d'échantillons restants sont facturés au second tarif.
• Aucun échantillon n'est facturé aux autres tarifs.

Variante B : si chaque série temporelle est écrite toutes les 60 secondes (1 échantillon/60 s), le nombre d'échantillons écrits par mois est de 43 800 000 000, soit 43 800 millions. Cette valeur mensuelle étant inférieure à 50 000 millions d'échantillons, seul le premier tarif s'applique.

Variante	Échantillons ingérés	Plage d'ingestion	Managed Service pour Prometheus (0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 échantillon/15 s) Total	50 000 millions 125 200 millions 175 200 millions	Jusqu'à 50 000 millions Jusqu'à 250 000 millions Jusqu'à 500 000 millions Plus de 500 000 millions	3 000,00 $ 6 009,60 $ 9 009,60$
B (1 échantillon/60 s) Total	43 800 millions 43 800 millions	Jusqu'à 50 000 millions Jusqu'à 250 000 millions Jusqu'à 500 000 millions Plus de 500 000 millions	2 628,00 $ 2 628,00$

Scénario 3 : Vous avez 100 conteneurs, chacun écrivant 1 000 séries temporelles de type distribution dans 100 buckets. Vous prévoyez que 25 % des buckets seront vides.

Variante A : si chaque série temporelle est écrite toutes les 15 secondes (1 échantillon/15 s), le nombre d'échantillons écrits par mois est de 1 349 040 000 000 (13 490 400 échantillons/mois x 1 000 séries temporelles x 100 conteneurs), soit 1 349 040 millions.

• Les 50 000 premiers millions d'échantillons sont facturés au premier tarif.
• Les 200 000 millions d'échantillons suivants sont facturés au second tarif.
• Les 250 000 millions d'échantillons suivants sont facturés au troisième tarif.
• Les 749 040 millions d'échantillons restants sont facturés au quatrième tarif.

Variante B : si chaque série temporelle est écrite toutes les 60 secondes (1 échantillon/60 s), le nombre d'échantillons écrits par mois est de 337 260 000 000 (3 372 600 échantillons/mois x 1 000 séries temporelles x 100 conteneurs), soit 337 260 millions.

• Les 50 000 premiers millions d'échantillons sont facturés au premier tarif.
• Les 200 000 millions d'échantillons suivants sont facturés au second tarif.
• Les 87 260 millions d'échantillons restants sont facturés au troisième tarif.

Variante	Échantillons ingérés	Plage d'ingestion	Managed Service pour Prometheus (0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 échantillon/15 s) Total	50 000 millions 200 000 millions 250 000 millions 749 040 millions 1 349 040 millions	Jusqu'à 50 000 millions Jusqu'à 250 000 millions Jusqu'à 500 000 millions Plus de 500 000 millions	3 000,00 $ 9 600,00 $ 9 000,00 $ 17 976,96 $ 39 576,96$
B (1 échantillon/60 s) Total	50 000 millions 200 000 millions 87 260 millions 337 260 millions	Jusqu'à 50 000 millions Jusqu'à 250 000 millions Jusqu'à 500 000 millions Plus de 500 000 millions	3 000,00 $ 9 600,00 $ 3 141,36 $ 15 741,36$

Scénario 4 : Vous avez 1 000 conteneurs, chacun écrivant 10 000 séries temporelles de type distribution dans 100 buckets. Vous prévoyez que 40 % des buckets seront vides.

Variante A : si chaque série temporelle est écrite toutes les 15 secondes (1 échantillon/15 s), le nombre d'échantillons écrits par mois est de 108 624 000 000 000 (10 862 400 échantillons/mois x 10 000 séries temporelles x 1 000 conteneurs), soit 108 624 000 millions.

• Les 50 000 premiers millions d'échantillons sont facturés au premier tarif.
• Les 200 000 millions d'échantillons suivants sont facturés au second tarif.
• Les 250 000 millions d'échantillons suivants sont facturés au troisième tarif.
• Les 108 124 000 millions d'échantillons restants sont facturés au quatrième tarif.

Variante B : si chaque série temporelle est écrite toutes les 60 secondes (1 échantillon/60 s), le nombre d'échantillons écrits par mois est de 27 156 000 000 000 (2 715 600 échantillons/mois x 10 000 séries temporelles x 1 000 conteneurs), soit 27 156 000 millions.

• Les 50 000 premiers millions d'échantillons sont facturés au premier tarif.
• Les 200 000 millions d'échantillons suivants sont facturés au second tarif.
• Les 250 000 millions d'échantillons suivants sont facturés au troisième tarif.
• Les 26 656 000 millions d'échantillons restants sont facturés au quatrième tarif.

Variante	Échantillons ingérés	Plage d'ingestion	Managed Service pour Prometheus (0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 échantillon/15 s) Total	50 000 millions 200 000 millions 250 000 millions 108 124 000 millions 108 624 000 millions	Jusqu'à 50 000 millions Jusqu'à 250 000 millions Jusqu'à 500 000 millions Plus de 500 000 millions	3 000,00 $ 9 600,00 $ 9 000,00 $ 2 594 976,00 $ 2 616 576,00$
B (1 échantillon/60 s) Total	50 000 millions 200 000 millions 250 000 millions 26 656 000 millions 27 156 000 millions	Jusqu'à 50 000 millions Jusqu'à 250 000 millions Jusqu'à 500 000 millions Plus de 500 000 millions	3 000,00 $ 9 600,00 $ 9 000,00 $ 639 744,00 $ 661 344,00$

Scénario 5 : Vous avez les éléments suivants :

• 1 000 conteneurs, chacun écrivant 1 000 séries temporelles scalaires toutes les 15 secondes. Le nombre d'échantillons écrits par mois est de 175 200 000 000, soit 175 200 millions. (Scénario 2, variante A)

• 1 000 conteneurs, chacun écrivant 10 000 séries temporelles de type distribution dans 100 buckets toutes les 15 secondes. Vous prévoyez que 40 % des buckets seront vides. Le nombre d'échantillons écrits par mois est de 108 624 000 000 000, soit 108 624 000 millions. (Scénario 4, variante A)

Le nombre total d'échantillons par mois est de 108 799 200 millions (175 200 millions + 108 624 000 millions).

• Les 50 000 premiers millions d'échantillons sont facturés au premier tarif.
• Les 200 000 millions d'échantillons suivants sont facturés au second tarif.
• Les 250 000 millions d'échantillons suivants sont facturés au troisième tarif.
• Les 108 299 200 millions d'échantillons restants sont facturés au quatrième tarif.

Variante	Échantillons ingérés	Plage d'ingestion	Managed Service pour Prometheus (0,06 $, 0,048 $, 0,036 $, 0,024 $)
2A + 4A Total	50 000 millions 200 000 millions 250 000 millions 108 299 200 millions 108 799 200 millions	Jusqu'à 50 000 millions Jusqu'à 250 000 millions Jusqu'à 500 000 millions Plus de 500 000 millions	3 000,00 $ 9 600,00 $ 9 000,00 $ 2 599 180,80 $ 2 620 780,80$

Tarifs pour l'exécution des tests de disponibilité (date d'entrée en vigueur: 1er octobre 2022)

Monitoring facture des frais pour chaque exécution régionale d'un test de disponibilité au-delà de l'attribution mensuelle gratuite d'un million d'exécutions. Une vérification qui s'exécute dans trois régions compte comme trois exécutions.

Le coût d'exécution du test de disponibilité est de 0,30 $pour 1 000 exécutions. Ce débit apparaît sur votre facture avec le SKU "CA14-D3DE-E67F". pour "Surveiller les tests de disponibilité".

Les exemples suivants montrent comment estimer les coûts pour exécuter des tests de disponibilité. Ces exemples sont destinés à illustrer techniques de calcul, et non pour fournir des données de facturation.

Comptabiliser les exécutions des tests de disponibilité

Pour estimer le coût de vos tests de disponibilité, vous devez connaître le nombre les exécutions régionales ont lieu en un mois. Frais Monitoring 0,30 $/1 000 exécutions, avec un million d'exécutions gratuites par mois

Pour estimer le coût de vos tests de disponibilité, vous pouvez utiliser les éléments suivants : calcul:

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

Pour chaque test de disponibilité, le nombre d'exécutions dépend des éléments suivants : de configuration:

• Fréquence d'exécution du test de disponibilité : 10 ou 15 minutes.

• Nombre de régions dans lesquelles le test de disponibilité s'exécute.

• Nombre de cibles pour lesquelles le test de disponibilité est configuré. Si le temps d'activité est configuré pour une seule VM, le nombre de cibles est de 1. Si le test de disponibilité est configuré pour un groupe de ressources, le nombre des cibles correspond au nombre de ressources dans le groupe.

Lorsque vous configurez un test de disponibilité, vous spécifiez un emplacement pour test de disponibilité, et chaque emplacement est associé à une ou plusieurs régions. La le tableau suivant indique les emplacements valides pour les tests de disponibilité et les régions auxquels ils sont mappés:

Emplacement de la configuration des tests de disponibilité	Inclut les régions Google Cloud
ASIA_PACIFIC	asia-southeast1
EUROPE	europe-west1
SOUTH_AMERICA	southamerica-east1
USA	us-central1, us-east4, us-west1
GLOBAL	Toutes les régions incluses dans d'autres emplacements

Vous devez configurer vos tests de disponibilité pour qu'ils s'exécutent dans au moins trois régions.

Pour estimer le nombre d'exécutions d'un test de disponibilité, vous devez connaître le nombre de régions couvertes par l'emplacement du test de disponibilité:

• ASIA_PACIFIC, EUROPE et SOUTH_AMERICA incluent chacun une région.
• USA inclut trois régions.
• GLOBAL inclut six régions.

Dans un mois, environ 730 heures (365 jours / 12 mois x 24 heures) ou 43 800 minutes.

• Un test de disponibilité configuré pour s'exécuter toutes les minutes dans USA s'exécute dans trois régions. Si ce test de disponibilité est configuré pour tester un seul VM, ce test de disponibilité exécute 131 400 instances (3 * 43 800) fois par mois. Si la vérification est configurée pour tester un groupe de ressources de 10 membres, le test de disponibilité s'exécute 1 314 000 (10 * 131 400) fois par mois.

• Un test de disponibilité configuré pour s'exécuter toutes les minutes dans ASIA_PACIFIC EUROPE et USA s'exécutent dans cinq régions. Ce test de disponibilité s'exécute 219 000 fois par mois configurés pour une seule cible.

Le tableau suivant indique le nombre d'exécutions horaires et mensuelles pour une seule configuré pour s'exécuter à des fréquences différentes dans différentes le nombre de régions:

Fréquence d'exécution du test (toutes les: )	Nombre de régions	Exécutions horaires par cible	Exécutions mensuelles par cible
1 minute	3 4 5 6.	180 240 300 360°	131 400 175 200 219 000 262 800
5 minutes	3 4 5 6.	36 48 60 72	26 280 35 040 43 000 52 660
10 minutes	3 4 5 6.	18 24 30 36	13 140 17 520 21 900 26 280
15 minutes	3 4 5 6.	12 16 20 24 ans	8 760 11 680 14 600 17 520

Examples

Pour estimer les prix, déterminez le nombre total d'exécutions mensuelles et soustrayez 1 000 000. Toutes les exécutions restantes sont facturées au tarif de 0,30 $/1 000 exécutions. multiplier les exécutions restantes par 0,0003.

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

Scénario 1: Vous avez un test de disponibilité dans l'emplacement USA. qui vérifie une VM toutes les minutes. Cette vérification s'exécute dans trois régions. La vérification s'exécute 131 400 fois par mois et ne coûte rien.

Nombre total d'exécutions mensuelles	Exécutions mensuelles facturables (plus de 1 000 000)	Coût (0,30 $/1 000 exécutions)
131 400	0	0,00 $

Scénario 2: Vous avez un test de disponibilité dans l'emplacement USA. qui vérifie un groupe de ressources de 10 membres toutes les minutes. Cette vérification s'exécute dans dans différentes régions. La vérification s’exécute 10 * 131 400 fois par mois et coûte 94,20 $/mois. La seule différence entre ce scénario et le scénario 1 correspond au nombre de cibles.

Nombre total d'exécutions mensuelles	Exécutions mensuelles facturables (plus de 1 000 000)	Coût (0,30 $/1 000 exécutions)
1 314 000 (10 cibles)	314 000	94,20 $

Scénario 3: Vous avez 10 tests de disponibilité GLOBAL, chacun vérifie une VM toutes les minutes. Ces vérifications s'exécutent dans six régions, Ainsi,chaque vérification est exécutée 262 800 fois par mois. Le total mensuel est de 2 628 000 (10 x 262 800). Ce scénario coûte 488,40 $/mois.

Nombre total d'exécutions mensuelles	Exécutions mensuelles facturables (plus de 1 000 000)	Coût (0,30 $/1 000 exécutions)
2 628 000	1 628 000	488,40 $

Scénario 4: Vous avez 5 tests de disponibilité dans l'emplacement USA qui vérifient une VM toutes les cinq minutes. Ces vérifications s'exécutent dans trois régions, s’exécute 26 280 fois par mois. Nombre total d'exécutions mensuelles pour cet ensemble de vérifications est de 105 120 (4 * 26 280).

Vous avez également 2 tests de disponibilité GLOBAL qui vérifient 1 VM toutes les 15 minutes. Ces vérifications s'exécutant dans six régions, chaque vérification s'exécute 17 520 fois par mois. Le nombre total d'exécutions mensuelles de tests est de 35 040 (2 x 17 520).

Le total de vos exécutions mensuelles est de 140 160 (105 120 + 35 040). Ce scénario ne coûte rien.

Nombre total d'exécutions mensuelles	Exécutions mensuelles facturables (plus de 1 000 000)	Coût (0,30 $/1 000 exécutions)
140 160	0	0,00 $

Tarifs pour l'exécution de la surveillance synthétique (date d'entrée en vigueur: 1er novembre 2023)

Cloud Monitoring facture chaque exécution d'une surveillance synthétique, au-delà l'attribution gratuite par mois de 100 exécutions par compte de facturation. Par exemple, si vous créez trois surveillances synthétiques et que vous configurez chacune pour qu'ils s'exécutent toutes les 5 minutes, votre nombre total exécutions par mois s'élève à 26 784:

Number of executions per month =  3 synthetic monitors * 1 execution per monitor per 5 minutes *
                                  1440 minutes per day * 31 days per month
                               =  26,784

Pour déterminer le nombre d'exécutions facturables, soustrayez l'attribution gratuite à partir du nombre total d'exécutions, puis multipliez le résultat par coût:

Nombre total d'exécutions mensuelles	Exécutions mensuelles facturables (plus de 100 exécutions par compte de facturation)	Coût (1,20 $/1 000 exécutions)
26 784	26 684	32,02 $

Tarifs des alertes

À compter du 7 janvier 2025, Cloud Monitoring commencera à facturer les alertes. Le modèle de tarification est le suivant:

• 1,50 $ par mois pour chaque condition d'une règle d'alerte
• 0,35 $ pour 1 000 000 de séries temporelles renvoyées par la requête d'une condition de règle d'alerte basée sur les métriques.

Important :Les contrats-cadres de services sont envoyés 60 jours, puis 30 jours avant l'activation de la tarification.

Cette section fournit les informations suivantes :

• Définitions de la terminologie des alertes
• Exemples de frais pour diverses alertes des configurations de règles.
• Suggestions pour réduire les coûts par en consolidant ou supprimant des règles d'alerte.
• Informations sur la désactivation de la facturation pour les règles d'alerte.

Définitions

• Condition: la condition d'un décrit lorsqu'une ressource ou un groupe de ressources est dans un état qui nécessite une réponse.

  • Les règles d'alerte qui utilisent des filtres pour créer metric-threshold ou Les requêtes de type metric-absence peuvent combiner jusqu'à six conditions.
  • Les règles d'alerte avec les types de requêtes suivants ne peuvent avoir qu'un seul condition unique:
    • requête PromQL (Prometheus Query Language),
    • Langage MQL (Monitoring Query Language)
    • Log match (Correspondance de journal), utilisée dans alertes basées sur les journaux.

  Le montant facturé correspond à 1,50 $par mois pour chaque condition. Pour ne plus être facturé pour une condition, vous devez supprimer la règle d'alerte. répéter ou désactiver la règle ; pour éviter que des frais ne vous soient facturés.

• Règles d'alerte basées sur les métriques et basées sur les journaux: règles d'alerte qui utilisent Tout type de condition, à l'exception des conditions de correspondance de journal, sont des alertes de type metric règles ; les conditions des règles d'alerte basées sur les métriques renvoient des séries temporelles. Pendant chaque période d'exécution, les conditions des règles d'alerte basées sur les métriques s'exécutent leurs requêtes sur le datastore Cloud Monitoring. La valeur renvoyée les séries temporelles sont ensuite évaluées par rapport à un seuil afin de déterminer les règles d'alerte.

  Les règles d'alerte basées sur les journaux utilisent des conditions de correspondance des journaux. Conditions de correspondance des journaux ne renvoient aucune série temporelle.

• Durée d'exécution: la fréquence à laquelle Cloud Monitoring exécute vos . Pour la plupart des types de condition, cette durée est de 30 secondes et ne peut pas être modifié. Les conditions qui utilisent une requête PromQL peuvent définir cette période. Pour en savoir plus, consultez la section Augmenter la durée de la période d'exécution (PromQL uniquement).

• Série temporelle renvoyée: à chaque période d'exécution, une métrique alertant exécute la requête de sa condition par rapport à Cloud Monitoring un datastore unique. Cloud Monitoring renvoie des données de séries temporelles en réponse à chaque requête. Chaque série temporelle de la réponse compte comme une série temporelle renvoyé.

  Le nombre de séries temporelles renvoyées au cours d'un mois est déterminé par trois facteurs:

  • La forme et la portée des données sous-jacentes.
  • Les filtres et les agrégations que vous utilisez dans la requête de votre condition
  • Période d'exécution.

  Prenons l'exemple d'une configuration avec les éléments suivants:

  • 100 machines virtuelles (VM), chaque VM appartenant à un seul service
  • Chaque VM émet une métrique, metric_name, qui possède une étiquette à 10 valeurs.
  • Cinq services au total.

  Puisque vous avez 100 VM, chacune peut générer 10 séries temporelles (une pour chaque valeur d'étiquette), vous disposez d'un total de 1 000 séries temporelles sous-jacentes. Chaque VM contient également une étiquette de type métadonnées qui enregistre auquel appartient la VM.

  Vous pouvez configurer vos règles d'alerte comme suit en utilisant PromQL, où chaque configuration génère un nombre différent de séries temporelles renvoyées par période d'exécution:

  Configuration	Requête PromQL	Séries temporelles renvoyées par période
  Aucune agrégation	rate(metric_name[1m])	1 000
  Agréger à la VM	sum by (vm) (rate(metric_name[1m]))	100
  Agréger jusqu'à la valeur de l'étiquette	sum by (label_key) (rate(metric_name[1m]))	10
  Agréger les données au niveau du service	sum by (service) (rate(metric_name[1m]))	5
  Agréger pour étiqueter la valeur et le service	sum by (service, label_key) (rate(metric_name[1m]))	50
  Agréger les données dans le parc	sum (rate(metric_name[1m]))	1
  Filtrer et agréger les données dans une VM	sum (rate(metric_name{vm="my_vm_name"}[1m]))	1
  Filtrer et agréger les données dans un seul service	sum (rate(metric_name{service="my_service_name"}[1m]))	1

Exemples de tarification

Les exemples suivants se déroulent sur un mois de 30 jours. Voici les résultats qui en découlent : d'évaluation:

• 86 400 périodes d'exécution de 30 secondes par mois
• 172 800 périodes d'exécution de 15 secondes par mois (requêtes PromQL uniquement)

Exemple 1: Une règle, agrégée sur la VM, 30 secondes

Dans cet exemple, utilisez les configurations suivantes:

Données

• 100 VM
• Chaque VM émet une métrique, metric_name
• metric_name comporte un libellé qui comporte 10 valeurs.

Règle d'alerte

• Une condition d'alerte
• La condition est agrégée au niveau de la VM
• Période d'exécution de 30 secondes

Coûts résultants

• Condition cost (Coût de l'état) : 1 condition x 1,50 $ par mois = 1,50 $ par mois
• Time series cost (Coût de la série temporelle) : 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: 4,52$par mois

Exemple 2: 100 règles (une par VM), cumulées sur la VM, 30 secondes

Dans cet exemple, utilisez les configurations suivantes:

Données

• 100 VM
• Chaque VM émet une métrique, metric_name
• metric_name comporte un libellé qui comporte 10 valeurs.

Règles d'alerte

• 100 conditions
• Chaque condition est filtrée et agrégée dans une VM
• Période d'exécution de 30 secondes

Coûts résultants

• Coût de la condition: 100 conditions x 1,50 $ par mois = 150 $par mois
• Time series cost (Coût de la série temporelle) : 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: 153,02$par mois

Exemple 3: une règle, avec l'agrégation de la VM, 15 secondes

Dans cet exemple, utilisez les configurations suivantes:

Données

• 100 VM
• Chaque VM émet une métrique, metric_name
• metric_name comporte un libellé qui comporte 10 valeurs.

Règle d'alerte

• Une condition d'alerte PromQL
• La condition est agrégée au niveau de la VM
• Période d'exécution de 15 secondes

Coûts résultants

• Condition cost (Coût de l'état) : 1 condition x 1,50 $ par mois = 1,50 $ par mois
• Time series cost (Coût de la série temporelle) : 100 séries temporelles renvoyées par période * 172 800 périodes par mois = 17,3 millions de séries temporelles renvoyées par mois * 0,35 $ par million de séries temporelles = 6,05 $ par mois
• Coût total: 7,55$par mois

Exemple 4: Agréger une règle par service pendant 30 secondes

Dans cet exemple, utilisez les configurations suivantes:

Données

• 100 VM, chaque VM appartenant à un service
• Cinq services au total
• Chaque VM émet une métrique, metric_name
• metric_name comporte un libellé qui comporte 10 valeurs.

Règle d'alerte

• Une condition
• La condition est agrégée au niveau du service
• Période d'exécution de 30 secondes

Coûts résultants

• Condition cost (Coût de l'état) : 1 condition x 1,50 $ par mois = 1,50 $ par mois
• Time series cost (Coût de la série temporelle) : 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: 1,64$par mois

Exemple 5: Agréger une règle sur la VM cardinalité sous-jacente plus élevée par VM, en 30 secondes

Dans cet exemple, utilisez les configurations suivantes:

Données

• 100 VM
• Chaque VM émet une métrique, metric_name
• metric_name comporte 100 étiquettes de 1 000 valeurs chacune

Règle d'alerte

• Une condition
• La condition est agrégée au niveau de la VM
• Période d'exécution de 30 secondes

Coûts résultants

• Condition cost (Coût de l'état) : 1 condition x 1,50 $ par mois = 1,50 $ par mois
• Time series cost (Coût de la série temporelle) : 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: 4,52$par mois

Exemple 6: Agréger une règle sur la VM unir deux métriques en une seule condition, en 30 secondes

Dans cet exemple, utilisez les configurations suivantes:

Données

• 100 VM
• Chaque VM émet deux métriques, metric_name_1 et metric_name_2.
• Les deux métriques ont une étiquette de 10 valeurs chacune

Règle d'alerte

• Une condition
• La condition est agrégée au niveau de la VM
• La condition utilise un opérateur OR pour unifier les métriques
• Période d'exécution de 30 secondes

Coûts résultants

• Condition cost (Coût de l'état) : 1 condition x 1,50 $ par mois = 1,50 $ par mois
• Time series cost (Coût de la série temporelle) : 2 métriques x 100 séries temporelles renvoyées par métrique et par période * 86 400 périodes par mois = 17,3 millions de séries temporelles renvoyées par mois * 0,35 $ par million de séries temporelles = 6,05 $ par mois
• Coût total: 7,55$par mois

Exemple 7: 100 règles d'alerte basées sur les journaux

Dans cet exemple, utilisez la configuration suivante:

Règles d'alerte

• 100 conditions (une condition par règle d'alerte basée sur les journaux)

Coûts résultants

• Condition cost (Coût de l'état) : 100 condition x 1,50 $ par mois = 150,00 $ par mois
• Time series cost (Coût de la série temporelle) : 0 $ (Les règles d'alerte basées sur les journaux ne renvoient pas de séries temporelles.)
• Coût total: 150,00$par mois

Suggestions pour réduire votre facture liée aux alertes

Lorsque vous configurez des règles d'alerte basées sur les métriques, utilisez les éléments suivants : afin de réduire le coût de vos factures associées aux alertes.

Consolider les règles d'alerte pour fonctionner sur plus de ressources

En raison du coût de 1,50 $par état, plus rentable d'utiliser une seule règle d'alerte pour surveiller plusieurs ressources que d'utiliser une seule règle d'alerte pour surveiller chaque ressource. Par exemple : Comparez l'exemple 1 à l'exemple 2: 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. Par conséquent, l'exemple 1 coûte presque 150 $de moins par mois.

Agrégez les données uniquement au niveau pour lequel vous devez générer une alerte.

L'agrégation à des niveaux de précision plus élevés entraîne des coûts plus élevés que et s'agrége à des niveaux de précision inférieurs. Par exemple : est moins coûteux d'agréger des données au niveau du projet Google Cloud que au niveau du cluster, et l'agrégation au niveau du cluster est plus économique que l'agrégation au niveau du cluster et de l'espace de noms.

Par exemple, comparez l'exemple 1 à l'exemple 4: Les deux exemples fonctionnent sur les mêmes données sous-jacentes et comportent une seule alerte . Cependant, comme la règle d'alerte de l'exemple 4 regroupe est moins chère que la règle d'alerte de l'exemple 1, qui agrège plus précisément les données de la VM.

De plus, comparez l'exemple 1 à l'exemple 5: Dans ce cas, la cardinalité de la métrique de l'exemple 5 est 10 000 fois supérieure à la cardinalité de la métrique dans l'exemple 1. Toutefois, comme la règle d'alerte L'exemple 1 et l'exemple 5 agrègent les deux sur la VM. de VM est le même dans les deux exemples, les exemples sont équivalents le prix.

Lorsque vous configurez vos règles d'alerte, choisissez des niveaux d'agrégation les mieux adaptés à votre cas d'utilisation. Par exemple, si vous souhaitez générer des alertes vous pouvez agréger les données au niveau de la VM et du processeur. Si vous des alertes sur la latence par point de terminaison, vous pouvez agréger au niveau du point de terminaison.

Ne pas générer d'alertes sur des données brutes et non agrégées

Monitoring utilise un système de métriques dimensionnelles, où toutes les métriques présente une cardinalité totale égale au nombre de ressources surveillées ; multipliée par le nombre de combinaisons d'étiquettes pour cette métrique. Pour Par exemple, si 100 VM émettent une métrique avec 10 VM, étiquettes de 10 valeurs chacune, votre cardinalité totale est 100 * 10 * 10 = 10 000.

En raison de l'évolution de la cardinalité, les alertes sur les données brutes peuvent être extrêmement chers. Dans l'exemple précédent, 10 000 séries temporelles ont été renvoyées pour chaque période d'exécution. Toutefois, si vous regroupez les données de la VM, Seulement 100 séries temporelles renvoyées par période d'exécution, quelle que soit l'étiquette cardinalité des données sous-jacentes.

Les alertes sur les données brutes vous exposent également à un risque d'augmentation des séries temporelles lorsque vos métriques reçoivent de nouveaux libellés. Dans l'exemple précédent, si un utilisateur ajoute un nouveau libellé à votre métrique, votre cardinalité totale augmente à 100 * 11 * 10 = 11 000 séries temporelles. Dans ce cas, le nombre d'impressions de série temporelle augmente de 1 000 à chaque période d'exécution,même si vos reste inchangée. Si, au contraire, vous regroupez les données sur la VM, une cardinalité sous-jacente plus élevée, seules 100 séries temporelles sont renvoyées.

Filtrer les réponses inutiles

Configurez vos conditions pour évaluer uniquement les données nécessaires à votre vos besoins d'alerte. Si vous ne preniez pas de mesures pour réparer quelque chose, excluez depuis vos règles d'alerte. Par exemple, vous n'avez probablement pas besoin d'alerter sur la VM de développement d'un stagiaire.

Pour réduire les coûts et les alertes inutiles, vous pouvez filtrer les séries temporelles qui ne sont pas importantes. Vous pouvez utiliser des étiquettes de métadonnées Google Cloud pour taguer des éléments avec des catégories, puis filtrer les catégories de métadonnées inutiles.

Utiliser des opérateurs top-stream pour réduire le nombre de séries temporelles renvoyées

Si votre condition utilise une requête PromQL ou MQL, vous pouvez utilisez 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
• MQL: top

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

Si vous limitez le nombre de séries temporelles à un nombre très élevé, vous risquez de manquer des données et telles que:

• Si plus de N séries temporelles dépassent votre seuil, vous manquerez 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, alors : vos incidents peuvent se fermer automatiquement alors que la série temporelle exclue est toujours ne respectent pas le seuil.
• Vos requêtes de condition ne vous montreront peut-être pas de contexte important, comme votre référence des séries temporelles qui fonctionnent comme prévu.

Pour atténuer ces risques, choisissez des valeurs élevées pour N et utilisez les flux principaux dans les règles d'alerte qui évaluent de nombreuses séries temporelles, comme pour chaque conteneur Kubernetes.

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 longueur de la période d'exécution en définissant evaluationInterval dans condition [état].

Les intervalles d'évaluation plus longs réduisent le nombre de séries temporelles renvoyées par mois. Par exemple, une requête de condition avec un intervalle de 15 secondes s'exécute deux fois plus souvent en tant que requête avec un intervalle de 30 secondes et en tant que requête avec un intervalle d'une minute s'exécute deux fois moins souvent qu'une requête à un intervalle de 30 secondes.

Remarque :Les autres conditions des autres règles d'alerte sont fixées sur une exécution de 30 secondes. période.

Désactivation…

Si vous avez un contrat Google Cloud existant qui n'expire pas avant le À compter du 7 janvier 2025, vous pouvez retarder la facturation des alertes jusqu'à la fin de votre contrat doit être renouvelé en demandant une exemption de l'API Cloud Monitoring équipe chargée de la facturation des alertes. Les clients avec des contrats actifs feront des exemptions au cas par cas.

Vous pouvez demander une exception jusqu'au 1er novembre 2024. Pour demander une exonération de facturation jusqu'au renouvellement du contrat, remplissez le formulaire de demande d'exemption de facturation.

Error Reporting

Pour obtenir des informations sur la tarification actuelle, reportez-vous à la section Tarifs d'Error Reporting.

Pour connaître les limites qui s'appliquent à votre utilisation d'Error Reporting, consultez la page Quotas et limites.

Cloud Profiler

L'utilisation de Cloud Profiler n'entraîne aucuns frais.

Pour connaître les limites qui s'appliquent à votre utilisation de Profiler, consultez la page Quotas et limites.

Cloud Trace

Les frais appliqués à Trace dépendent du nombre de délais de trace ingérés et analysés. Lorsque les données de latence sont envoyées à Trace, elles sont regroupées dans une trace composée de délais, qui sont ingérés par le backend Cloud Trace. Lorsque vous affichez des données de trace, Cloud Trace analyse les délais stockés. Cette section fournit les informations suivantes :

• Elle définit les délais de trace payants et gratuits.
• Elle présente un exemple de tarification.
• Elle explique comment réduire l'ingestion de délais de trace.
• Elle fournit les paramètres d'une règle d'alerte pouvant vous avertir si le seuil défini pour l'ingestion des délais de trace est atteint.

Pour obtenir des informations sur la tarification actuelle, reportez-vous à la section Tarifs de Cloud Trace.

Pour connaître les limites qui s'appliquent à votre utilisation de Trace, consultez la page Quotas et limites.

Pour savoir comment afficher votre utilisation actuelle ou passée, consultez Estimer vos factures.

Délais de trace gratuits

Les tarifs de Cloud Trace ne s'appliquent pas aux délais générés automatiquement par l'environnement standard App Engine, Cloud Functions ou Cloud Run : l'ingestion de ces traces est gratuite.

Délais de trace payants

L'ingestion des délais de trace, à l'exception de ceux indiqués dans la section Délais de trace gratuits, est payante et facturée en fonction du volume ingéré. Il s'agit, entre autres, des délais créés par l'instrumentation que vous ajoutez à votre application App Engine standard.

Exemples de tarification

Ces exemples illustrent les tarifs de Trace en vigueur depuis juillet 2020.

• Si vous ingérez 2 millions de délais par mois, le coût est de 0 $. (Vos 2,5 premiers millions de délais ingérés en un mois sont gratuits.)
• Si vous ingérez 14 millions de délais en un mois, le coût est de 2,30 $. (Vos 2,5 premiers millions de délais en un mois sont gratuits. Le coût des délais restants est de 11,5 millions de délais x 0,20 $/million de délais = 2,30 $.)
• Si vous ingérez 1 milliard de délais en un mois, le coût est de 199 $. (Vos 2,5 premiers millions de délais en un mois sont gratuits. Le coût des délais restants est de 997,5 millions de délais x 0,20 $/million de délais = 199,50 $.)

Réduire votre utilisation de 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.

Créer des alertes sur les délais mensuels ingérés

Pour créer une règle d'alerte qui se déclenche lorsque votre abonnement mensuel Délais Cloud Trace ingérés dépasse une limite définie par l'utilisateur, utilisez les paramètres suivants.

Procédure permettant de créer une règle d'alerte

Pour créer une règle d'alerte, procédez comme suit :

1. Dans la console Google Cloud, accédez à la page Alertes.

   Accéder à l'interface des alertes

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Surveillance.

2. Si vous n'avez pas créé vos canaux de notification et que vous souhaitez être averti, cliquez sur Modifier les canaux de notification et ajoutez vos canaux de notification. Revenez à la page Alertes après avoir ajouté vos canaux.
3. Sur la page Alertes, cliquez sur Créer une règle.
4. Pour sélectionner la ressource, la métrique et les filtres, développez le menu Sélectionner une métrique, puis utilisez les valeurs du tableau Nouvelle condition :
   1. (Facultatif) Pour limiter le menu aux entrées pertinentes, saisissez le nom de la ressource ou de la métrique dans la barre de filtre.
   2. Sélectionner un type de ressource Par exemple, sélectionnez Instance de VM.
   3. Sélectionnez une catégorie de métriques. Par exemple, sélectionnez instance.
   4. Sélectionnez une métrique. Par exemple, sélectionnez Utilisation du processeur.
   5. Sélectionnez Appliquer.
5. Cliquez sur Suivant, puis configurez le déclencheur de règle d'alerte. Pour renseigner ces champs, utilisez les valeurs du tableau Configurer le déclencheur d'alerte.
6. Cliquez sur Suivant.

7. Facultatif : Pour ajouter des notifications à votre règle d'alerte, cliquez sur Canaux de notification. Dans la boîte de dialogue, sélectionnez un ou plusieurs canaux de notification dans le menu, puis cliquez sur OK.

   Pour recevoir une notification en cas d'ouverture et de fermeture d'un incident, cochez la case Notifier en cas de fermeture des incidents. Par défaut, les notifications ne sont envoyées que lorsque des incidents sont ouverts.

8. (Facultatif) Mettez à jour la durée de fermeture automatique de l'incident. Ce champ détermine à quel moment Monitoring ferme les incidents en l'absence de données de métriques.
9. Facultatif : Cliquez sur Documentation, puis ajoutez les informations à inclure dans le message de notification.
10. Cliquez sur Nom de l'alerte et saisissez un nom pour la règle d'alerte.
11. Cliquez sur Créer une règle.

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 Metrics (Métriques), sélectionnez Monthly trace spans ingested.
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.

GKE Enterprise

L'utilisation des journaux système et des métriques de GKE Enterprise est gratuite. les journaux du plan de contrôle, les métriques du plan de contrôle sous-ensemble sélectionné de métriques d'état Kube activé par défaut pour les clusters GKE sur Google Cloud enregistré au moment de la création du cluster dans un projet compatible avec GKE Enterprise. Les journaux du plan de contrôle entraînent des frais Cloud Logging, tandis que les métriques activées par défaut sont inclus sans frais supplémentaires.

Pour obtenir la liste des journaux et métriques GKE inclus, consultez Quels journaux sont collectés ? Métriques disponibles.

Dans un cluster Google Distributed Cloud, les journaux et métriques système de GKE Enterprise incluent les éléments suivants:

• Journaux et métriques de tous les composants d'un cluster d'administrateur
• Journaux et métriques des composants de ces espaces de noms dans un cluster d'utilisateur : kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system

Questions fréquentes

Quelles fonctionnalités du produit sont gratuites ?

L'utilisation des produits d'observabilité Google Cloud est facturée en fonction du volume de données. En dehors de la volume de données détaillé sur cette page, utilisation de toutes les ressources Les fonctionnalités du produit Google Cloud Observability sont gratuites.

À combien s'élèveront mes coûts ?

Pour estimer vos coûts d'utilisation, consultez la page Estimer vos factures.

Si vous avez des questions, consultez la page Questions sur la facturation.

Comment comprendre les détails de mon utilisation ?

Plusieurs métriques vous permettent d'explorer et d'analyser le volume de vos journaux et métriques à l'aide de l'explorateur de métriques. Pour en savoir plus, consultez la section Afficher l'utilisation détaillée dans l'explorateur de métriques.

Si vous souhaitez apprendre à gérer vos coûts, consultez ces articles de blog messages:

• Tarifs de Cloud Logging pour les administrateurs Cloud : comment les aborder et faire des économies
• Quatre étapes pour gérer vos coûts Cloud Logging avec un budget

Comment les champs d'application des métriques affectent-ils la facturation ?

Dans la plupart des cas, les champs d'application des métriques n'ont pas d'incidence sur la facturation. Les journaux et les métriques sont facturés au projet Google Cloud qui reçoit les données. Le champ d'application des métriques pour un projet définit la collection de projets dont les métriques peuvent être affichées et surveillées par ce projet. Lorsque vous définissez un champ d'application de métriques, cela n'a aucune incidence sur le projet qui reçoit les données de métrique ou sur la duplication des données.

Par exemple, supposons que votre organisation dispose de 100 machines virtuelles (VM) : 60 VM sont hébergées dans le projet A et 40 VM dans le projet B. Le projet A reçoit et stocke les métriques de ses VM. Il est facturé lorsque les métriques sont facturables. De même, le projet B reçoit et stocke les métriques de ses VM, et il est facturé lorsque ces métriques sont facturables. Si vous créez un champ d'application de métriques qui inclut les projets A et B, vous pouvez afficher les métriques combinées des 100 VM. Vous pouvez désormais afficher uniquement les métriques du projet A, uniquement celles du projet B ou l'ensemble des métriques des deux projets. Bien qu'il existe deux façons d'afficher les métriques du projet A, cela n'a aucune implication en termes de facturation.

Dans le cas de la surveillance de comptes AWS, vous devez connecter AWS à Google Cloud en créant Projet de connecteur AWS : Le projet de connecteur contient les journaux et les données de surveillance du compte AWS.

Que se passe-t-il si je dépasse les attributions gratuites ?

Vous êtes automatiquement facturé pour toute utilisation au-delà de vos attributions gratuites. Vous ne perdez aucun journal ni aucune métrique. Pour mieux comprendre l'estimation de vos coûts, consultez la page Estimer vos factures.

Vous pouvez créer une règle d'alerte qui surveille votre utilisation et vous avertit lorsque vous approchez du seuil de facturation.

Mes projets comportent un grand nombre de journaux Google Cloud que je n'utilise pas. Les frais liés à ces journaux me préoccupent. Comment puis-je les éviter ?

Vous pouvez exclure des journaux pour contrôler ceux qui sont ingérés dans Logging. Consultez la section consacrée à la réduction de votre utilisation des journaux pour plus d'informations.

Les services qui envoient des journaux à mon projet recevront-ils une erreur si les journaux sont exclus ?

Non. Les services qui envoient des entrées de journaux ne peuvent pas déterminer si ces entrées sont ingérées dans Logging ou non.

Serai-je facturé deux fois pour les journaux de flux Virtual Private Cloud ?

Si vous envoyez vos journaux de flux VPC à Logging, les frais de génération des journaux de flux VPC sont annulés, et seuls les frais de Logging s'appliquent. Toutefois, si vous exportez vos journaux de flux VPC vers Logging, puis les supprimez de ce service, les frais de génération des journaux vous seront facturés. Pour en savoir plus, consultez Simulateur de coût Google Cloud Sélectionnez ensuite l'onglet intitulé "Cloud Load Balancing et services réseau".

¹ À des fins de tarification, toutes les unités sont traitées comme mesures binaires. Exemple : mébioctets (Mio ou 2²⁰ octets) ou gibioctets (Gio, ou 2³⁰ octets).

² Il n'y a aucuns frais Les métriques Google Cloud ou GKE Enterprise mesurée jusqu'à 1 point de données par minute, la résolution la plus élevée actuellement. À l'avenir, les métriques mesurées à des résolutions plus élevées pourront entraîner des frais.

³ Les métriques de processus sont actuellement collectées à une fréquence par défaut prédéfinie par minute et ne peut pas être modifiée. Comme ces données changent généralement lentement, ces métriques sont actuellement suréchantillonnées. Par conséquent, les métriques de processus facturées à 5 % du tarif standard sont alignées sur ce tarif si elles ont été échantillonnées à des intervalles de 20 minutes. Les utilisateurs qui collectent 100 Mio de données à partir de ces métriques ne sont facturés que pour 5 Mio.

Étape suivante

• Lisez la documentation sur l'observabilité Google Cloud.
• Essayez le Simulateur de coût.
• Découvrez les solutions d'observabilité Google Cloud et les cas d'utilisation.

Demander un devis personnalisé

Avec le paiement à l'usage de Google Cloud, vous ne payez que pour les services que vous utilisez. Contactez notre équipe commerciale pour obtenir un devis personnalisé pour votre entreprise.

Contacter le service commercial