Échantillonnage des traces

L'échantillonnage de traces détermine les requêtes et les délais que Cloud Trace ingère, ce qui vous permet de contrôler les coûts de stockage et de respecter les quotas tout en capturant suffisamment de données pour résoudre les problèmes de performances des applications. Lorsque chaque segment d'une requête de bout en bout est enregistré, la trace est complète. Toutefois, pour gérer des volumes de requêtes élevés, les composants d'un système de traçage distribué n'échantillonnent généralement qu'un sous-ensemble de traces ou suivent les décisions d'échantillonnage des délais parents.

L'échantillonnage est différent de la propagation du contexte. L'échantillonnage contrôle si un composant enregistre des données de segment. En revanche, la propagation du contexte transmet les identifiants de trace entre les composants afin que les délais échantillonnés puissent être liés.

Stratégies d'échantillonnage

Les décisions d'échantillonnage peuvent être basées sur l'en-tête ou sur la fin. Dans l'échantillonnage basé sur l'en-tête, la décision d'échantillonnage est prise lorsque la requête est reçue par le composant qui traite le segment. Dans l'échantillonnage basé sur la fin, la décision d'échantillonnage est différée jusqu'à ce que la trace complète soit disponible.

Vous pouvez rencontrer l'expression "échantillonnage à 100 %" dans la documentation des systèmes de traçage distribué. Cette expression peut s'appliquer à une trace ou à un composant. Lorsqu'elle s'applique à une trace, cela signifie que tous les délais ont été échantillonnés ou, de manière équivalente, que la trace est complète. Lorsqu'elle s'applique à un composant, cela signifie que le composant échantillonne chaque délai qu'il traite.

Échantillonnage basé sur l'en-tête

Les échantillonneurs basés sur l'en-tête sont généralement configurés pour toujours échantillonner les délais ou pour utiliser une stratégie d'échantillonnage probabiliste :

  • Avec les configurations toujours échantillonner, les composants qui traitent et écrivent des données de trace échantillonnent chaque délai. Idéalement, toutes les traces sont complètes et vous disposez donc des informations nécessaires pour résoudre les problèmes d'échec. Toutefois, une configuration "toujours échantillonner" peut vous amener à dépasser les quotas ou les limites de coûts de stockage.

  • Avec l'échantillonnage probabiliste, tous les délais ne sont pas échantillonnés. Le comportement réel de cette approche dépend de l'implémentation du composant. Dans certaines implémentations, tous les délais ont la même probabilité d'être échantillonnés. Dans d'autres cas, la décision d'échantillonnage du parent influence l'échantillonnage d'un segment.

Une trace peut ne pas contenir tous les segments. Si vous utilisez l'échantillonnage probabiliste , que vous dépassez le quota ou que vous utilisez des composants qui traitent des délais sans les échantillonner, des traces incomplètes sont attendues.

Échantillonnage basé sur la fin

Cloud Trace n'est pas compatible avec l'échantillonnage basé sur la fin. Les décisions d'échantillonnage doivent être prises dans les composants qui envoient des données à Cloud Trace.

Si vous utilisez l'échantillonnage basé sur la fin, vous pouvez également utiliser un serveur intermédiaire pour recevoir les données de trace, évaluer les décisions d'échantillonnage et relayer les délais échantillonnés vers Trace. Par exemple, vous pouvez utiliser un collecteur OpenTelemetry avec le processeur d'échantillonnage basé sur la fin pour prendre une décision d'échantillonnage différée.

Si vous prévoyez d'utiliser l'échantillonnage basé sur la fin, tenez compte des points suivants :

  • Vous devez stocker tous les délais dans une trace avant de prendre une décision d'échantillonnage. Par conséquent, vous aurez peut-être besoin d'une grande quantité de stockage temporaire ou d'autres frais généraux.
  • En général, tous les composants qui peuvent générer des délais pour une trace doivent se coordonner. En règle générale, les développeurs qui utilisent OpenTelemetry acheminent tous les délais pour le même ID de trace vers le même collecteur.

Les composants prennent des décisions d'échantillonnage

Chaque composant prend sa propre décision quant à l'échantillonnage du segment qu'il traite. Toutefois, la décision d'échantillonnage du parent, qui peut être disponible pour le composant via le contexte de trace, peut influencer la décision du composant. Les applications qui utilisent l'en-tête traceparent peuvent transmettre la décision d'échantillonnage du parent à l'aide de l'indicateur sampled.

Par exemple, supposons que chaque composant dispose d'une règle qui indique que "si le segment parent est échantillonné, échantillonnez le segment actuel ; sinon, échantillonnez 50% des segments". Dans ce scénario, les points suivants sont vrais :

  • Le segment racine détermine si tous les segments de la trace sont échantillonnés.
  • Lorsque le délai racine est échantillonné, tous les délais de la trace le sont également. Par conséquent, la trace est complète.

Échantillonnage et Google Cloud services

Chaque Google Cloud service prend ses propres décisions d'échantillonnage, et tous les Google Cloud services n'échantillonnent pas. Autrement dit, un service peut ne jamais envoyer de données à Cloud Trace.

Lorsque l'échantillonnage est compatible avec un Google Cloud service, ce service implémente généralement les éléments suivants :

  • Un taux d'échantillonnage par défaut.
  • Un mécanisme permettant d'utiliser la décision d'échantillonnage du parent comme indication pour savoir s'il faut échantillonner le délai.
  • Un taux d'échantillonnage maximal.

Pour demander à un Google Cloud service d'ajouter la compatibilité avec l'échantillonnage, utilisez l'outil Issue Tracker de Google.

Étape suivante