Présentation du traçage distribué

Le traçage distribué pour les équilibreurs de charge d'application offre une visibilité de bout en bout sur les requêtes lorsqu'elles transitent de vos clients vers vos services de backend, en passant par l'équilibreur de charge.

Cloud Load Balancing s'intègre à Cloud Trace pour générer des segments de trace pour les requêtes traitées par l'équilibreur de charge. Étant donné que l'équilibreur de charge est le point d'entrée du trafic de votre application, le démarrage et la propagation du contexte de trace au niveau de l'équilibreur de charge garantissent une visibilité de diagnostic sur l'ensemble du chemin de la requête. Vous pouvez utiliser ces traces pour identifier les goulots d'étranglement de latence, isoler les sauts défaillants et résoudre les erreurs dans les architectures multiniveaux.

L'équilibreur de charge génère des traces conformes aux normes ouvertes (contexte de trace W3C et OpenTelemetry). Les services de backend instrumentés avec OpenTelemetry peuvent poursuivre la trace lancée par l'équilibreur de charge.

Principaux avantages

Le traçage distribué avec Cloud Trace offre les avantages suivants :

  • Visibilité des requêtes de bout en bout : suivez le chemin d'une requête à travers les équilibreurs de charge d'application externes et internes, ainsi que les services de backend vers lesquels ils acheminent le trafic.
  • Observabilité de périphérie : capturez les segments de trace au niveau de la règle de transfert, avant que l'équilibreur de charge ne sélectionne un backend, afin de pouvoir voir les erreurs de périphérie et la latence que l'instrumentation du backend ne peut pas détecter.
  • Configuration de télémétrie dissociée : définissez les paramètres de traçage dans des ressources TelemetryPolicy autonomes sans modifier la configuration de routage de votre équilibreur de charge.
  • Corrélation entre les données de télémétrie : mettez en corrélation les délais de trace avec les journaux de requêtes Cloud Load Balancing et les métriques Cloud Monitoring pour identifier l'origine de la latence ou des erreurs.

Équilibreurs de charge compatibles

Le tableau suivant liste les équilibreurs de charge compatibles avec le traçage distribué et les modes d'échantillonnage compatibles avec chaque équilibreur de charge :

Équilibreur de charge Schéma d'équilibrage de charge Échantillonnage probabiliste Échantillonnage basé sur les parents
Équilibreur de charge d'application externe global EXTERNAL_MANAGED
Équilibreur de charge d'application externe régional EXTERNAL_MANAGED
Équilibreur de charge d'application interne régional INTERNAL_MANAGED
Équilibreur de charge d'application interne interrégional INTERNAL_MANAGED

Les équilibreurs de charge d'application classiques ne sont pas compatibles avec le traçage distribué.

Fonctionnement du traçage distribué

Pour configurer le traçage distribué, créez une ressource TelemetryPolicy dans l'API Network Services. Une stratégie de télémétrie spécifie les éléments suivants :

  • Cibles : règles de transfert des équilibreurs de charge que vous souhaitez tracer.
  • Configuration du traçage : paramètres d'échantillonnage qui déterminent les requêtes que l'équilibreur de charge trace.

Lorsqu'une requête arrive au niveau d'une règle de transfert ciblée par une stratégie de télémétrie, l'équilibreur de charge décide d'échantillonner ou non la requête. Si la requête est échantillonnée, l'équilibreur de charge génère un segment de trace, l'envoie à Cloud Trace et propage le contexte de trace au backend dans l'en-tête de requête W3C traceparent.

Association de règle de transfert

Les stratégies de télémétrie ciblent la règle de transfert de l'équilibreur de charge, qui représente l'interface de l'équilibreur de charge. En associant le traçage à la règle de transfert, l'équilibreur de charge peut tracer tout le trafic qui entre dans une adresse IP virtuelle (VIP) et un port, y compris les requêtes qui échouent avant que l'équilibreur de charge ne sélectionne un backend.

Les stratégies de télémétrie présentent les caractéristiques suivantes :

  • Cycle de vie indépendant : les stratégies de télémétrie sont distinctes des services de backend, des mappages d'URL et des proxys cibles. Vous pouvez créer, modifier ou supprimer une stratégie de télémétrie sans modifier la façon dont l'équilibreur de charge achemine le trafic.
  • Réutilisable sur plusieurs interfaces : une seule stratégie de télémétrie peut cibler plusieurs règles de transfert, ce qui vous permet d'appliquer des paramètres de traçage cohérents sur plusieurs interfaces d'équilibreur de charge.
  • Champ d'application limité à un emplacement : créez une stratégie de télémétrie dans l'emplacement global pour cibler les règles de transfert globales, telles que celles utilisées par les équilibreurs de charge d'application externes globaux et les équilibreurs de charge d'application internes interrégionaux. Créez une stratégie de télémétrie dans une région pour cibler les règles de transfert régionales de cette région, telles que celles utilisées par les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes régionaux.

Modes d'échantillonnage

Le traçage distribué est compatible avec les modes d'échantillonnage suivants. Pour en savoir plus sur les modes d'échantillonnage compatibles avec chaque équilibreur de charge, consultez la section Équilibreurs de charge compatibles de ce document.

  • Échantillonnage probabiliste : l'équilibreur de charge échantillonne une proportion fixe de requêtes, que vous définissez dans le champ samplingRate. Par exemple, une valeur de 0.01 échantillonne 1 % des requêtes. L'échantillonnage probabiliste est compatible avec tous les équilibreurs de charge compatibles.

  • Échantillonnage basé sur le parent : l'équilibreur de charge respecte la décision d'échantillonnage dans l'en-tête traceparent entrant d'un client ou d'un service en amont. Vous configurez l'échantillonnage basé sur le parent dans le champ parentBasedSampling. L'échantillonnage basé sur le parent n'est compatible qu'avec les équilibreurs de charge d'application internes.

    Lorsque vous activez l'échantillonnage basé sur le parent, l'équilibreur de charge gère les requêtes comme suit :

    • Si l'en-tête traceparent entrant comporte l'option d'échantillonnage, l'équilibreur de charge échantillonne la requête au taux spécifié dans le champ parentBasedSampling.samplingRate. Par exemple, définissez ce champ sur 1.0 pour tracer toutes les requêtes qu'un service en amont a déjà échantillonnées.
    • Si l'en-tête traceparent entrant ne comporte pas l'indicateur d'échantillonnage, l'équilibreur de charge n'échantillonne pas la requête. Ce comportement respecte la décision en amont et suit la spécification OpenTelemetry, qui empêche les traces déconnectées d'apparaître dans Cloud Trace.
    • Si la requête n'inclut pas d'en-tête traceparent, l'équilibreur de charge applique la valeur de référence samplingRate.

Gestion des en-têtes de contexte de trace

L'équilibreur de charge gère l'en-tête W3C traceparent comme suit :

  • Le traçage n'est pas activé ou la requête n'est pas échantillonnée : l'équilibreur de charge transfère l'en-tête traceparent entrant au backend sans modification.
  • La requête est échantillonnée et n'inclut pas d'en-tête traceparent : l'équilibreur de charge génère un nouvel ID de trace et un nouvel ID de segment, et définit les indicateurs de trace sur 03 (aléatoire et échantillonné).
  • La requête est échantillonnée et inclut un en-tête traceparent : l'équilibreur de charge conserve l'ID de trace entrant et l'indicateur aléatoire, génère un nouvel ID de segment et définit l'indicateur d'échantillonnage.

Les services de backend qui utilisent un SDK OpenTelemetry avec l'outil de propagation de contexte de trace W3C lisent automatiquement l'en-tête traceparent et poursuivent la trace. Pour en savoir plus, consultez Contexte de trace.

Cas d'utilisation courants

Cette section décrit des scénarios courants de traçage distribué.

Surveiller la périphérie de la vitrine

Une plate-forme d'e-commerce utilise un équilibreur de charge d'application externe global pour recevoir le trafic des clients. Pour surveiller la latence périphérique et les erreurs telles que les réponses 404 et les échecs TLS, vous associez une stratégie de télémétrie avec échantillonnage probabiliste à la règle de transfert de la vitrine. Un faible taux d'échantillonnage, tel que 0.01 (1 %), permet de maintenir les coûts d'ingestion de Cloud Trace à un niveau prévisible lors des pics de trafic.

Maintenir la continuité des traces entre les services de paiement

Les demandes de paiement sont transmises de la vitrine à un équilibreur de charge d'application interne, puis aux services internes de panier, d'inventaire et de paiement. Pour vous assurer que les requêtes de paiement échantillonnées au niveau de la vitrine sont tracées à chaque saut interne, vous activez l'échantillonnage basé sur le parent sur l'équilibreur de charge interne avec un parentBasedSampling.samplingRate de 1.0. Le trafic interne de routine qui ne comporte pas de décision d'échantillonnage en amont est échantillonné au niveau de référence samplingRate.

Isoler les goulots d'étranglement de latence

Lorsque la latence de paiement augmente ou que les erreurs 5xx augmentent, vous comparez les segments de l'équilibreur de charge dans Cloud Trace avec les journaux de requêtes de l'équilibreur de charge et les métriques de latence. Cette comparaison vous permet de déterminer si le problème provient de la périphérie de l'équilibreur de charge, d'un saut d'équilibreur de charge interne ou d'un service de backend.

Tarifs

L'équilibreur de charge ne facture pas la génération de segments de trace. Toutefois, Cloud Trace facture l'ingestion des segments de trace conformément aux tarifs de Cloud Trace.

Pour gérer les coûts d'ingestion des charges de travail de production à fort trafic, nous vous recommandons de définir un samplingRate de 0.01 (1 %) ou 0.001 (0,1 %).

Limites

Pendant la phase de preview, le traçage distribué pour les équilibreurs de charge d'application présente les limites suivantes :

  • L'échantillonnage basé sur le parent n'est pas compatible avec les équilibreurs de charge d'application externes.
  • Les attributs de segment personnalisés ne sont pas acceptés.
  • Vous ne pouvez pas configurer le traçage distribué à l'aide de l'API Gateway de Google Kubernetes Engine ni de Terraform.
  • Une même stratégie de télémétrie peut cibler jusqu'à 50 ressources.

Traçage distribué pour Agent Gateway

Si vous utilisez Agent Gateway pour gérer le trafic des agents IA, consultez Surveiller le trafic via Agent Gateway pour en savoir plus sur la surveillance du trafic des agents.

Étapes suivantes