Skip to main content
L’échantillonnage à l’ingestion vous permet de contrôler la proportion de traces qui parviennent à une instance Weave autogérée et d’écarter les autres. Pour les clusters à fort volume, ne conserver qu’un pourcentage défini de traces peut contribuer à réduire les coûts de stockage et de traitement. Ce guide 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 aucune version particulière du SDK. 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 défini côté serveur s’applique à l’ensemble du déploiement sans pouvoir être modifié ni ignoré par les différents clients. Pour plus d’informations, voir Contrôler le taux d’échantillonnage.

​
Pourquoi utiliser l’échantillonnage à l’ingestion

Par défaut, Weave conserve toutes les traces envoyées par vos applications. À des volumes élevés, conserver des enregistrements complets peut toutefois devenir coûteux. Comme l’échantillonnage à l’ingestion supprime une trace côté serveur avant qu’elle ne soit stockée ou évaluée, vos coûts sont à peu près proportionnels à la part du trafic que vous conservez. Pour définir le taux d’échantillonnage à l’ingestion, indiquez un nombre compris 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 les autres.
  • 0.0 supprime toutes les traces, à l’exception des évaluations.

​
Portée de l’échantillonnage à l’ingestion

L’échantillonnage à l’ingestion s’applique à deux types de trafic, et le taux que vous définissez vaut pour les deux :
  • Les appels issus du décorateur @weave.op, qui apparaissent dans l’onglet Traces.
  • Les spans d’agent envoyés au point de terminaison de traçage des agents (/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 issues du SDK Weave. Weave les conserve, car il s’agit de mesures de qualité intentionnelles, dont les scores seraient faussés s’ils étaient calculés sur des données partielles.
  • Les traces envoyées au point de terminaison OTel brut (/otel/v1/traces) à l’aide de vos propres outils OpenTelemetry. Le trafic OpenTelemetry brut ne comporte aucun marqueur d’évaluation : l’échantillonner risquerait donc de supprimer des évaluations à votre insu. Pour plus d’informations, voir Envoyer des traces OpenTelemetry vers Weave.
  • Les appels issus de versions du SDK Weave antérieures aux versions prises en charge. Voir Exigences et limites.

​
Fonctionnement

Le serveur s’appuie sur l’ID de la trace et sur un échantillonnage déterministe par hachage pour déterminer quelles traces supprimer et lesquelles conserver. Si une trace contient plusieurs appels partageant le même trace_id, la décision du serveur de conserver ou de supprimer la trace s’applique à tous les appels ou spans imbriqués qui partagent cet ID de trace. Une trace est soit conservée, soit supprimée dans son intégralité, jamais stockée partiellement.
La décision n’est stable que tant que le taux reste inchangé. Une trace en cours au moment où le taux est modifié peut se retrouver scindée de part et d’autre de la modification. 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 serveur de traces, par exemple dans vos valeurs Helm : Définissez WEAVE_INGEST_SAMPLE_RATE sur la proportion de traces que vous souhaitez conserver, par exemple 0.1.

​
Facultatif : prévisualiser avec une simulation à blanc

Une simulation à blanc vous permet de prévisualiser l’effet d’un taux d’échantillonnage avant de supprimer quoi que ce soit. Sa seule sortie est constituée des 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 ; vous pouvez alors l’ignorer et définir directement le taux. Si vous collectez ces métriques, lancez l’exécution avec WEAVE_INGEST_SAMPLE_RATE=0.1 et WEAVE_INGEST_SAMPLE_DRY_RUN=true sur une période représentative des pics de trafic, par exemple une journée complète, afin de voir quelle part du trafic le serveur supprimerait et quelle part 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 disposent de compteurs distincts : les deux ensembles ne comptent pas les mêmes éléments 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’appels et les compteurs d’agent comptent les spans, et non des traces entières : les ratios au sein d’un ensemble reflètent donc le volume de messages plutôt que le nombre de traces. Les compteurs suivants concernent les appels : Les compteurs suivants concernent les spans d’agent :

​
Exigences et limites

Avant d’activer l’échantillonnage à l’ingestion, prenez connaissance des exigences, limites et comportements suivants :
  • Exigences de version du SDK : le serveur n’échantillonne que les appels provenant du SDK Python Weave 0.53.0 ou version ultérieure, ou du SDK TypeScript Weave 0.16.0 ou version ultérieure. Ces versions ajoutent les signaux dont le serveur a besoin pour regrouper les messages d’une trace et identifier les appels d’évaluation. Les appels provenant de SDK plus anciens ne sont ni échantillonnés ni rejetés : tant que vos applications ne sont pas mises à niveau, le taux reste sans effet sur leur trafic. Les spans d’agent transportent un identifiant de trace, conformément au protocole OpenTelemetry ; leur échantillonnage n’impose donc aucune version minimale du 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 entraîne l’échantillonnage de votre trafic d’agent au même taux.
  • Les économies dépendent de la répartition de vos clients : le trafic non échantillonné, comme celui des SDK plus anciens 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 inférieures à ce que le taux laisse supposer. Le mieux est d’effectuer d’abord une simulation à blanc pour mesurer cet effet.
  • Monitors et évaluation : une trace supprimé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 de suppression envoyé au client : une trace supprimée reçoit une réponse de succès normale. Le client n’est pas informé de la suppression de sa trace.
Dernière modification le 30 septembre 2026