Transformation

2. Transformation et Échantillonnage #

Adaptation des spans et échantillonnage (sampling).

Nettoyer les attributs #

Une trace peut contenir des données sensibles. otelcol.processor.attributes les retire ou les masque avant qu'elles ne quittent votre réseau.

otelcol.processor.attributes "nettoyage" {
  action {
    key    = "http.request.header.authorization"
    action = "delete"
  }
  action {
    key    = "user.email"
    action = "hash"
  }
  action {
    key    = "deployment.environment.name"
    value  = "prod"
    action = "upsert"
  }
  output {
    traces = []
  }
}

Le hachage garde une valeur stable : vous pouvez toujours compter les utilisateurs touchés, sans connaître leur adresse.

Normaliser avec OTTL #

otelcol.processor.transform exécute des instructions en OTTL. Ici, on regroupe GET /produits/42, GET /produits/43… sous un seul nom : sans cela, chaque identifiant crée une opération distincte, et les tableaux de bord deviennent illisibles.

otelcol.processor.transform "noms" {
  error_mode = "ignore"
  trace_statements {
    context    = "span"
    statements = [
      `set(attributes["http.route"], "/produits/{id}") where IsMatch(name, "^GET /produits/[0-9]+$")`,
      `set(name, "GET /produits/{id}") where IsMatch(name, "^GET /produits/[0-9]+$")`,
    ]
  }
  output {
    traces = []
  }
}

Résultat constaté : le span s'appelle GET /produits/{id} et porte http.route=/produits/{id}. L'ordre compte : on écrit l'attribut avant de renommer, sinon la condition ne correspond plus.

Échantillonner intelligemment #

Garder toutes les traces coûte cher. Il existe deux approches :

otelcol.processor.tail_sampling "decision" {
  decision_wait = "30s"
  num_traces    = 50000

  policy {
    name = "garder-les-erreurs"
    type = "status_code"
    status_code {
      status_codes = ["ERROR"]
    }
  }

  policy {
    name = "garder-les-lentes"
    type = "latency"
    latency {
      threshold_ms = 1000
    }
  }

  policy {
    name = "echantillon-du-reste"
    type = "probabilistic"
    probabilistic {
      sampling_percentage = 5
    }
  }

  output {
    traces = []
  }
}

Une trace est gardée dès qu'une politique l'accepte. Nous avons testé erreurs et lenteur (avec decision_wait réduit à 5 s) sur 3 traces :

otelcol_receiver_accepted_spans_total valait 3, et otelcol_exporter_sent_spans_total 2.

En cas de plusieurs instances : tous les spans d'une trace doivent arriver sur la même instance. Devant plusieurs Alloy, ajoutez otelcol.exporter.loadbalancing avec routing_key = "traceID". decision_wait (30 s par défaut) et num_traces (50000) déterminent la mémoire nécessaire.

Produire des métriques à partir des traces #

Pour ne pas perdre les taux réels malgré l'échantillonnage, générez les métriques avant celui-ci : forward les traces reçues à la fois vers ce connecteur et vers le pipeline.

otelcol.connector.spanmetrics "red" {
  histogram {
    explicit {
      buckets = ["100ms", "500ms", "2s"]
    }
  }
  output {
    metrics = [otelcol.exporter.prometheus.vers_prom.input]
  }
}

otelcol.exporter.prometheus "vers_prom" {
  forward_to = [prometheus.remote_write.mimir.receiver]
}

prometheus.remote_write "mimir" {
  endpoint {
    url = "http://mimir:9009/api/v1/push"
  }
}