> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Configurer l’échantillonnage à l’ingestion pour Weave autogéré
> Ne conserver qu’une partie des traces entrantes pour maîtriser les coûts de stockage et d’évaluation par LLM sur une instance Weave autogérée
L’échantillonnage à l’ingestion vous permet de contrôler la proportion de traces qui parviennent à une [instance Weave autogérée](/fr/products/wandb/weave/guides/platform/weave-self-managed) 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](#requirements-and-limitations).
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](/fr/products/wandb/weave/guides/tracking/ops#control-sampling-rate).
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](/fr/products/wandb/weave/guides/tracking/trace-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](/fr/products/wandb/weave/guides/tracking/otel).
* Les appels issus de versions du SDK Weave antérieures aux versions prises en charge. Voir [Exigences et limites](#requirements-and-limitations).
Fonctionnement
Le serveur s’appuie sur l’ID de la trace et sur un [échantillonnage déterministe par hachage](https://opentelemetry.io/docs/concepts/sampling/) 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.
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 :
| Variable | Type | Par défaut | Signification |
| - | - | - | - |
| `WEAVE_INGEST_SAMPLE_RATE` | float | `1.0` | La proportion de traces à conserver. Toute valeur non valide ou hors limites est ramenée à `1.0`. |
| `WEAVE_INGEST_SAMPLE_DRY_RUN` | bool | `false` | Lorsque la valeur est `true`, le serveur décide de conserver ou de rejeter chaque trace et comptabilise ce qu’il rejetterait, sans toutefois rien rejeter. |
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 :
| Métrique | Ce qu’elle compte |
| - | - |
| `ingest_sampling.seen.otel` | Enregistrements d’appels évalués par l’échantillonneur. |
| `ingest_sampling.evals_kept.otel` | Appels d’évaluation conservés. |
| `ingest_sampling.dropped.otel` | Enregistrements supprimés. Porte un tag `dry_run`. |
| `ingest_sampling.dropped_bytes.otel` | Octets supprimés. Porte un tag `dry_run`. |
| `ingest_sampling.unsupported.otel` | Trafic provenant de clients trop anciens pour être échantillonnés. |
| `ingest_sampling.parse_failures.otel` | Messages reçus sans identifiant de trace exploitable. |
Les compteurs suivants concernent les spans d’agent :
| Métrique | Ce qu’elle compte |
| - | - |
| `weave_trace_server.ingest_sampling.spans.seen` | Spans évalués par l’échantillonneur. |
| `weave_trace_server.ingest_sampling.spans.evals_kept` | Spans d’évaluation conservés. |
| `weave_trace_server.ingest_sampling.spans.dropped` | Spans supprimés. Porte un tag `dry_run`. |
| `weave_trace_server.ingest_sampling.spans.dropped_bytes` | Octets supprimés. Porte un tag `dry_run`. |
| `weave_trace_server.ingest_sampling.spans.parse_failures` | Spans reçus sans identifiant de trace exploitable. |
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.