

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.

# CloudWatch Métriques (OTel)
<a name="metrics-pipeline-selection-criteria"></a>

Les critères de sélection déterminent les métriques OTel qui entrent dans un pipeline pour être traitées. Chaque critère est une expression du formulaire `<path> == "<value>"` qui correspond à un attribut spécifique de la métrique entrante. Au moins un critère de sélection est requis.

Les critères sont regroupés dans un `match_all` bloc avec la sémantique AND : une métrique doit correspondre à chaque expression du groupe pour entrer dans le pipeline.

## Chemins pris en charge
<a name="selection-criteria-paths"></a>

Les chemins OTTL suivants sont pris en charge dans les critères de sélection :


**Chemins liés aux critères de sélection**  

| Chemin | Description | 
| --- | --- | 
| `resource.attributes["key"]` | Resource-level attribut | 
| `instrumentation_scope.name` | Nom de la portée de l'instrumentation | 
| `instrumentation_scope.version` | Version de la lunette d'instrumentation | 
| `instrumentation_scope.attributes["key"]` | Attribut de portée de l'instrumentation | 
| `metric.name` | Nom de la métrique | 
| `datapoint.attributes["key"]` | Datapoint-level attribut | 
| `attributes["key"]` | Forme abrégée pour `datapoint.attributes["key"]` | 

## Configuration
<a name="selection-criteria-configuration"></a>

Les critères de sélection sont définis dans la `source` section de configuration du pipeline :

```
pipeline:
  source:
    cloudwatch_metrics:
      format: otlp
      selection_criteria:
        - match_all:
            - 'resource.attributes["service.name"] == "my-service"'
            - 'metric.name == "http.server.request.duration"'
  processor:
    - add_attributes:
        attributes:
          - key: resource.attributes["team"]
            value: "platform-engineering"
  sink:
    - cloudwatch_metrics: {}
```

L'exemple suivant utilise tous les types de chemins pris en charge :

```
pipeline:
  source:
    cloudwatch_metrics:
      format: otlp
      selection_criteria:
        - match_all:
            - 'resource.attributes["service.name"] == "my-service"'
            - 'instrumentation_scope.name == "my-scope"'
            - 'instrumentation_scope.version == "1.0.0"'
            - 'instrumentation_scope.attributes["library"] == "otel-java"'
            - 'metric.name == "http.server.request.duration"'
            - 'datapoint.attributes["status_code"] == "200"'
            - 'attributes["environment"] == "production"'
  processor:
    - add_attributes:
        attributes:
          - key: resource.attributes["team"]
            value: "observability"
  sink:
    - cloudwatch_metrics: {}
```

## Vérifier avec ProMQL
<a name="selection-criteria-promql"></a>

CloudWatch mappe les étendues d'attributs OTLP aux étiquettes ProMQL en utilisant la convention des préfixes. `@` Utilisez ce mappage pour vérifier que votre pipeline traite les métriques comme prévu dans Query Studio :


**Chemin OTTL vers le mappage des étiquettes ProMQL**  

| Trajectoire OTTL du pipeline | Préfixe d'étiquette ProMQL | Exemple | 
| --- | --- | --- | 
| `resource.attributes["key"]` | `@resource.` | `@resource.service.name` | 
| `instrumentation_scope.name` | `@instrumentation.@name` | `@instrumentation.@name` | 
| `instrumentation_scope.attributes["key"]` | `@instrumentation.` | `@instrumentation.library` | 
| `datapoint.attributes["key"]` / `attributes["key"]` | `@datapoint.`ou nu | `status_code` | 

Par exemple, si votre pipeline ajoute `resource.attributes["team"]` de la valeur`"platform-engineering"`, vous pouvez confirmer qu'il a été appliqué :

```
{"CPUUtilization", "@resource.team"="platform-engineering"}
```

## Exigences et limitations
<a name="selection-criteria-requirements"></a>

Un seul `match_all` groupe  
Chaque pipeline prend en charge exactement un `match_all` groupe dans`selection_criteria`. Vous ne pouvez pas définir plusieurs `match_all` groupes dans un même pipeline.

Critères minimaux  
Au moins une expression est requise dans le `match_all` groupe.

Critères maximaux  
Un `match_all` groupe peut contenir au maximum 20 expressions.

Sémantique ET  
Toutes les expressions du `match_all` groupe doivent correspondre pour qu'une métrique entre dans le pipeline.

Correspondance exacte des chaînes  
Les valeurs doivent être des chaînes statiques. Les caractères génériques, les expressions régulières et les correspondances partielles ne sont pas pris en charge. Chaque expression doit utiliser l'`==`opérateur.

Aucun critère ne se chevauche entre les pipelines  
Chaque point de données métrique doit correspondre à au plus un pipeline. Si un point de données correspond à la fois à des critères de pipeline nouveaux et existants, la création de pipeline échoue. Pour éviter tout chevauchement, incluez au moins un chemin attributaire avec des valeurs distinctes dans les critères de sélection de chaque pipeline.  
Par exemple, les deux critères de sélection suivants se chevauchent car le pipeline A sélectionne toutes les mesures parmi `payment-service` lesquelles la métrique spécifique ciblée par le pipeline B :  

```
# Pipeline A — selects ALL metrics from payment-service
selection_criteria:
  - match_all:
      - 'resource.attributes["service.name"] == "payment-service"'

# Pipeline B — FAILS: a datapoint with service.name="payment-service"
# and metric.name="http.server.request.duration" matches both pipelines
selection_criteria:
  - match_all:
      - 'metric.name == "http.server.request.duration"'
```