Processeur d'échantillonnage

Le processeur d'échantillonnage implémente un échantillonnage probabiliste pour réduire le volume de données tout en préservant le signal. Utilisez-le pour conserver toutes les erreurs et les requêtes lentes tout en échantillonnant de manière agressive les cas de succès courants, réduisant ainsi les coûts sans perdre de valeur diagnostique.

Quand utiliser le processeur d'échantillonnage

Le processeur d'échantillonnage prend en charge différentes capacités en fonction de votre type de données de télémétrie :

Pour les logs et les événements

Les Logs et Événements prennent en charge l'échantillonnage conditionnel avec des règles personnalisables basées sur la sévérité, les attributs et d'autres critères :

Conservez 100 % des erreurs tout en échantillonnant les cas de succès: préservez toutes les données de diagnostic, supprimez le trafic de routine
Échantillonnez plus agressivement les services à fort volume: différents taux d'échantillonnage selon le niveau de service ou l'importance
Conserver les requêtes lentes tout en échantillonnant les rapides: conservez les valeurs aberrantes de performance pour analyse
Appliquez des taux d'échantillonnage différents par environnement ou service: Production à 10 %, préproduction à 50 %, test à 100 %

Pour les traces

Les traces prennent en charge uniquement l'échantillonnage global basé sur un taux. Réduisez le volume global de traces avec un taux d'échantillonnage uniforme.

Pour les métriques

L'échantillonnage de métriques n'est actuellement pas pris en charge par le processeur d'échantillonnage. Utilisez plutôt le processeur de filtre pour supprimer les métriques indésirables.

Comment fonctionne l'échantillonnage

Le processeur d'échantillonnage utilise un échantillonnage probabiliste avec des règles conditionnelles :

Pourcentage d’échantillonnage par défaut: taux par défaut appliqué à toutes les données ne correspondant pas aux règles conditionnelles.
Règles: remplacez le taux par défaut lorsque des conditions spécifiques sont remplies.
Source d'aléatoire: un champ cohérent (comme trace_id) garantit que les données liées sont échantillonnées ensemble.

Ordre d’évaluation: les règles sont évaluées dans l’ordre défini. La première règle correspondante détermine le taux d'échantillonnage. Si aucune règle ne correspond, le pourcentage d'échantillonnage par défaut s'applique.

Configuration

Ajoutez un processeur d'échantillonnage à votre pipeline :

probabilistic_sampler/Logs:
        description: Probabilistic sampling for all logs
        config:
          default_sampling_percentage: 100
          rules:
            - name: sample the log records for ruby test service
              description: sample the log records for ruby test service with 70%
              sampling_percentage: 70
              source_of_randomness: trace.id
              conditions:
                - resource.attributes["service.name"] == "ruby-test-service"

Champs de configuration:

default_sampling_percentage: Taux d’échantillonnage par défaut (0-100) pour les données ne correspondant pas aux règles.
rules: Éventail de règles (évaluées dans l'ordre) - pris en charge uniquement pour les logs et les événements.
- name: Identifiant de règle.
- description: Description lisible par l'humain.
- sampling_percentage: Taux d’échantillonnage pour les données correspondantes (0-100).
- source_of_randomness: Champ à utiliser pour la décision d'échantillonnage (généralement trace_id).
- conditions: liste d'expressions OTTL pour correspondre à la télémétrie.

Stratégies d'échantillonnage

Conservez les données précieuses, rejetez le trafic de routine

Le modèle le plus courant pour les logs et événements: conserver toutes les données de diagnostic (erreurs, requêtes lentes), échantillonner agressivement les cas de réussite courants.

probabilistic_sampler/Logs:
  description: "Intelligent log sampling"
  config:
    default_sampling_percentage: 5  # Sample 5% of everything else
    rules:
      - name: "preserve-errors"
        description: "Keep all errors and fatals"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_text == "ERROR" or severity_text == "FATAL"'

      - name: "preserve-warnings"
        description: "Keep most warnings"
        sampling_percentage: 50
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_text == "WARN"'

Résultat: 100 % des erreurs + 50 % des avertissements + 5 % du reste

Échantillonner par niveau de service

Différents taux d'échantillonnage selon l'importance du service :

probabilistic_sampler/Logs:
  description: "Service tier sampling"
  config:
    default_sampling_percentage: 10
    rules:
      - name: "critical-services"
        description: "Keep most traces from critical services"
        sampling_percentage: 80
        source_of_randomness: "trace.id"
        conditions: 
          - 'resource.attributes["service.name"] == "checkout" or resource.attributes["service.name"] == "payment"'

      - name: "standard-services"
        description: "Medium sampling for standard services"
        sampling_percentage: 30
        source_of_randomness: "trace.id"
        conditions: 
          - 'resource.attributes["service.tier"] == "standard"'

Échantillon par environnement

Échantillonnage plus élevé dans les environnements de test, plus faible en production :

probabilistic_sampler/Logs:
  description: "Environment-based sampling"
  config:
    default_sampling_percentage: 10  # Production default
    rules:
      - name: "test-environment"
        description: "Keep all test data"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'resource.attributes["environment"] == "test"'

      - name: "staging-environment"
        description: "Keep half of staging data"
        sampling_percentage: 50
        source_of_randomness: "trace.id"
        conditions: 
          - 'resource.attributes["environment"] == "staging"'

Conserver les requêtes lentes

Conserver les valeurs aberrantes de performance pour analyse :

probabilistic_sampler/Logs:
  description: "Preserve important logs"
  config:
    default_sampling_percentage: 1  # Sample 1% of routine logs
    rules:
      - name: "critical-logs"
        description: "Keep all error and fatal logs"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_text == "ERROR" or severity_text == "FATAL"'

      - name: "warning-logs"
        description: "Keep half of warning logs"
        sampling_percentage: 50
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_text == "WARN"'
      
      - name: "traced-logs"
        description: "Keep logs with trace context"
        sampling_percentage: 50
        source_of_randomness: "trace.id"
        conditions: 
          - 'trace_id != nil and trace_id.string != "00000000000000000000000000000000"'

Remarque: La durée est exprimée en nanosecondes (1 seconde = 1 000 000 000 ns).

Exemples complets

Exemple 1 : Échantillonnage intelligent des traces pour le traçage distribué

Pour les traces, vous pouvez uniquement configurer le pourcentage d'échantillonnage par défaut. Ce pourcentage s'applique à toutes les traces uniformément, y compris les traces d'erreur et les traces lentes :

probabilistic_sampler/Traces:
  description: Probabilistic sampling for traces
  config:
    default_sampling_percentage: 55

Exemple 2 : Réduction du volume de logs

Réduisez considérablement le volume de logs tout en conservant les données de diagnostic :

probabilistic_sampler/Logs:
  description: "Aggressive log sampling, preserve errors"
  config:
    default_sampling_percentage: 2  # Keep 2% of routine logs
    rules:
      - name: "keep-errors-fatals"
        description: "Keep all errors and fatals"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_number >= 17'  # ERROR and above

      - name: "keep-some-warnings"
        description: "Keep 25% of warnings"
        sampling_percentage: 25
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_number >= 13 and severity_number < 17'  # WARN

Exemple 3 : Échantillonnage par code d'état HTTP

Échantillonner tous les échecs (100 %) et une fraction des succès (5 %) :

probabilistic_sampler/Logs:
  description: "Sample by HTTP response status"
  config:
    default_sampling_percentage: 5  # 5% of successes
    rules:
      - name: "keep-server-errors"
        description: "Keep all 5xx errors"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["http.status_code"] >= 500'

      - name: "keep-client-errors"
        description: "Keep all 4xx errors"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["http.status_code"] >= 400 and attributes["http.status_code"] < 500'

Exemple 4 : Échantillonnage de service multiniveau

Différents taux pour différents niveaux d'importance :

probabilistic_sampler/Logs:
  description: "Business criticality sampling"
  config:
    default_sampling_percentage: 1
    rules:
      # Critical business services: keep 80%
      - name: "critical-services"
        description: "High sampling for critical services"
        sampling_percentage: 80
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["business_criticality"] == "critical"'

      # Important services: keep 40%
      - name: "important-services"
        description: "Medium sampling for important services"
        sampling_percentage: 40
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["business_criticality"] == "important"'

      # Standard services: keep 10%
      - name: "standard-services"
        description: "Low sampling for standard services"
        sampling_percentage: 10
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["business_criticality"] == "standard"'

Exemple 5 : Échantillonnage temporel (réduction hors pointe)

Échantillonnage plus élevé pendant les heures de bureau (nécessite un étiquetage d'attributs externes) :

probabilistic_sampler/Logs:
  description: "Time-based sampling (requires time attribute)"
  config:
    default_sampling_percentage: 5  # Off-peak default
    rules:
      - name: "business-hours"
        description: "Higher sampling during business hours"
        sampling_percentage: 50
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["is_business_hours"] == true'

Exemple 6 : Échantillonner par motif de point de terminaison

Conserver tous les endpoints d'administration, échantillonner l'API publique de manière agressive :

probabilistic_sampler/Logs:
  description: "Endpoint-based sampling"
  config:
    default_sampling_percentage: 10
    rules:
      - name: "admin-endpoints"
        description: "Keep all admin traffic"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'IsMatch(attributes["http.path"], "^/admin/.*")'

      - name: "api-endpoints"
        description: "Sample public API"
        sampling_percentage: 5
        source_of_randomness: "trace.id"
        conditions: 
          - 'IsMatch(attributes["http.path"], "^/api/.*")'

Source d'aléatoire

Le champ source_of_randomness détermine quel attribut est utilisé pour prendre des décisions d'échantillonnage cohérentes.

Valeurs courantes:

trace_id: Pour les traces distribuées (garantit que tous les spans d'une trace sont échantillonnés ensemble)
span_id: Pour l'échantillonnage individuel de spans (non recommandé pour le traçage distribué)
Attribut personnalisé : tout attribut qui fournit de l'aléatoire

Pourquoi c'est important: L'utilisation de trace_id garantit que lorsque vous échantillonnez une trace, vous obtenez TOUS les spans de cette trace, et non pas seulement des spans individuels aléatoires. Ceci est essentiel pour comprendre les transactions distribuées.

Considérations relatives aux performances

Ordonnez les règles par fréquence: Placez les conditions les plus fréquemment remplies en premier pour réduire le temps d'évaluation
Performances de la source d'aléatoire: L'utilisation de trace_id est très efficace car il est déjà disponible
L'échantillonnage s'effectue après les autres processeurs: placez l'échantillonnage vers la fin de votre pipeline pour éviter de gaspiller du CPU sur des données qui seront rejetées

Ordonnancement efficace des pipelines:

steps:
      # ... receive steps...
      probabilistic_sampler/Logs:
        description: Probabilistic sampling for all logs
        output:
          - filter/Logs
        config:
          rules:
            - name: sample the log records for ruby test service
              description: sample the log records for ruby test service with 70%
              sampling_percentage: 70
              source_of_randomness: trace.id
              conditions:
                - resource.attributes["service.name"] == "ruby-test-service"
          default_sampling_percentage: 100
      probabilistic_sampler/Traces:
        description: Probabilistic sampling for traces
        output:
          - filter/Traces
        config:
          default_sampling_percentage: 100
      filter/Logs:
        description: Apply drop rules and data processing for logs
        output:
          - transform/Logs
        config:
          error_mode: ignore
          rules:
            - name: drop the log records
              description: drop all records which has severity text INFO
              conditions:
                - log.severity_text == "INFO"
              context: log
      # ... filter steps ...
      # ... transdormer steps ...

Exemples d'impact sur les coûts

Exemple : 1 To/jour → 100 Go/jour

Avant l'échantillonnage:

1 To de logs par jour
90 % sont des opérations de routine de niveau INFO
8 % sont WARN
2 % sont ERROR/FATAL

Avec l'échantillonnage intelligent:

probabilistic_sampler/Logs:
  description: "Sample logs by severity level"
  config:
    default_sampling_percentage: 2  # Sample 2% of INFO and below
    rules:
      - name: "errors"
        description: "Keep all error logs"
        sampling_percentage: 100  # Keep 100% of errors
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_number >= 17'
      
      - name: "warnings"
        description: "Keep quarter of warning logs"
        sampling_percentage: 25  # Keep 25% of warnings
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_number >= 13 and severity_number < 17'

Après l'échantillonnage:

INFO : 900 Go × 2 % = 18 Go
AVERTISSEMENT : 80 Go × 25 % = 20 Go
ERREUR/FATAL : 20 Go × 100 % = 20 Go
Total : -58 Go/jour (réduction de 94 %)
Toutes les erreurs conservées pour le dépannage

Ressources OpenTelemetry

Prochaines étapes

En savoir plus sur le processeur de transformation pour l'enrichissement des données avant l'échantillonnage
Consultez Filter processor pour supprimer les données indésirables
Consultez la référence de configuration YAML pour la syntaxe complète

Cette traduction automatique est fournie pour votre commodité.

Quand utiliser le processeur d'échantillonnage.css-21sua1{background:none;border:none;width:0;padding:0;}