Optimisation des coûts pour Google Cloud Observability

Google Cloud Observability comprend un ensemble de services gérés basés sur le cloud, qui sont conçus pour offrir une visibilité étendue sur les services d'application et d'infrastructure. L'un des avantages des services gérés sur Google Cloud est que les services sont basés sur l'utilisation, ce qui signifie que vous ne payez que ce que vous utilisez. Même si ce modèle de tarification est susceptible d'offrir un avantage financier par rapport aux licences logicielles standards, il peut compliquer la prévision des coûts. Cette solution décrit comment vous pouvez comprendre votre utilisation de ces services et optimiser vos coûts.

Tarification

Les services de Google Cloud Observability étant des services gérés, ils vous permettent de vous concentrer sur les insights qu'ils fournissent, plutôt que sur l'infrastructure requise pour utiliser ces services. Lorsque vous utilisez ces services, vous n'avez pas à payer individuellement pour les machines virtuelles, les licences logicielles, l'analyse de sécurité, la maintenance matérielle ou l'espace dans un centre de données. Les services offrent un coût par utilisation simple.

Les coûts couvrent les frais de Cloud Logging, Cloud Monitoring et Cloud Trace. Le produit de journalisation Error Reporting ne génère aucun coût distinct tant qu'il est en version bêta. Par ailleurs, vous pouvez utiliser Cloud Profiler sans frais. Pour Stackdriver Error Reporting, des frais minimes peuvent vous être facturés si vos erreurs sont ingérées par Logging.

Vous pouvez également lire un résumé de toutes les informations tarifaires.

Coûts de Logging et de Error Reporting

Les tarifs applicables à Logging sont basés sur le volume de journaux payants ingérés. Cette tarification simplifie les coûts qui sont calculés par Gio. L'utilisateur bénéficie d'une attribution mensuelle gratuite et certains journaux, tels que les journaux d'audit Cloud, ne sont pas payants.

Voici quelques exemples d'utilisations de produits qui engendrent des coûts en générant davantage de journaux :

• Cloud Load Balancing
• Agent Logging utilisé sur Compute Engine
• Agent Logging utilisé sur AWS (Amazon Web Services)
• Opération d'écriture dans l'API Cloud Logging

Coûts liés à Monitoring

Les tarifs applicables à Monitoring sont basés sur le volume de métriques payantes ingérées et le nombre d'appels d'API facturables. Par exemple, les métriques non Google Cloud (telles que les métriques associées aux agents, personnalisées, externes ou AWS) sont payantes. La méthode projects.timeSeries.list de l'API Cloud Monitoring est facturée par appel d'API, tandis que le reste de l'utilisation de l'API est gratuit. L'utilisateur bénéficie d'une attribution mensuelle gratuite d'un certain volume de métriques, dont beaucoup, y compris toutes les métriques Google Cloud, ne sont pas payantes. Pour en savoir plus sur les métriques payantes, consultez la section Tarifs Monitoring.

Voici quelques exemples d'utilisations de produits qui engendrent des coûts en générant des métriques et des appels d'API :

• Métriques personnalisées Monitoring
• Agent Monitoring utilisé sur Compute Engine
• Agent Monitoring utilisé sur AWS
• Opération de lecture dans l'API Monitoring

Coûts liés à Trace

Les tarifs applicables à Trace sont basés sur le nombre de délais ingérés et analysés à terme. Certains services Google Cloud, tels que l'environnement standard App Engine, génèrent automatiquement des délais non facturables. L'utilisateur bénéficie d'une attribution gratuite mensuelle pour Trace.

Voici quelques exemples d'utilisations de produits qui engendrent des coûts liés à l'ingestion de délai et requièrent une instrumentation supplémentaire :

• Délais (autres que les valeurs par défaut) pour les applications App Engine
• Cloud Load Balancing ;
• Applications personnalisées

Utilisation

L'analyse de votre utilisation peut vous permettre de déterminer quels composants génèrent des coûts. Vous pourrez ainsi identifier les domaines susceptibles d'être optimisés.

Analyse de la facture Google Cloud

La première étape pour comprendre votre utilisation consiste à examiner votre facture Google Cloud et à comprendre vos coûts. Pour obtenir des insights, vous pouvez utiliser les rapports de facturation disponibles dans Google Cloud Console.

La page "Rapports" fournit divers filtres utiles pour affiner les résultats par heure, projet, produit, SKU et libellé. Le filtre "Produits" permet de limiter les données de facturation aux coûts de surveillance et de journalisation.

Logging

L'API Logging présente des listes détaillées de journaux, ainsi que le volume de journaux actuel et le volume mensuel prévu pour chaque projet. Vous pouvez consulter ces informations pour chaque projet tout en examinant vos frais Logging sur votre facture Google Cloud. Cela vous permet de déterminer facilement quels journaux représentent le volume le plus élevé et, par conséquent, la part la plus importante des coûts.

Le volume de journaux ingérés dans votre projet est indiqué sur la page Stockage des journaux. La page Stockage des journaux fournit une liste des journaux et leurs volumes pour le mois précédent et le mois en cours, ainsi que leurs volumes prévus pour la fin du mois.

Cette analyse vous permet de mieux évaluer l'utilisation des journaux dans des projets spécifiques et l'évolution de leur volume au fil du temps. Vous pouvez vous en servir pour identifier les journaux susceptibles d'être optimisés.

Surveillance

Organisé en champs d'application des métriques, Monitoring fournit une liste détaillée des projets, ainsi que des volumes de métriques précédents, actuels et prévus. Comme un champ d'application des métriques peut inclure plusieurs projets, les volumes de chaque projet sont répertoriés séparément, comme illustré dans l'image suivante.

Découvrez comment afficher les données d'utilisation de Monitoring.

Vous pouvez afficher le graphique détaillé du volume de métriques pour chaque projet dans l'explorateur de métriques de Monitoring. Vous aurez ainsi un aperçu du volume de métriques ingérées au fil du temps.

Cette analyse vous fournit les volumes de métriques Monitoring pour chaque projet que vous avez identifié lors de l'examen de vos frais Monitoring sur votre facture Google Cloud. Vous pouvez ensuite examiner des volumes de métriques spécifiques, et identifier les composants représentant le volume le plus élevé et la part la plus importante des coûts.

Trace

Trace fournit une vue détaillée des délais ingérés pour le mois en cours et le mois précédent. Vous pouvez consulter ces détails dans la console Google Cloud pour chaque projet que vous identifiez tout en examinant vos frais Trace sur votre facture Google Cloud.

Cette analyse vous fournit le nombre de délais ingérés pour chaque projet dans un espace de travail que vous avez identifié lors de l'examen de vos frais Trace sur votre facture Google Cloud. Ensuite, vous pouvez examiner un nombre spécifique de délais ingérés, et identifier les projets et services générant le plus de délais et de coûts.

Exporter des journaux Logging

Logging fournit un récepteur de journaux pour exporter les journaux vers Cloud Storage, BigQuery et Pub/Sub.

Par exemple, si vous exportez tous vos journaux de Logging vers BigQuery pour le stockage et l'analyse à long terme, vous serez facturé des coûts BigQuery, y compris le stockage par Gio, l'insertion en flux continu et les coûts des requêtes.

Pour analyser les coûts générés par vos exportations, effectuez les opérations suivantes :

1. Recherchez les récepteurs de journaux. Identifiez les récepteurs de journaux que vous avez activés, le cas échéant. Par exemple, plusieurs récepteurs de journaux peuvent avoir été créés pour votre projet à différentes fins, telles que la mise en œuvre d'opérations de sécurité ou la satisfaction d'exigences réglementaires.
2. Examinez les données d'utilisation. Analysez l'utilisation en fonction de la destination des exportations (par exemple, les tailles de table BigQuery pour les exportations BigQuery ou les tailles de bucket pour les exportations Cloud Storage).

Rechercher les récepteurs de journaux

Vos récepteurs de journaux peuvent être au niveau du projet (un ou plusieurs récepteurs par projet) ou au niveau de l'organisation Google Cloud, appelés exportations agrégées. Les récepteurs peuvent inclure les journaux de nombreux projets dans la même organisation Google Cloud.

Vous pouvez afficher vos récepteurs de journaux en consultant des projets spécifiques. La console Google Cloud fournit une liste des récepteurs et de la destination. Pour afficher les exportations agrégées de votre organisation, vous pouvez utiliser la ligne de commande gcloud logging sinks list --organization ORGANIZATION_ID.

Examiner les données d'utilisation

Monitoring fournit un ensemble complet de métriques non seulement pour vos applications, mais également pour l'utilisation de votre produit Google Cloud. Vous pouvez obtenir des métriques d'utilisation détaillées pour Cloud Storage, BigQuery et Pub/Sub en consultant les métriques d'utilisation dans l'explorateur de métriques.

Remarque : Les espaces de travail peuvent inclure plusieurs projets. Utilisez l'espace de travail qui inclut le bucket Cloud Storage, l'ensemble de données BigQuery et les sujets Pub/Sub utilisés pour l'exportation, afin d'afficher les détails d'utilisation.

Cloud Storage

L'explorateur de métriques de Monitoring vous permet d'afficher la capacité de stockage de vos buckets Cloud Storage. Servez-vous des valeurs ci-dessous dans l'explorateur de métriques pour afficher la capacité de stockage des buckets Cloud Storage utilisés pour les récepteurs de journaux.

Pour afficher les métriques d'une ressource surveillée à l'aide de l'explorateur de métriques, procédez comme suit :

1. Dans le panneau de navigation de la console Google Cloud, sélectionnez Monitoring, puis  Explorateur de métriques :

   Accéder à l'explorateur de métriques

2. Dans l'élément Métrique, développez le menu Sélectionner une métrique, saisissez Total bytes dans la barre de filtre, puis utilisez les sous-menus pour sélectionner un type de ressource et des métriques spécifiques :
   1. Dans le menu Ressources actives, sélectionnez Bucket GCS.
   2. Dans le menu Catégories de métriques actives, sélectionnez Stockage.
   3. Dans le menu Métriques actives, sélectionnez Nombre total d'octets.
   4. Cliquez sur Appliquer.
   Le nom complet de cette métrique est storage.googleapis.com/storage/total_bytes.
3. Configurez le mode d'affichage des données.
   • Dans l'élément Filtre, cliquez sur Ajouter un filtre, puis sélectionnez project_id. Pour la valeur, sélectionnez votre ID de projet Google Cloud.
   • Dans l'élément Filtre, cliquez sur Ajouter un filtre, puis sélectionnez bucket_name. Pour la valeur, sélectionnez le nom de votre bucket d'exportation Cloud Storage.
   • Dans l'entrée Agrégation, définissez le premier menu sur Non agrégé.

   Pour plus d'informations sur la configuration d'un graphique, consultez la page Sélectionner des métriques lors de l'utilisation de l'explorateur de métriques.

Le graphique précédent indique la taille des données (en To) exportées au fil du temps, ce qui donne un aperçu de l'utilisation de la fonctionnalité d'exportation des journaux Logging vers Cloud Storage.

BigQuery

L'explorateur de métriques de Monitoring vous permet d'afficher la capacité de stockage de votre ensemble de données BigQuery. Servez-vous des valeurs ci-dessous dans l'explorateur de métriques pour afficher la capacité de stockage de l'ensemble de données BigQuery utilisé pour le récepteur de journaux.

Pour afficher les métriques d'une ressource surveillée à l'aide de l'explorateur de métriques, procédez comme suit :

1. Dans le panneau de navigation de la console Google Cloud, sélectionnez Monitoring, puis  Explorateur de métriques :

   Accéder à l'explorateur de métriques

2. Dans l'élément Métrique, développez le menu Sélectionner une métrique, saisissez Stored bytes dans la barre de filtre, puis utilisez les sous-menus pour sélectionner un type de ressource et des métriques spécifiques :
   1. Dans le menu Ressources actives, sélectionnez Ensemble de données BigQuery.
   2. Dans le menu Catégories de métriques actives, sélectionnez Stockage.
   3. Dans le menu Métriques actives, sélectionnez Octets stockés.
   4. Cliquez sur Appliquer.
   Le nom complet de cette métrique est bigquery.googleapis.com/storage/stored_bytes.
3. Configurez le mode d'affichage des données.
   • Dans l'élément Filtre, cliquez sur Ajouter un filtre, puis sélectionnez project_id. Pour la valeur, sélectionnez votre ID de projet Google Cloud.
   • Dans l'élément Filtre, cliquez sur Ajouter un filtre, puis sélectionnez dataset_id. Pour la valeur, sélectionnez le nom de votre ensemble de données d'exportation BigQuery.
   • Dans l'entrée Agrégation, définissez le premier menu sur Moyenne et le second menu sur dataset_id.
   • Dans le volet Affichage, définissez le type de widget sur Graphique à barres empilées.
   • Définissez une période d'au moins un jour.

   Pour plus d'informations sur la configuration d'un graphique, consultez la page Sélectionner des métriques lors de l'utilisation de l'explorateur de métriques.

Le graphique précédent indique la taille de l'ensemble de données d'exportation (en To) au fil du temps, ce qui donne un aperçu de l'utilisation de la fonctionnalité d'exportation des journaux Logging vers BigQuery.

Pub/Sub

En utilisant l'explorateur de métriques dans Monitoring, vous pouvez afficher le nombre de messages et la taille des messages exportés vers Pub/Sub. Servez-vous des valeurs ci-dessous dans l'explorateur de métriques pour afficher la capacité de stockage du sujet Pub/Sub utilisé pour le récepteur de journaux.

Pour afficher les métriques d'une ressource surveillée à l'aide de l'explorateur de métriques, procédez comme suit :

1. Dans le panneau de navigation de la console Google Cloud, sélectionnez Monitoring, puis  Explorateur de métriques :

   Accéder à l'explorateur de métriques

2. Dans l'élément Métrique, développez le menu Sélectionner une métrique, saisissez Byte cost dans la barre de filtre, puis utilisez les sous-menus pour sélectionner un type de ressource et des métriques spécifiques :
   1. Dans le menu Ressources actives, sélectionnez Sujet Cloud Pub/Sub.
   2. Dans le menu Catégories de métriques actives, sélectionnez Sujet.
   3. Dans le menu Métriques actives, sélectionnez Coût total des octets du sujet.
   4. Cliquez sur Appliquer.
   Le nom complet de cette métrique est pubsub.googleapis.com/topic/byte_cost.
3. Configurez le mode d'affichage des données.
   • Dans l'élément Filtre, cliquez sur Ajouter un filtre, puis sélectionnez project_id. Pour la valeur, sélectionnez votre ID de projet Google Cloud.
   • Dans l'élément Filtre, cliquez sur Ajouter un filtre, puis sélectionnez topic_id. Pour la valeur, sélectionnez le nom de votre sujet d'exportation Pub/Sub.
   • Dans l'entrée Agrégation, définissez le premier menu sur Non agrégé.

   Pour plus d'informations sur la configuration d'un graphique, consultez la page Sélectionner des métriques lors de l'utilisation de l'explorateur de métriques.

Le graphique précédent indique la taille des données (en Ko) exportées au fil du temps, ce qui donne un aperçu de l'utilisation de la fonctionnalité d'exportation des journaux Logging vers Pub/Sub.

Mettre en œuvre des contrôles de coûts

Les options ci-dessous offrent différentes solutions pour réduire les coûts. Chaque option a pour effet de limiter la visibilité dont vous disposez sur vos applications et votre infrastructure. Choisissez l'option offrant le meilleur compromis entre visibilité et coût.

Contrôle des coûts liés à Logging

Pour optimiser votre utilisation de l'API Logging, vous pouvez réduire le nombre de journaux qu'elle ingère. Plusieurs stratégies permettent de réduire le volume des journaux tout en conservant ceux dont vos développeurs et opérateurs ont besoin.

Exclure des journaux

Vous pouvez exclure des API Logging et Error Reporting la plupart des journaux dont les équipes chargées du développement et des opérations n'ont pas besoin.

L'exclusion des journaux signifie qu'ils n'apparaissent pas dans l'interface utilisateur Logging ou Error Reporting. Vous pouvez utiliser des filtres Logging pour sélectionner des entrées de journal spécifiques ou des journaux entiers à exclure. Il est également possible d'employer des règles d'exclusion d'échantillons pour exclure un pourcentage d'entrées de journaux. Par exemple, vous pouvez choisir d'exclure certains journaux si leur volume est élevé ou s'ils n'ont aucune valeur pratique.

Plusieurs exemples courants d'exclusion sont présentés ci-dessous.

• Exclusion des journaux de Cloud Load Balancing : les équilibreurs de charge peuvent générer un volume important de journaux pour les applications à fort trafic. Par exemple, vous pouvez utiliser un filtre de journaux afin de configurer une exclusion pour 90 % des messages de Cloud Load Balancing.

• Exclusion des journaux de flux de cloud privé virtuel (VPC Service Controls) : la fonctionnalité des journaux de flux inclut des journaux s'appliquant à chaque communication entre les machines virtuelles d'un réseau VPC Service Controls. Elle peut donc générer un volume important de journaux. Deux approches que vous pouvez utiliser conjointement ou séparément permettent de réduire le volume de journaux.

  • Exclusion en fonction du contenu des entrées de journaux : cette approche consiste à exclure la plupart des journaux de flux VPC en ne conservant que des messages de journaux spécifiques qui peuvent être utiles. Par exemple, si vous disposez de réseaux VPC privés ne devant pas recevoir de trafic entrant en provenance de sources externes, vous souhaiterez peut-être conserver uniquement les journaux de flux dont les champs sources correspondent à des adresses IP externes.
  • Exclusion en fonction d'un pourcentage : une autre approche consiste à n'échantillonner qu'un pourcentage des journaux identifiés par le filtre. Par exemple, vous pouvez exclure 95 % des journaux de flux et ne conserver que 5 % de ces derniers.

• Exclusion des réponses HTTP 200 OK des journaux de requêtes. les messages HTTP 200 OK peuvent ne pas fournir beaucoup d'informations et sont susceptibles de générer un volume important de journaux pour les applications à fort trafic.

Consultez la page Exclusions de journaux pour mettre en œuvre ces exclusions.

Exporter des journaux

Vous pouvez exporter des journaux tout en les empêchant d'être ingérés dans Logging. Cela vous permet de conserver les journaux dans Cloud Storage et BigQuery ou d'utiliser Pub/Sub pour traiter les journaux, tout en excluant les journaux de Logging, ce qui peut aider à réduire les coûts. Vos journaux ne s'affichent donc pas dans Logging, mais sont toutefois exportés.

Utilisez cette méthode pour conserver les journaux en vue d'une analyse à long terme sans avoir à payer les frais liés à l'ingestion dans Logging. Pour comprendre précisément comment les exclusions et les exportations interagissent, consultez le schéma représentant le cycle de vie d'un journal, qui illustre la façon dont les entrées de journaux exportées sont traitées dans Logging.

Réduire l'utilisation de l'agent Logging

Vous pouvez réduire le volume de journaux en n'envoyant pas les journaux supplémentaires générés par l'agent Logging à l'API Logging. L'agent Logging transmet les journaux des applications tierces courantes comme Apache, Mongodb et MySQL.

Par exemple, pour réduire le volume de journaux, n'installez pas l'agent Logging sur les machines virtuelles de l'environnement de développement ou d'autres environnements non essentiels. Vos machines virtuelles continuent à transmettre les journaux standards à Logging, mais pas les journaux d'applications tierces ni les journaux syslog.

Contrôle des coûts liés à Monitoring

Pour optimiser votre utilisation de l'API Monitoring, vous pouvez réduire le volume de métriques payantes qu'elle ingère et le nombre d'appels de lecture qu'elle reçoit. Plusieurs stratégies permettent de limiter le volume de métriques tout en conservant celles dont vos développeurs et opérateurs ont besoin.

Optimiser les métriques et l'utilisation des libellés

La manière dont vous utilisez les libellés dans les métriques personnalisées de Monitoring peut affecter le volume de séries temporelles générées.

Si vous disposez d'une métrique personnalisée avec deux libellés, par exemple des valeurs cost_center et env, vous pouvez calculer le nombre maximal de séries temporelles en multipliant la cardinalité des deux libellés.

total_num_time_series = cost_center_cardinality * env_cardinality

S'il existe 11 valeurs cost_center et 5 valeurs env, cela permet de générer jusqu'à 55 séries temporelles. C'est pourquoi l'ajout de libellés de métriques peut augmenter considérablement le volume de métriques et, par conséquent, le coût. Consultez l'article de blog Conseils et astuces pour Cloud Monitoring : analyser les métriques et créer des graphiques pour obtenir une description détaillée de la cardinalité des métriques.

Nous vous conseillons de suivre les recommandations suivantes pour réduire le nombre de séries temporelles :

• Si possible, réduisez le nombre de libellés de métriques personnalisées.
• Sélectionnez soigneusement les libellés pour éviter ceux ayant une cardinalité élevée. Par exemple, l'utilisation de user_id en tant que libellé entraîne au moins une série temporelle pour chaque utilisateur, ce qui peut être très volumineux si votre trafic est important.

Réduire l'utilisation des agents Monitoring

Les métriques envoyées par l'agent Monitoring sont payantes. L'agent Monitoring transmet les métriques d'application et de système issues d'applications tierces courantes (Apache, MySQL et Nginx, par exemple) ainsi que des métriques supplémentaires définies au niveau des VM Google Cloud. Si vous n'avez pas besoin de métriques système détaillées ni de métriques d'applications tierces pour certaines VM, vous pouvez ne pas envoyer ces métriques afin de réduire le volume. Vous avez également la possibilité de réduire le volume de métriques en limitant le nombre de VM utilisant l'agent Monitoring.

Par exemple, vous pouvez réduire les volumes de métriques en choisissant de ne pas ajouter de projets Google Cloud dans votre développement ou d'autres environnements non essentiels à Monitoring. En outre, vous pouvez choisir de ne pas installer l'agent Monitoring sur les VM de l'environnement de développement ou d'autres environnements non essentiels.

Réduire l'utilisation des métriques personnalisées

Les métriques personnalisées sont payantes. Créées à l'aide de l'API Monitoring, elles permettent de surveiller les métriques instrumentées par les utilisateurs. Vous pouvez créer ces métriques à l'aide de l'API Monitoring ou des intégrations.

OpenCensus fait partie de ces intégrations. Il s'agit d'une distribution de bibliothèques qui collectent des métriques et des traces distribuées à partir de vos applications. Les applications équipées d'OpenCensus peuvent transmettre des métriques à plusieurs backends, y compris Monitoring, à l'aide de métriques personnalisées. Ces métriques s'affichent dans Monitoring sous le type de ressource commençant par le préfixe custom.googleapis.com/opencensus. Par exemple, la latence aller-retour du client indiquée par OpenCensus apparaît dans Monitoring sous le type de ressource custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency.

Plus le nombre d'applications que vous instrumentez pour envoyer des métriques est élevé, plus vous générez de métriques de surveillance personnalisées. Pour réduire le volume de métriques, vous pouvez limiter le nombre de métriques de surveillance personnalisées qui sont envoyées par vos applications.

Contrôle des coûts liés à Trace

Pour optimiser l'utilisation de Trace, vous pouvez réduire le nombre de délais ingérés et analysés. Lorsque vous instrumentez votre application pour signaler des délais à Trace, vous utilisez l'échantillonnage pour ingérer une partie du trafic. L'échantillonnage est un élément clé du système de traçage, car il fournit des informations sur la répartition de la latence engendrée par les composants des applications, tels que les appels RPC. Il s'agit d'une bonne pratique d'utilisation de Trace. Vous pouvez par ailleurs choisir de limiter le volume de délais pour réduire les coûts.

Utiliser la fonctionnalité d'échantillonnage d'OpenCensus

Si vous utilisez Trace comme destination d'exportation pour vos traces OpenCensus, vous pouvez employer la fonctionnalité d'échantillonnage d'OpenCensus pour réduire le volume de traces ingérées.

Par exemple, si vous disposez d'une application Web populaire recevant 5 000 requêtes par seconde, vous pouvez obtenir suffisamment d'informations en échantillonnant 5 % de son trafic au lieu de 20 %. Cela permet de réduire le nombre de délais ingérés dans Trace à un quart.

Vous pouvez spécifier l'échantillonnage dans la configuration de l'instrumentation à l'aide des bibliothèques OpenCensus Python pour Trace. Par exemple, l'exportateur OpenCensus Python fournit une classe ProbabilitySampler permettant de spécifier un taux d'échantillonnage.

from opencensus.trace.samplers import probability
from opencensus.trace import tracer as tracer_module

# Sampling the requests at the rate equals 0.05
sampler = probability.ProbabilitySampler(rate=0.05)
tracer = tracer_module.Tracer(sampler=sampler)

Utiliser les quotas de délais de l'API Cloud Trace

Vous pouvez utiliser des quotas pour limiter l'utilisation de Trace et les coûts. Vous pouvez appliquer des quotas de délais à l'aide de la page des quotas spécifiques à l'API dans la console Google Cloud.

Si vous spécifiez un quota inférieur à celui défini par défaut pour le produit, vous vous assurez que votre projet ne dépassera pas la limite de quota indiquée. Cela vous permet de prévoir vos coûts. Vous pouvez surveiller ce quota à partir de la page des quotas propres aux API, comme illustré sur l'image suivante.

Si vous réduisez votre quota de délais, vous devez également envisager de surveiller les métriques de quota et de définir une règle d'alerte dans Monitoring, afin qu'une alerte soit envoyée lorsque l'utilisation se rapproche du quota. Cette alerte vous invite à vérifier l'utilisation ainsi qu'à identifier l'application et le développeur susceptibles de générer un grand volume de délais. Si vous définissez un quota de délais et s'il est dépassé, les délais sont supprimés jusqu'à ce que vous ajustiez le quota.

Par exemple, si votre quota est fixé à 50 millions de délais ingérés, vous pouvez définir une alerte se déclenchant lorsque vous avez utilisé 80 % du quota de l'API, ce qui correspond à 40 millions de délais. Suivez les instructions relatives à la gestion des règles d'alerte pour créer une règle d'alerte en utilisant les informations ci-dessous.

1. Dans Google Cloud Console, accédez à Surveillance ou utilisez le bouton suivant :
   Accéder à Surveillance
2. Dans le volet de navigation Monitoring, sélectionnez  Alertes, puis Créer une règle.
3. Saisissez le nom de la règle d'alerte.
4. Cliquez sur Ajouter une condition :
   1. Les paramètres du volet Cible permettent de spécifier la ressource et la métrique à surveiller. Cliquez sur la zone de texte pour activer un menu, puis sélectionnez la ressource global.
   2. Cliquez sur la zone de texte pour activer un menu, puis sélectionnez cloudtrace.googleapis.com/billing/monthly_spans_ingested.
   3. Ajoutez les valeurs ci-dessous pour le paramètre Filtre.
   • Cliquez sur project_id, puis sélectionnez l'ID de votre projet Google Cloud.
   • Cliquez sur chargeable, puis sélectionnez true.
   4. Les paramètres du volet Configuration de la règle d'alerte déterminent le moment où l'alerte se déclenche. Remplissez les champs suivants :
   • Pour Déclenchement de la condition si, sélectionnez À chaque infraction de série.
   • Pour Seuil, indiquez 40000000.
   • Pour, sélectionnez Valeur la plus récente
   5. Cliquez sur Enregistrer.

5. Cliquez sur Enregistrer.

   L'alerte générée par la règle est semblable à celle présentée ci-dessous. Elle affiche des informations sur le projet, la règle qui l'a générée et la valeur actuelle de la métrique.

Optimiser les appels tiers

Votre application peut être appelée par une autre application. Si elle signale des délais, le nombre de délais signalés peut dépendre du trafic entrant que vous recevez en provenance de l'application tierce. Par exemple, si un microservice frontend appelle un microservice de paiement et si les deux microservices sont équipés d'OpenCensus, le taux d'échantillonnage du trafic est au moins égal au taux d'échantillonnage du frontend. En comprenant la façon dont les applications instrumentées interagissent, vous pouvez évaluer l'incidence du nombre de délais ingérés.

Exportation de journaux Logging

Si les coûts engendrés par les exportations Logging vous préoccupent, une solution consiste à mettre à jour votre récepteur de journaux afin d'utiliser un filtre de journalisation réduisant le volume de journaux exportés. Vous pouvez exclure de l'exportation les journaux dont vous n'avez pas besoin.

Remarque : Si vous excluez des journaux à la fois de l'API Logging et de l'exportation, vous n'avez pas accès à ces derniers.

Par exemple, si votre environnement inclut une application s'exécutant sur Compute Engine, et utilisant Cloud SQL, Cloud Storage et BigQuery, vous pouvez limiter les journaux générés de façon à n'inclure que les informations relatives à ces produits. Le filtre ci-dessous permet de n'exporter que les journaux relatifs à Cloud Audit Logging, Compute Engine, Cloud Storage, Cloud SQL et BigQuery. Vous pouvez l'appliquer à un récepteur de journaux et n'inclure que les journaux sélectionnés.

logName:"/logs/cloudaudit.googleapis.com" AND
(resource.type:gce OR
resource.type=gcs_bucket OR
resource.type=cloudsql_database OR
resource.type=bigquery_resource)

Conclusion

Google Cloud Observability permet d'afficher les données d'utilisation des produits et de les analyser en détail. Vous pouvez ainsi configurer les produits afin d'optimiser de manière appropriée l'utilisation et les coûts.

Étape suivante

• En savoir plus sur l'API Logging.
• En savoir plus sur l'API Monitoring.
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.