Passer au contenu principal
L’échantillonnage à l’ingestion vous permet de contrôler la proportion des traces qui arrivent sur une instance Weave autogérée et d’éliminer les autres. Cela peut aider à réduire les coûts de stockage et de traitement sur les clusters à fort volume en ne conservant qu’un pourcentage défini de traces. Ce guide vous explique comment activer cette fonctionnalité sur votre instance Weave autogérée.
L’échantillonnage à l’ingestion nécessite une version du serveur Weave qui inclut l’échantillonneur. L’échantillonnage des appels @weave.op nécessite également le SDK Python Weave 0.53.0 ou version ultérieure, ou le SDK TypeScript Weave 0.16.0 ou version ultérieure. Les spans d’agent ne nécessitent aucun SDK particulier. Pour plus de détails, voir Exigences et limites.
L’échantillonnage à l’ingestion est indépendant de l’échantillonnage côté client. Le paramètre tracing_sample_rate du décorateur @weave.op permet toujours à une fonction tracée d’échantillonner ses propres appels, mais seul un taux côté serveur s’applique à l’ensemble du déploiement, et les clients individuels ne peuvent ni le modifier ni l’ignorer. Pour plus d’informations, voir Control sampling rate.

​
Pourquoi utiliser l’échantillonnage à l’ingestion

Par défaut, Weave conserve chaque trace envoyée par vos applications, et à volume élevé, conserver des enregistrements complets peut devenir coûteux. Comme l’échantillonnage à l’ingestion supprime une trace sur le serveur avant qu’elle ne soit stockée ou évaluée, vos coûts sont globalement proportionnels à la part de trafic que vous conservez. Vous définissez le taux d’échantillonnage à l’ingestion en définissant une valeur comprise entre 0 et 1 :
  • 1.0 conserve toutes les traces et désactive l’échantillonnage (par défaut).
  • 0.1 conserve 10 % des traces et supprime le reste.
  • 0.0 supprime toutes les traces, à l’exception des évaluations.

​
À quoi s’applique l’échantillonnage à l’ingestion

L’échantillonnage à l’ingestion s’applique à deux types de trafic, et le taux que vous définissez s’applique aux deux :
  • Les appels du décorateur @weave.op, qui apparaissent dans l’onglet Traces.
  • Les spans d’agent envoyés au point de terminaison d’agent tracing (/agents/otel/v1/traces), qui apparaissent dans l’onglet Agents. Pour plus d’informations, voir Tracer vos agents.
Le trafic suivant n’est jamais échantillonné et est toujours conservé dans son intégralité :
  • Les évaluations du SDK Weave. Weave les conserve, car il s’agit de mesures de qualité intentionnelles, et leurs scores seraient erronés s’ils étaient calculés sur des données partielles.
  • Les traces envoyées avec vos propres outils OpenTelemetry vers le point de terminaison OTel brut (/otel/v1/traces). Le trafic OpenTelemetry brut ne contient aucun marqueur d’évaluation ; son échantillonnage pourrait donc supprimer silencieusement des évaluations. Pour plus d’informations, voir Envoyer des traces OpenTelemetry vers Weave.
  • Les appels provenant de versions du SDK Weave antérieures aux versions prises en charge. Voir Exigences et limites.

​
Fonctionnement

Le serveur utilise l’ID de la trace et l’échantillonnage déterministe basé sur le hachage pour déterminer quelles traces rejeter et lesquelles conserver. Si une trace contient plusieurs appels avec le même trace_id, la décision du serveur de conserver ou de rejeter une trace s’applique également à tous les appels imbriqués ou spans qui partagent le même ID de trace. Une trace est soit conservée dans son intégralité, soit rejetée dans son intégralité ; elle n’est jamais stockée partiellement.
La décision n’est stable que tant que le taux reste fixe. Une trace en cours de traitement au moment où le taux change peut être scindée de part et d’autre de ce changement. Modifiez le taux d’échantillonnage pendant une période de faible trafic.

​
Configurer l’échantillonnage à l’ingestion

Pour configurer l’échantillonnage à l’ingestion, définissez les variables d’environnement suivantes sur le déploiement du trace server, par exemple via vos valeurs Helm : Définissez WEAVE_INGEST_SAMPLE_RATE sur la proportion de traces que vous souhaitez conserver, par exemple 0.1.

​
Facultatif : aperçu avec une simulation à blanc

Vous pouvez prévisualiser l’effet d’un taux d’échantillonnage avant de supprimer quoi que ce soit à l’aide d’une simulation à blanc. Son seul résultat correspond aux métriques d’échantillonnage du serveur, émises sous forme de compteurs vers un backend de métriques tel que Datadog. Si votre déploiement ne collecte pas ces métriques, une simulation à blanc n’a aucun effet visible, et vous pouvez l’ignorer et définir directement le taux. Si vous collectez ces métriques, exécutez avec WEAVE_INGEST_SAMPLE_RATE=0.1 et WEAVE_INGEST_SAMPLE_DRY_RUN=true pendant une période couvrant un trafic de pointe représentatif, par exemple une journée complète, afin de voir quelle quantité de trafic le serveur supprimerait et quelle quantité de trafic n’est pas éligible à l’échantillonnage. Définissez ensuite WEAVE_INGEST_SAMPLE_DRY_RUN=false pour commencer à supprimer des traces. Les appels et les spans d’agent publient des compteurs distincts, et ces deux ensembles comptent des éléments différents et ne doivent pas être combinés. Chaque compteur porte un tag route qui identifie le point de terminaison. Les compteurs d’appels comptent les enregistrements d’appel et les compteurs d’agent comptent les spans, et non des traces entières ; les proportions au sein d’un même ensemble reflètent donc le volume de messages plutôt que le nombre de traces. Les compteurs suivants couvrent les appels : Les compteurs suivants couvrent les spans d’agent :

​
Exigences et limites

Avant d’activer l’échantillonnage à l’ingestion, consultez les exigences, limites et comportements suivants :
  • Exigences de version du SDK : le serveur échantillonne les appels uniquement depuis le SDK Python Weave 0.53.0 ou version ultérieure, ou le SDK TypeScript Weave 0.16.0 ou version ultérieure. Ces versions ajoutent les signaux que le serveur utilise pour regrouper les messages d’une trace et reconnaître les appels d’évaluation. Les appels provenant d’anciens SDK ne sont ni échantillonnés ni rejetés ; tant que vos applications ne sont pas mises à niveau, le taux n’a donc aucun effet sur leur trafic. Les spans d’agent incluent un ID de trace dans le protocole OpenTelemetry ; leur échantillonnage n’impose donc aucune exigence de SDK.
  • Version du serveur : la prise en charge des spans d’agent a été ajoutée après celle des appels. Si vous avez déjà défini un taux inférieur à 1.0, la mise à niveau vers une version du serveur qui échantillonne les spans d’agent commencera à échantillonner votre trafic d’agent au même taux.
  • Les économies dépendent de votre mix de clients : le trafic qui n’est pas échantillonné, comme celui provenant d’anciens SDK et d’OpenTelemetry brut, ne réduit pas les coûts. Si une grande partie de votre trafic provient de ces sources, les économies seront plus faibles que ce que le taux laisse penser. Une simulation à blanc est le meilleur moyen de le mesurer au préalable.
  • Monitors et scoring : une trace écartée n’est ni stockée ni évaluée. Si vous comptez sur des monitors couvrant 100 % du trafic, tenez-en compte avant d’activer l’échantillonnage.
  • Aucun signal d’exclusion envoyé au client : une trace écartée reçoit une réponse de réussite normale. Le client n’est pas informé que sa trace a été écartée.