Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Cas d'utilisation courants des processeurs
<a name="processor-examples"></a>

Voici des scénarios courants et des exemples de configurations pour combiner des processeurs.

**Exemples de pipeline de logs**

**Example Standardisez les formats de journal et ajoutez des métadonnées**  
Analysez les journaux JSON, normalisez les noms de champs et ajoutez des informations sur l'environnement :  

```
processor:
  - parse_json: {}
  - rename_keys:
      entries:
        - from_key: "timestamp"
          to_key: "@timestamp"
        - from_key: "log_level"
          to_key: "level"
  - add_entries:
      entries:
        - key: "environment"
          value: "production"
        - key: "application"
          value: "payment-service"
```

**Example Nettoyer et normaliser les valeurs des champs**  
Standardisez les codes d'état et supprimez les données sensibles :  

```
processor:
  - uppercase_string:
      with_keys: ["status", "method"]
  - delete_entries:
      with_keys: ["credit_card", "password"]
  - substitute_string:
      entries:
        - source: "status"
          from: "SUCCESS"
          to: "OK"
```

**Example Extraire et transformer des champs spécifiques**  
Extrayez les informations utilisateur et le format à des fins d'analyse :  

```
processor:
  - extract_value:
      entries:
        - source: "user_agent"
          target: "browser"
          from: "(?<browser>Chrome|Firefox|Safari)"
          to: "${browser}"
  - lowercase_string:
      with_keys: ["browser"]
  - move_keys:
      entries:
        - from_key: "browser"
          to_key: "user_data.browser"
```

**Example Traitement conditionnel avec conditions d'entrée de gamme**  
Ajoutez différentes métadonnées en fonction de la gravité du journal à l'aide de conditions d'entrée de gamme `when` :  

```
processor:
  - add_entries:
      entries:
        - key: "alert_level"
          value: "critical"
          when: "log.level == 'ERROR'"
        - key: "alert_level"
          value: "info"
          when_else: "log.level == 'ERROR'"
```

**Example Supprimer les entrées de journal indésirables**  
Filtrez les entrées du journal de débogage et de suivi provenant d'une source tierce afin de réduire le bruit et les coûts de stockage :  

```
processor:
  - drop_events:
      when: "log.level in {'DEBUG', 'TRACE'}"
      handle_expression_failure: "skip"
```

**Example Processor-level conditionnel avec delete\_entries**  
Supprimez les champs sensibles uniquement lorsque l'environnement est celui de la production :  

```
processor:
  - delete_entries:
      with_keys: ["password", "api_key", "ssn"]
      when: "environment in {'prod', 'staging'}"
```

## Exemples de pipeline de métriques
<a name="metrics-processor-examples"></a>

Les exemples suivants montrent les configurations de processeur pour les pipelines de métriques. Les processeurs de métriques utilisent des expressions de chemin OTTL pour cibler les attributs dans différentes étendues.

**Example Ajouter le contexte commercial aux indicateurs**  
Ajoutez des balises d'environnement et de propriété de l'équipe aux points de données métriques :  

```
processor:
  - add_attributes:
      attributes:
        - key: resource.attributes["team"]
          value: "platform-engineering"
        - key: resource.attributes["cost_center"]
          value: "CC-1234"
```

**Example Supprimer les attributs à cardinalité élevée**  
Supprimez les attributs qui font grimper les coûts de stockage. Ne s'applique pas aux métriques cumulées ou aux métriques distribuées. Si l'une des métriques des critères de sélection présente une temporalité non prise en charge, le pipeline émet une métrique d'`UnsupportedTemporality`avertissement que vous pouvez surveiller dans l'espace de noms : `AWS/Observability Admin`  

```
processor:
  - delete_attributes:
      with_keys:
        - resource.attributes["host.id"]
        - datapoint.attributes["http.request.id"]
```

**Example Standardisez les conventions de dénomination**  
Renommez les métriques et les attributs pour les aligner sur les conventions OpenTelemetry sémantiques. Ne s'applique pas aux mesures cumulatives ou aux mesures vendues :  

```
processor:
  - rename_metrics:
      metrics:
        - from: "cpu_usage_percent"
          to: "system.cpu.utilization"
  - rename_attributes:
      attributes:
        - from_key: resource.attributes["hostname"]
          to_key: resource.attributes["host.name"]
```