> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wandb.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Configurer l'échantillonnage à l'ingestion pour Weave Autogéré
> Conservez seulement une partie des traces entrantes pour maîtriser les coûts de stockage et de scoring LLM sur une instance Weave autogérée
L'échantillonnage à l'ingestion vous permet de contrôler la proportion des traces qui arrivent sur une [instance Weave autogérée](/fr/weave/guides/platform/weave-self-managed) 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](#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 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](/fr/weave/guides/tracking/ops#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](/fr/weave/guides/tracking/trace-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](/fr/weave/guides/tracking/otel).
* Les appels provenant de versions du SDK Weave antérieures aux versions prises en charge. Voir [Exigences et limites](#requirements-and-limitations).
## Fonctionnement
Le serveur utilise l'ID de la trace et l'[échantillonnage déterministe basé sur le hachage](https://opentelemetry.io/docs/concepts/sampling/) 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 :
| Variable | Type | Par défaut | Signification |
| ----------------------------- | ----- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| `WEAVE_INGEST_SAMPLE_RATE` | float | `1.0` | La proportion de traces à conserver. Une valeur non valide ou hors plage revient à `1.0`. |
| `WEAVE_INGEST_SAMPLE_DRY_RUN` | bool | `false` | Lorsque `true`, le serveur décide de conserver ou de supprimer chaque trace et comptabilise celles qu’il supprimerait, sans rien supprimer. |
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 :
| Métrique | Ce qu'elle compte |
| ------------------------------------- | ------------------------------------------------------------------ |
| `ingest_sampling.seen.otel` | Enregistrements d'appel é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 ID de trace exploitable. |
Les compteurs suivants couvrent 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 ID de trace exploitable. |
## 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.