Processeur de filtre

Le processeur de filtrage supprime les enregistrements de télémétrie ou des attributs spécifiques en fonction d'expressions booléennes OTTL (OpenTelemetry Transformation Language). Utilisez-le pour supprimer les données de test, les logs de débogage, les vérifications de l'état ou toute télémétrie de faible valeur avant qu'elle ne quitte votre réseau.

Quand utiliser le processeur de filtre

Utilisez le processeur de filtre lorsque vous devez :

Supprimer les PII ou les données d'environnement de test: Supprimez les données qui ne doivent pas quitter votre réseau
Supprimer les logs de niveau debug de la production: filtrer par sévérité pour réduire le bruit
Filtrer les requêtes de vérification de l'état: exclure le trafic de monitoring répétitif et de faible valeur
Supprimer les métriques avec des préfixes ou des motifs spécifiques: Supprimez les flux de métriques inutiles
Supprimez la télémétrie de faible valeur en fonction des attributs: filtrez par nom de service, environnement ou tags personnalisés

Fonctionnement du processeur de filtrage

Le processeur de filtre évalue les expressions booléennes OTTL pour chaque enregistrement de télémétrie. Lorsqu'une condition est évaluée à true, l'enregistrement est rejeté.

C'est l'inverse de nombreux langages de requête où WHERE status = 'ERROR' signifie « conserver les erreurs ». Dans le processeur de filtre, status == 'ERROR' signifie « abandonner les erreurs ».

Configuration

Ajoutez un processeur de filtre à votre pipeline :

filter/Logs:
        description: Apply drop rules and data processing for 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"

Champs de configuration:

rules: éventail de règles de filtrage évaluées dans l'ordre.
- name: Identifiant de règle.
- context: le type de données à évaluer. Valeurs prises en charge : log, span, span_event, metric, datapoint.
- conditions: Une liste d'expressions booléennes OTTL.

Conditions multiples: lorsque vous fournissez plusieurs expressions dans le tableau, elles sont évaluées avec une logique OU. Si l'une des conditions est vraie, l'enregistrement est rejeté.

Opérateurs booléens OTTL

Opérateurs de comparaison

== - Égal à
!= - Différent de
< - Inférieur à
<= - Inférieur ou égal à
> - Supérieur à
>= - Supérieur ou égal à

Opérateurs logiques

and - Les deux conditions doivent être vraies
or - L'une des conditions doit être vraie
not - Nie une condition

Correspondance de motifs

IsMatch - Correspondance de motifs Regex

rules:
  - name: match-health-logs
    conditions:
      - 'IsMatch(body, ".*health.*") or IsMatch(attributes["http.url"], ".*\\/api\\/v1\\/health.*")'

Exemples complets

Exemple 1 : Supprimer les données de l'environnement de test

Supprimer toute la télémétrie des environnements de test et de développement :

config:
  rules:
    - name: drop-test-environment
      description: Drop logs from test environment
      conditions: 
        - 'resource.attributes["environment"] == "test"'
      context: log
    - name: drop-dev-environment
      description: Drop logs from dev environment
      conditions: 
        - 'resource.attributes["environment"] == "dev"'
      context: log

Exemple 2 : Supprimer les logs de debug en production

Conservez uniquement les niveaux de log pertinents en production :

config:
  rules:
    - name: drop-debug-logs
      description: Drop all DEBUG severity logs
      conditions: 
        - 'severity_text == "DEBUG"'
      context: log
    - name: drop-low-severity-logs
      description: Drop INFO and below severity logs
      conditions: 
        - "severity_number < 9"
      context: log

Référence du numéro de sévérité:

TRACE = 1-4
DEBUG = 5-8
INFO = 9-12
WARN = 13-16
ERREUR = 17-20
FATAL = 21-24

Exemple 3 : Supprimer les spans de contrôle de santé

Supprimez le trafic de contrôle de santé qui n'apporte aucune valeur diagnostique :

config:
  rules:
    - name: drop-health-endpoint
      description: Drop spans from /health endpoint
      conditions: 
        - 'attributes["http.path"] == "/health"'
      context: span
    - name: drop-health-check-spans
      description: Drop spans named health_check
      conditions: 
        - 'name == "health_check"'
      context: span

Exemple 4 : Supprimer par nom de service

Filtrer des services spécifiques ou des modèles de service :

config:
  rules:
    - name: drop-legacy-api
      description: Drop logs from legacy API v1 service
      conditions: 
        - 'resource.attributes["service.name"] == "legacy-api-v1"'
      context: log
    - name: drop-canary-services
      description: Drop logs from canary deployment services
      conditions: 
        - 'IsMatch(resource.attributes["service.name"], ".*-canary")'
      context: log

Exemple 5 : Supprimer les métriques avec des préfixes spécifiques

Supprimer les flux de métriques inutiles :

config:
  rules:
    - name: drop-internal-metrics
      description: Drop metrics with internal prefix
      conditions: 
        - 'IsMatch(name, "^internal\\.")'
      context: metric
    - name: drop-debug-datapoints
      description: Drop datapoints marked as debug type
      conditions: 
        - 'attributes["metric.type"] == "debug"'
      context: datapoint

Exemple 6 : Conditions combinées avec AND

Supprimer uniquement lorsque plusieurs conditions sont vraies :

config:
  rules:
    - name: drop-debug-logs-from-test
      description: Drop DEBUG logs from background-worker service in test environment
      conditions:
        - 'severity_text == "DEBUG"'
        - 'resource.attributes["service.name"] == "background-worker"'
        - 'resource.attributes["environment"] == "test"'
      context: log

Exemple 7 : Conserver les erreurs, abandonner tout le reste

Inversez la logique pour ne conserver que les données utiles :

config:
  rules:
    - name: drop-non-error-logs
      description: Drop everything below ERROR severity level
      conditions: 
        - "severity_number < 17"
      context: log

Ou utilisez la logique NOT :

filter/Logs:
  description: "Drop non-errors"
  config:
    error_mode: ignore
    rules:
      - name: drop-non-error-logs
        description: Drop logs that are not ERROR or FATAL
        conditions:
          - 'not (severity_text == "ERROR" or severity_text == "FATAL")'
        context: log

Exemple 8 : Correspondance de motifs dans le corps du log

Supprimer les logs contenant des motifs spécifiques :

config:
  rules:
    - name: drop-health-check-logs
      description: Drop logs with health check in body
      conditions: 
        - 'IsMatch(body, ".*health check.*")'
      context: log

Exemple 9 : Supprimer les spans à volume élevé et de faible valeur

Supprimez les spans qui apparaissent fréquemment mais apportent peu de valeur :

config:
  rules:
    - name: drop-fast-cache-hits
      description: Drop cache hit operations faster than 1ms
      conditions:
        - 'attributes["db.operation"] == "get"'
        - 'end_time_unix_nano - start_time_unix_nano < 1000000'
        - 'attributes["cache.hit"] == true'
      context: span

Exemple 10 : Suppression basée sur le statut HTTP

Filtrer les requêtes réussies, conserver les erreurs :

config:
  rules:
    - name: drop-successful-requests
      description: Drop HTTP requests with status code less than 400
      conditions: 
        - 'attributes["http.status_code"] < 400'
      context: span

Exemple 11 : Conditions multiples avec OR

Supprimer si une condition correspond :

config:
    rules:
      - name: drop-test-health-debug
        description: Drop logs from test environment, health checks, or debug severity
        conditions:
          - 'resource.attributes["environment"] == "test"'
          - 'IsMatch(body, ".*health.*")'
          - 'severity_text == "DEBUG"'
        context: log

Suppression de données vs suppression d'attributs

Le processeur de filtre peut supprimer des enregistrements entiers (comme indiqué ci-dessus) ou supprimer des attributs spécifiques des enregistrements conservés.

Pour supprimer des attributs tout en conservant l'enregistrement, vous devez utiliser la fonction delete_key() du processeur de transformation, et non le processeur de filtre. Le processeur de filtre supprime uniquement des enregistrements entiers.

Mauvaise approche (cela ne fonctionnera pas) :

filter/Logs:
  config:
    rules:
      - name: wrong-attribute-drop
        description: Identify and drop logs containing specific sensitive attributes
        conditions:
          - 'delete attributes["sensitive_field"]'  # Filter conditions must be boolean, not actions
        context: log

Approche correcte (utilisez plutôt le processeur de transformation) :

transform/Logs:
  description: "Remove sensitive attribute"
  config:
    rules:
      - name: remove-sensitive-field
        description: "Redacts the 'sensitive_field' attribute from log records to ensure privacy compliance."
        statements:
          - 'delete_key(attributes, "sensitive_field")'
  output: 
    - nrexporter/newrelic

Considérations relatives aux performances

L'ordre est important: placez les processeurs de filtrage au début de votre pipeline pour supprimer les données indésirables avant les traitements coûteux
Combiner les conditions: Utilisez la logique and/or dans une seule expression plutôt que de chaîner plusieurs processeurs de filtrage
Performance des regex: IsMatch est plus coûteux que les vérifications d’égalité exacte. Utilisez == si possible.

Exemple d'ordonnancement efficace:

steps:
      # ... receive steps ...
      # ... probabilistic sampler steps ...
      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/Metrics:
        description: Apply drop rules and data processing for metrics
        output:
          - transform/Metrics
        config:
          error_mode: ignore
          rules:
            - name: drop-internal-metrics
              description: drop internal metric
              conditions:
                - IsMatch(name, "^internal\\.")
              context: metric
            - name: drop-debug-datapoints
              description: drop-debug-datapoints
              conditions:
                - attributes["metric.type"] == "debug"
              context: datapoint
      filter/Traces:
        description: Apply drop rules and data processing for traces
        output:
          - transform/Traces
        config:
          error_mode: ignore
          rules:
            - name: drop-health-endpoint
              description: drop-health-endpoint
              conditions:
                - attributes["http.path"] == "/health"
              context: span
            - name: drop-debug-events
              description: drop-debug-events
              conditions:
                - name == 'debug_event'
              context: span_event
        # ... transformer steps...

Référence des expressions booléennes OTTL

Pour la syntaxe OTTL complète et les opérateurs supplémentaires :

Prochaines étapes

En savoir plus sur le processeur de transformation pour modifier les données avant le filtrage.
Consultez Sampling processor pour la réduction probabiliste du volume
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 de filtre.css-21sua1{background:none;border:none;width:0;padding:0;}