

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.

# Processeurs d'analyseur
<a name="parser-processors"></a>

Les processeurs d'analyse convertissent les données de journal brutes ou semi-structurées en formats structurés. Chaque pipeline peut avoir au plus un processeur d'analyseur principal, qui doit être le premier processeur du pipeline. L'analyseur XML est une exception : il agit sur des champs produits par un analyseur principal et vous pouvez ajouter au maximum 5 instances à un seul pipeline.

**Traitement conditionnel non pris en charge**  
Les processeurs d'analyse (à l'exception de Grok et XML) ne prennent pas en charge le traitement conditionnel avec le `when` paramètre. Cela inclut les analyseurs OCSF, CSV, JSON KeyValue, VPC, Route53, RDS, WAF, Postgres et Amazon. CloudFront Pour de plus amples informations, veuillez consulter [Syntaxe d'expression pour le traitement conditionnel](conditional-processing.md).

## Processeur OCSF
<a name="ocsf-processor"></a>

Analyse et transforme les données des journaux conformément aux normes OCSF (Open Cybersecurity Schema Framework).

**Configuration**  
Configurez le processeur OCSF avec les paramètres suivants :

```
processor:
  - ocsf:
      version: "1.5"
      mapping_version: 1.5.0
      schema:
          microsoft_office365_management_activity:
```Parameters

`version` (obligatoire)  
Version du schéma OCSF à utiliser pour la transformation. Doit être 1,5

`mapping_version` (obligatoire)  
La version cartographique OCSF pour la transformation. Doit être 1.5.0.

`schema` (obligatoire)  
Objet de schéma spécifiant le type de source de données. Les schémas pris en charge dépendent du type de source de pipeline : chaque type de source possède son propre ensemble de schémas OCSF compatibles. Vous devez utiliser un schéma qui correspond au type de source de votre pipeline.

Ce tableau répertorie les combinaisons de schémas prises en charge.


| Type de source de pipeline | Schémas pris en charge | Version | Version cartographique | 
| --- | --- | --- | --- | 
| cloudwatch\_logs | cloud\_trail: | 1.5 | Facultatif | 
| cloudwatch\_logs | route53\_resolver: | 1.5 | Facultatif | 
| cloudwatch\_logs | vpc\_flow: | 1.5 | Facultatif | 
| cloudwatch\_logs | eks\_audit: | 1.5 | Facultatif | 
| cloudwatch\_logs | aws\_waf: | 1.5 | Facultatif | 
| cloudwatch\_logs | aws\_nlb: | 1.5 | Facultatif | 
| s3 | N'importe quel schéma OCSF | N’importe lequel | N’importe lequel | 
| microsoft\_office365 | microsoft\_office365: | 1.5 | 1.5.0 | 
| microsoft\_entraid | microsoft\_entraid: | 1.5 | 1.5.0 | 
| microsoft\_windows\_event | microsoft\_windows\_event: | 1.5 | 1.5.0 | 
| paloaltonetworks\_nextgenerationfirewall | paloaltonetworks\_nextgenerationfirewall: | 1.5 | 1.5.0 | 
| okta\_auth0 | okta\_auth0: | 1.5 | 1.5.0 | 
| okta\_sso | okta\_sso: | 1.5 | 1.5.0 | 
| crowdstrike\_falcon | crowdstrike\_falcon: | 1.5 | 1.5.0 | 
| github\_auditlogs | github\_auditlogs: | 1.5 | 1.5.0 | 
| sentinelone\_endpointsecurity | sentinelone\_endpointsecurity: | 1.5 | 1.5.0 | 
| servicenow\_cmdb | servicenow\_cmdb: | 1.5 | 1.5.0 | 
| wiz\_cnapp | wiz\_cnapp: | 1.5 | 1.5.0 | 
| zscaler\_internetaccess | zscaler\_internetaccess: | 1.5 | 1.5.0 | 

## Processeur CSV
<a name="csv-processor"></a>

Analyse les données au format CSV dans des champs structurés.

**Configuration**  
Configurez le processeur CSV avec les paramètres suivants :

```
processor:
  - csv:      
      column_names: ["col1", "col2", "col3"]
      delimiter: ","
      quote_character: '"'
```Parameters

`column_names` (facultatif)  
Tableau de noms de colonnes pour les champs analysés. Maximum de 100 colonnes, chaque nom pouvant contenir 128 caractères. S'il n'est pas fourni, la valeur par défaut est column\_1, column\_2, etc.

`delimiter` (facultatif)  
Caractère utilisé pour séparer les champs CSV. Il doit s'agir d'un seul caractère. La valeur par défaut est virgule (,).

`quote_character` (facultatif)  
Caractère utilisé pour citer les champs CSV contenant des délimiteurs. Il doit s'agir d'un seul caractère. La valeur par défaut est un guillemet double («).

Pour utiliser le processeur sans spécifier de paramètres supplémentaires, utilisez la commande suivante :

```
processor:
  - csv: {}
```

## Processeur Grok
<a name="grok-processor"></a>

Analyse les données non structurées à l'aide de modèles Grok. Au maximum 1 Grok est pris en charge par pipeline. Pour plus de détails sur le transformateur Grok dans CloudWatch Logs, consultez la section [ Processeurs que vous pouvez utiliser ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch-Logs-Transformation-Processors.html) dans le Guide * de l'utilisateur * CloudWatch des journaux.

**Configuration**  
Configurez le processeur Grok avec les paramètres suivants :

Lorsque la source de données est un dictionnaire, vous pouvez utiliser cette configuration :

```
processor:
  - grok:      
      match:
       source_key: ["%{WORD:level} %{GREEDYDATA:msg}"]
```

Lorsque la source de données est CloudWatch Logs, vous pouvez utiliser cette configuration :

```
processor:
  - grok:      
      match:
       source_key: ["%{WORD:level} %{GREEDYDATA:msg}"]
```Parameters

`match` (obligatoire)  
Cartographie des champs avec des motifs Grok. Un seul mappage de champs est autorisé.

`match.<field>` (obligatoire)  
Tableau avec un seul motif Grok. 512 caractères maximum par motif.

`when` (facultatif)  
Expression conditionnelle qui détermine si ce processeur s'exécute. La longueur maximale est de 256 caractères. Consultez [Syntaxe d'expression pour le traitement conditionnel](conditional-processing.md).

**Important**  
Si le processeur Grok est utilisé comme analyseur (premier processeur) dans un pipeline et que sa `when` condition est évaluée à false, le pipeline entier ne s'exécute pas pour cet événement de journal. Les analyseurs doivent être exécutés pour que les processeurs en aval puissent recevoir des données structurées.

## Processeur VPC
<a name="vpc-processor"></a>

Analyse les données du VPC Flow Log dans des champs structurés.

**Configuration**  
Configurez le processeur VPC avec les paramètres suivants :

```
processor:
  - parse_vpc: {}
```

## Processeur JSON
<a name="json-processor"></a>

Analyse les données JSON dans des champs structurés.

**Configuration**  
Configurez le processeur JSON avec les paramètres suivants :

```
processor:
  - parse_json:
      source: "message"
      destination: "parsed_json"
```Parameters

`source` (facultatif)  
Le champ contenant les données JSON à analyser. En cas d'omission, l'intégralité du message du journal est traitée

`destination` (facultatif)  
Le champ dans lequel le JSON analysé sera stocké. En cas d'omission, les champs analysés sont ajoutés au niveau racine

## Processeur Route 53
<a name="route53-processor"></a>

Analyse les données du journal du résolveur Route 53 dans des champs structurés.

**Configuration**  
Configurez le processeur Route 53 avec les paramètres suivants :

```
processor:
  - parse_route53: {}
```

## Processeur Amazon RDS
<a name="rds-processor"></a>

Analyse les données du journal Amazon RDS Aurora dans des champs structurés. Le `parse_rds` processeur n'est pris en charge que lorsque celui du pipeline l'`data_source_name`est`amazon_rds`. Il applique la logique d'analyse qui correspond à celle du `data_source_type` pipeline.

**Configuration**  
Configurez le processeur Amazon RDS avec les paramètres suivants :

```
processor:
  - parse_rds: {}
```

## Key-value processeur
<a name="key-value-processor"></a>

Analyse les données formatées par paires clé-valeur dans des champs structurés.

**Configuration**  
Configurez le processeur clé-valeur avec les paramètres suivants :

```
processor:
  - key_value:
      source: "message"
      destination: "parsed_kv"
      field_delimiter: "&"
      key_value_delimiter: "="
```Parameters

`source` (facultatif)  
Champ contenant des données clé-valeur. 128 caractères maximum.

`destination` (facultatif)  
Champ cible pour les paires clé-valeur analysées. 128 caractères maximum.

`field_delimiter` (facultatif)  
Modèle pour diviser les paires clé-valeur. 10 caractères maximum.

`key_value_delimiter` (facultatif)  
Modèle pour séparer les clés des valeurs. 10 caractères maximum.

`overwrite_if_destination_exists` (facultatif)  
S'il faut remplacer le champ de destination existant.

`prefix` (facultatif)  
Préfixe à ajouter aux clés extraites. 128 caractères maximum.

`non_match_value` (facultatif)  
Valeur pour les clés sans allumettes. 128 caractères maximum.

Pour utiliser le processeur sans spécifier de paramètres supplémentaires, utilisez la commande suivante :

```
processor:
  - key_value: {}
```

## analyseur XML
<a name="xml-processor"></a>

Utilisez l'analyseur XML pour convertir un champ spécifié contenant une chaîne XML au format JSON. Utilisez l'analyseur XML lorsque les événements de votre journal contiennent des champs XML intégrés que vous souhaitez interroger sous forme de données structurées. L'analyseur XML agit sur un champ nommé qui contient déjà une chaîne XML. Placez cet analyseur après un analyseur principal dans le pipeline. Vous pouvez ajouter au maximum 5 `parse_xml` analyseurs à un seul pipeline.

**Configuration**  
Configurez l'analyseur XML avec les paramètres suivants :

```
processor:
  - parse_json:
      source: "@message"
  - parse_xml:
      source: "body"
      destination: "parsed_xml"
```Parameters

`source` (Obligatoire)  
Spécifie le champ qui contient la chaîne XML à analyser. Utilisez la notation par points pour accéder aux champs imbriqués. Par exemple, `event.body`. 128 caractères maximum.

`destination` (facultatif)  
Spécifie le champ dans lequel la structure XML analysée est stockée. Si vous omettez ce paramètre, les champs analysés sont ajoutés au niveau racine. 128 caractères maximum.

`when` (facultatif)  
Expression conditionnelle qui détermine si cet analyseur s'exécute. La longueur maximale est de 256 caractères. Pour de plus amples informations, veuillez consulter [Syntaxe d'expression pour le traitement conditionnel](conditional-processing.md).

**Exemple : sortie d'un analyseur XML**  
Étant donné l'événement de journal JSON suivant avec un champ XML intégré :

```
{
  "body": "<Person id=\"123\" active=\"true\"><name>John</name><age>30</age></Person>"
}
```

Avec la configuration suivante :

```
processor:
  - parse_json:
      source: "@message"
  - parse_xml:
      source: "body"
      destination: "parsed_xml"
```

L'analyseur XML produit le résultat suivant :

```
{
  "body": "<Person id=\"123\" active=\"true\"><name>John</name><age>30</age></Person>",
  "parsed_xml": {
    "id": "123",
    "active": "true",
    "name": "John",
    "age": "30"
  }
}
```Notes de comportement

Profondeur de nidification  
L'analyseur XML prend en charge une profondeur d'imbrication maximale de 25 niveaux. Les éléments imbriqués au-delà de cette limite génèrent une erreur.

Gestion des erreurs  
Un code XML mal formé ne fait pas échouer le pipeline. L'analyseur préserve l'original `@message` et définit `@pipeline.processing.status = "error"` l'événement.