L'échantillonnage des traces détermine les requêtes et les spans ingérés par Cloud Trace. Il vous aide à contrôler les coûts de stockage et à respecter les quotas tout en capturant suffisamment de données pour résoudre les problèmes de performances. 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 spans parents.
L'échantillonnage est différent de la propagation du contexte : l'échantillonnage contrôle si un composant enregistre des données de couverture, tandis que la propagation du contexte transmet les identifiants de trace entre les composants afin que les couvertures échantillonnées puissent être liées.
Stratégies d'échantillonnage
Les décisions d'échantillonnage peuvent être basées sur la tête ou la queue. 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 span. 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 est appliquée à une trace, cela signifie que toutes les portées ont été échantillonnées ou, de manière équivalente, que la trace est complète. Lorsqu'il est appliqué à un composant, cela signifie que le composant échantillonne chaque span 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 spans ou pour utiliser une stratégie d'échantillonnage probabiliste :
Avec les configurations always sample, les composants qui traitent et écrivent des données de trace échantillonnent chaque span. Dans l'idéal, toutes les traces sont complètes et vous disposez donc des informations nécessaires pour résoudre les problèmes. Toutefois, une configuration d'échantillonnage permanent peut vous faire dépasser les quotas ou les limites de coûts de stockage.
Avec l'échantillonnage probabiliste, toutes les portées ne sont pas échantillonnées. Le comportement réel de cette approche dépend de l'implémentation du composant. Dans certaines implémentations, toutes les portées ont la même probabilité d'être échantillonnées. Dans d'autres, la décision d'échantillonnage du parent influence l'échantillonnage d'une portée.
Il est possible qu'une trace ne contienne pas toutes les portées. Si vous utilisez un échantillonnage probabiliste, que vous dépassez le quota ou que vous utilisez des composants qui traitent les spans, mais ne les échantillonnent pas, des traces incomplètes sont attendues.
Échantillonnage basé sur la fin de la distribution
Cloud Trace n'est pas compatible avec l'échantillonnage basé sur la fin de la trace. 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 de la distribution, vous pouvez également utiliser un serveur intermédiaire pour recevoir les données de trace, évaluer les décisions d'échantillonnage et relayer les spans échantillonnés vers Trace. Par exemple, vous pouvez utiliser un collecteur OpenTelemetry avec le processeur d'échantillonnage de queue pour prendre une décision d'échantillonnage différée.
Si vous prévoyez d'utiliser l'échantillonnage de queue, tenez compte des points suivants :
- Vous devez stocker toutes les portées 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 surcoûts.
- En général, tous les composants pouvant générer des spans pour une trace doivent se coordonner. En règle générale, les développeurs qui utilisent OpenTelemetry acheminent toutes les portées pour le même ID de trace vers le même collecteur.
Les composants prennent des décisions d'échantillonnage
Chaque composant décide lui-même s'il doit échantillonner la portée 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 stipule "si le segment parent est échantillonné, échantillonnez le segment actuel ; sinon, échantillonnez 50% des segments". Dans ce scénario, les conditions suivantes sont remplies :
- Le segment racine détermine si tous les segments de la trace sont échantillonnés.
- Lorsque la portée racine est échantillonnée, toutes les portées de la trace le sont également. La trace est donc complète.
Échantillonnage et services Google Cloud
Chaque service Google Cloud prend ses propres décisions d'échantillonnage, et tous les services Google Cloud n'échantillonnent pas. Autrement dit, un service peut ne jamais envoyer de données à Cloud Trace.
Lorsqu'un service Google Cloud prend en charge l'échantillonnage, il implémente généralement les éléments suivants :
- Taux d'échantillonnage par défaut.
- Mécanisme permettant d'utiliser la décision d'échantillonnage du parent comme indication pour savoir s'il faut échantillonner la portée.
- Taux d'échantillonnage maximal.
Pour demander à un service Google Cloud d'ajouter la prise en charge de l'échantillonnage, utilisez l'outil Issue Tracker de Google.
Étapes suivantes
Pour savoir comment choisir une stratégie d'échantillonnage par nom de span, consultez Échantillonnage à distance Jaeger.
Nous vous recommandons de consulter la documentation Open Source suivante pour vous aider à déterminer l'approche d'échantillonnage la mieux adaptée à vos applications en cours de développement et déployées :
Documentation du serviceGoogle Cloud :