Tarifs de Google Cloud Observability

La tarification de Google Cloud Observability vous permet de contrôler votre utilisation et vos dépenses. La tarification des produits Google Cloud Observability se base sur le volume de données ou l'utilisation. Vous pouvez bénéficier d'attributions de consommation gratuite des données pour vous lancer, sans frais initiaux ni engagements.

Les documents suivants peuvent également vous intéresser :

• Exemples de tarification.
• Estimer vos factures.
• Optimisez et surveillez vos coûts.

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

Synthèse des tarifs Cloud Logging

^*  Le volume de stockage comptabilise la taille réelle des entrées de journal avant l'indexation. Aucuns frais de stockage ne sont facturés pour les journaux stockés dans le _Requiredbucket de journaux.
^†  Les journaux vendus sont des journaux Google Cloud de mise en réseau générés par les Google Cloud services lorsque la génération de ces journaux est activée. Les journaux vendus incluent les journaux de flux VPC, les journaux des règles de pare-feu et les journaux Cloud NAT. Ces journaux sont également soumis aux tarifs de la télémétrie réseau. Pour en savoir plus, consultez la section Journaux vendus.
^‡  Il n'y a aucuns frais de conservation pour les journaux stockés dans le bucket de journaux _Required, dont la durée de conservation est fixée à 400 jours.
^♣  Le routage des journaux est défini comme le transfert des journaux reçus via l'API Cloud Logging vers une destination compatible. Des frais de destination peuvent s'appliquer aux journaux acheminés.
^♥  Aucuns frais ne s'appliquent à la mise à niveau d'un bucket de journaux pour utiliser l'Analyse de journaux ou à l'émission de requêtes SQL à partir de la page Analyse de journaux.
Remarque : La langue de tarification de Cloud Logging a changé le 19 juillet 2023. Toutefois, les attributions gratuites et les tarifs restent les mêmes. Il se peut que votre facture fasse référence à l'ancienne langue de tarification.

Synthèse des tarifs Cloud Monitoring

^†  Google Cloud Managed Service pour Prometheus utilise l'espace de stockage de Cloud Monitoring pour stocker les données de métriques créées en externe, et utilise l'API Monitoring pour récupérer ces données. Managed Service pour Prometheus effectue des mesures basées sur les échantillons ingérés au lieu des octets, conformément aux conventions de Prometheus. Pour en savoir plus sur la mesure basée sur l'échantillonnage, consultez Optimiser les coûts de Managed Service pour Prometheus. 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 au compte de facturation dans lequel elles sont définies. Pour en savoir plus, consultez Tarifs pour l'exécution des tests de disponibilité.
^*  Les exécutions sont facturées au compte de facturation dans lequel elles sont définies. Pour chaque exécution, des frais supplémentaires peuvent s'appliquer à d'autres Google Cloud services, tels que les fonctions Cloud Run, 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 la section Tarifs des alertes.
^♥  Les appels d'API en lecture émis via la Google Cloud console ne sont pas facturés, à l'exception de ceux émis via Cloud Shell. Les appels d'API en lecture qui ne sont pas émis via la Google Cloud console et qui peuvent renvoyer des données de séries temporelles sont facturés en fonction du nombre de séries temporelles renvoyées ou d'une série temporelle, selon la valeur la plus élevée. Les autres appels en lecture de l'API sont sans frais. Pour en savoir plus, consultez la tarification de l'API Cloud Monitoring.

Synthèse des tarifs Cloud Trace

Pour en savoir plus sur les coûts liés aux produits Google Cloud Observability, consultez 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 la page GKE Enterprise.

Cloud Logging

Les buckets de journaux sont les conteneurs Logging qui stockent les données des journaux. Logging facture le volume de données de journaux stockées dans le bucket de journaux _Default et dans les buckets de journaux définis par l'utilisateur. Les tarifs s'appliquent aux journaux réseau non vendus lorsque le volume dépasse l'allocation mensuelle gratuite, et aux journaux réseau vendus.

Pour le bucket de journaux _Default et les buckets de journaux définis par l'utilisateur, Logging facture également les journaux conservés au-delà de la période de conservation par défaut, qui est de 30 jours.

Logging ne facture pas de frais supplémentaires pour les opérations suivantes :

• Router les journaux
• Utiliser l'API Cloud Logging
• Créer des champs d'application de journal
• Créer des vues analytiques
• Les journaux stockés dans le bucket de journaux _Required, dont la durée de conservation est fixée à 400 jours.

Cette section fournit des informations sur les sujets suivants :

• Modèle de stockage de Cloud Logging
• Tarifs du stockage
• Tarifs de fidélisation
• Tarifs des journaux réseau vendus
• Tarification des métriques basées sur les journaux

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.

Modèle de stockage Cloud Logging

Pour chaque Google Cloud projet, Logging crée automatiquement deux buckets de journal : _Required et _Default. Pour ces deux buckets, Logging crée automatiquement des récepteurs de journaux nommés _Required et _Default qui acheminent les journaux vers les buckets de journaux nommés correspondants. Vous ne pouvez pas 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 stocker de nouveaux journaux.

Vous pouvez créer des buckets de journaux définis par l'utilisateur dans n'importe lequel de vos Google Cloud projets. Vous pouvez également configurer des récepteurs pour acheminer n'importe quelle combinaison de journaux, même entre plusieurs Google Cloud projets dans votreGoogle Cloud organisation, vers ces buckets de journaux.

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

Vous pouvez mettre à niveau vos buckets de journaux pour utiliser l'Analyse de journaux. Aucuns frais ne s'appliquent à la mise à niveau d'un bucket de journaux pour utiliser l'Analyse de journaux.

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

Tarifs de stockage

Logging facture le projet dans lequel les journaux sont diffusés dans des buckets de journaux pour le stockage, une fois l'allocation mensuelle gratuite dépassée. Pour chaque projet, les frais sont basés sur le volume de journaux transférés dans ses buckets de journaux définis par l'utilisateur et dans son bucket de journaux _Default.

Logging ne facture pas le routage des journaux. Supposons qu'une entrée de journal provienne d'un projet, mais que ce projet ne stocke pas l'entrée de journal dans l'un de ses buckets de journaux. Dans ce scénario, le projet n'est pas facturé pour l'entrée de journal. Toutefois, si le projet achemine l'entrée de journal vers un bucket de journaux dans un autre projet, c'est le projet de destination qui est facturé pour cette entrée de journal.

Lorsqu'une entrée de journal est écrite dans un bucket de journaux autre que le bucket de journaux _Required, le projet qui contient ce bucket de journaux est facturé pour le stockage de cette entrée de journal. Par exemple, si une entrée de journal est acheminée vers trois buckets de journaux situés dans le même projet, ce projet est facturé trois fois pour l'entrée de journal. De même, si une entrée de journal est acheminée vers deux buckets de journaux, mais que ces buckets se trouvent dans des projets différents, les projets qui stockent ces buckets de journaux sont chacun facturés pour une entrée de journal.

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 Google Workspace pour les administrateurs
• Journaux d'audit des groupes Enterprise
• Journaux d'audit de connexion
• Les journaux Access Transparency. Pour savoir comment activer les journaux Access Transparency, consultez la documentation sur les journaux Access Transparency.

Tarifs de conservation

Le tableau suivant répertorie les périodes de conservation des données pour les journaux stockés dans des 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 frais de conservation lorsque les journaux sont conservés au-delà de la durée de conservation par défaut. Vous ne pouvez pas configurer la période de conservation pour le bucket de journaux _Required. Aucuns frais de conservation ne sont facturés lorsque les journaux sont stockés uniquement pendant la durée de conservation par défaut du bucket de journaux.

Si vous raccourcissez la période de conservation d'un bucket de journaux, une période de grâce de sept jours s'applique pendant laquelle les journaux expirés ne sont pas supprimés. Vous ne pouvez pas interroger ni afficher les journaux expirés. Toutefois, pendant ces sept jours, vous pouvez rétablir l'accès complet en prolongeant la période de conservation du bucket de journaux. Les journaux stockés pendant le délai de grâce sont pris en compte dans vos coûts de conservation.

Si vous acheminez une entrée de journal vers plusieurs buckets de journaux, les coûts de stockage et de conservation peuvent vous être facturés plusieurs fois. Par exemple, supposons que vous acheminiez une entrée de journal vers le bucket de journaux _Default et vers un bucket de journaux défini par l'utilisateur. Supposons également que vous configurez une période de conservation personnalisée pour les deux buckets, qui est supérieure à 30 jours. Pour cette configuration, vous recevez deux frais de stockage et deux frais de conservation.

Tarifs des journaux réseau vendus

Les journaux réseau vendus ne sont disponibles que si vous configurez la génération de journaux. Les services qui génèrent des journaux réseau vendus facturent la génération de journaux. Si vous stockez ces journaux dans un bucket de journaux ou si vous les acheminez vers une autre destination compatible, vous serez également soumis aux frais de Cloud Logging ou de la destination. Pour en savoir plus sur les coûts de génération des journaux, consultez la page Tarifs de la télémétrie réseau.

Pour savoir comment activer les journaux réseau vendus, consultez les pages Configurer les journaux de flux VPC, Utiliser la journalisation des règles de pare-feu et Cloud NAT : journaux et métriques.

Pour trouver vos journaux réseau vendus, dans l'explorateur de journaux, filtrez par les noms de journaux suivants :

• projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows
• projects/PROJECT_ID/logs/compute.googleapis.com%2Ffirewall
• projects/PROJECT_ID/logs/compute.googleapis.com%2Fnat_flows
• projects/PROJECT_ID/logs/networkmanagement.googleapis.com%2Fvpc_flows

Tarification 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 Google Cloud projets 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.

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.

• Exécution de tests de disponibilité

• Exécution de la surveillance synthétique

• Conditions des règles d'alerte mesurées par le 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 :

• Tarifs de l'API Cloud Monitoring
• Définitions des métriques facturables et non facturables.
• Description des stratégies d'ingestion byte- et des échantillons.

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

Tarifs de l'API Cloud Monitoring

Les appels d'API Monitoring en écriture sont gratuits.

Du 1er juillet 2018 au 1er octobre 2025, les appels d'API de lecture Monitoring sont facturés une unité par appel.

À partir du 2 octobre 2025, les coûts des API en lecture de Monitoring seront déterminés par le nombre de séries temporelles renvoyées :

• Les appels d'API en lecture émis via la Google Cloud console ne sont pas facturés, à l'exception de ceux émis via Cloud Shell.

• Les appels d'API en lecture qui ne peuvent pas renvoyer de données de séries temporelles sont sans frais.

• Tous les autres appels d'API en lecture sont facturés en fonction du nombre de séries temporelles renvoyées ou d'une série temporelle, selon la valeur la plus élevée. Par exemple, un appel à timeSeries.list peut renvoyer plusieurs séries temporelles. L'API Cloud Monitoring peut être appelée indirectement. Par exemple, les commandes Google Cloud CLI, les bibliothèques clientes et les outils tiers comme Grafana peuvent émettre des commandes d'API de lecture.

Métriques non facturables

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

• Google Cloud métriques. 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 appartenant au type de métrique agent.googleapis.com, à l'exception du 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ées 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 entre dans cette catégorie.

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

• Les métriques personnalisées, y compris, mais sans s'y limiter, celles envoyées à l'aide de l'API Cloud Monitoring ou des bibliothèques clientes spécifiques à un langage, d'OpenCensus et d'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.

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

Frais de Monitoring pour chaque exécution régionale d'un test de disponibilité au-delà de l'allocation mensuelle gratuite d'un million d'exécutions. Un contrôle qui s'exécute dans trois régions compte pour trois exécutions.

Le coût d'exécution des tests de disponibilité est de 0,30 $pour 1 000 exécutions. Sur votre facture, les frais apparaissent sous le SKU "CA14-D3DE-E67F" pour "Surveillance des vérifications de disponibilité".

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

Cloud Monitoring facture chaque exécution d'un test synthétique au-delà de l'allocation mensuelle gratuite de 100 exécutions par compte de facturation.

Tarifs des alertes

À partir du 1er mai 2026 au plus tôt, Cloud Monitoring commencera à facturer les alertes. Le modèle de tarification est le suivant :

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

Cette section fournit les informations suivantes :

• Définitions de la terminologie liée aux alertes
• Informations sur la désactivation de la facturation pour les règles d'alerte

Définitions

• Condition : la condition d'une règle d'alerte décrit le moment où une ressource ou un groupe de ressources se trouve dans un état nécessitant une réponse.

  • Les règles d'alerte qui utilisent des filtres pour créer des requêtes de seuil de métrique ou d'absence de métrique peuvent combiner jusqu'à six conditions.
  • Les règles d'alerte avec les types de requêtes suivants ne peuvent comporter qu'une seule condition :
    • Requête Prometheus Query Language (PromQL),
    • Langage MQL (Monitoring Query Language)
    • Correspondance de journaux, utilisée dans les alertes basées sur les journaux.

  Le coût est de 0,10 $par condition et par mois. Pour ne plus être facturé pour une condition, vous devez supprimer la règle d'alerte. Mettre en veille ou désactiver la règle ne vous empêche pas d'être facturé.

• Règles d'alerte basées sur les métriques et basées sur les journaux : les règles d'alerte qui utilisent un type de condition autre que les conditions de correspondance de journaux sont des règles d'alerte basées sur les métriques. 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 des métriques exécutent leurs requêtes sur le datastore Cloud Monitoring. Les séries temporelles renvoyées sont ensuite évaluées par rapport à un seuil pour déterminer si la règle d'alerte doit être déclenchée.

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

• Période d'exécution : fréquence à laquelle Cloud Monitoring exécute votre condition. Pour la plupart des types de conditions, ce délai 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 Augmenter la durée de la période d'exécution (PromQL uniquement).

• Séries temporelles renvoyées : pendant chaque période d'exécution, une règle d'alerte basée sur les métriques exécute la requête de sa condition sur le datastore Cloud Monitoring. 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 pour une série temporelle renvoyée.

  Le nombre de séries temporelles renvoyées par 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.
  • La période d'exécution

Désactivation…

Si vous avez un contrat en cours qui n'expire pas avant le 1er mai 2026, vous pouvez demander une dérogation à l'équipe de facturation des alertes Cloud Monitoring pour retarder la facturation des alertes jusqu'à la date de renouvellement de votre contrat. Google Cloud Les demandes de dérogation pour les clients ayant des contrats actifs seront examinées au cas par cas.

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

Error Reporting

Vous pouvez signaler les données d'erreur à votre Google Cloud projet à l'aide de l'API Error Reporting ou de l'API Cloud Logging.

L'utilisation d'Error Reporting n'entraîne aucun frais. Toutefois, des frais Cloud Logging peuvent s'appliquer, car les entrées de journaux sont générées, puis stockées par Cloud Logging.

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 aucun coût.

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. Les données de trace peuvent être ingérées via l'API Cloud Trace ou l'API Telemetry. La configuration des champs d'application des traces est gratuite.

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 connaître les limites qui s'appliquent à votre utilisation de Trace, consultez la page Quotas et limites.

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 Run Functions ou Cloud Run : l'ingestion de ces traces est gratuite.

Les traces générées automatiquement ne consomment pas de quota d'API Cloud Trace et sont exclues des métriques d'utilisation de l'API Cloud Trace.

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é.

GKE Enterprise

Pour un cluster GKE Enterprise, les métriques du plan de contrôle, les métriques Kube State sélectionnées, les métriques cAdvisor/Kubelet et les métriques DCGM ne sont pas facturées. Les journaux système, les journaux du plan de contrôle et les journaux de charge de travail entraînent des frais Cloud Logging. Les journaux du plan de contrôle, les métriques du plan de contrôle, les métriques Kube State, les métriques cAdvisor/Kubelet et les métriques DCGM sont activés par défaut pour les clusters GKE Google Cloud enregistrés au moment de la création du cluster dans un projet sur lequel GKE Enterprise est activé. Pour obtenir la liste des journaux et métriques GKE inclus, consultez les pages Journaux collectés et Métriques disponibles.

Dans un cluster Google Distributed Cloud, les journaux système et les métriques GKE Enterprise sont gratuits. Ils 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 Google Cloud Observability est facturée selon le volume de données. Outre les coûts des volumes de données décrits sur cette page, l'utilisation de toutes les fonctionnalités produit supplémentaires de Google Cloud Observability est gratuite.

À 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 savoir comment gérer vos coûts, consultez ces articles de blog :

• 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 dans un budget

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

Dans la plupart des cas, les champs d'application des métriques, les champs d'application des journaux et les champs d'application des traces n'ont pas d'incidence sur la facturation.

Les journaux, les métriques et les traces sont facturés au projet, au compte de facturation, au dossier ou à l'organisation qui reçoit les données. Le champ d'application des métriques pour un projet définit la collection de ressources 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 la ressource qui reçoit les données de métrique ou sur la duplication des données. Un champ d'action des journaux ne répertorie que les ressources qui stockent ou acheminent les entrées de journal que vous souhaitez afficher. De même, un champ d'application de trace ne liste que les ressources qui stockent les données de trace que vous souhaitez afficher.

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.

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 Google Cloud journaux 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 Réduire 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 le Google Cloud simulateur de coût, puis sélectionnez l'onglet "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).

² Aucuns frais ne s'appliquent aux métriquesGoogle Cloud ou GKE Enterprise mesurées jusqu'à 1 point de données par minute, ce qui correspond actuellement à la résolution la plus élevée. À 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 Google Cloud Observability.
• Essayez le Simulateur de coût.
• Découvrez les solutions et cas d'utilisation de Google Cloud Observability.