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.

# Configurer la visibilité des points de terminaison HTTP
<a name="Application-Signals-EndpointVisibility"></a>

Cette page fournit des conseils aux clients d'Application Signals qui s'attendent à voir leurs opérations de service HTTP séparées par des noms de point de terminaison spécifiques, mais à voir plusieurs points de terminaison regroupés dans la même métrique. Par défaut, Application Signals tronque la dimension `Operation` métrique au premier segment de chemin d'URL pour les services HTTP (par exemple, `/api/v1/users` becomes`GET /api`) afin de préserver les métriques à faible cardinalité. Par conséquent, les utilisateurs peuvent constater que les services dotés de plusieurs points de terminaison partageant le même préfixe ont une visibilité limitée sur l'état de fonctionnement de chaque point de terminaison. Vous pouvez suivre les étapes ci-dessous pour configurer les points de terminaison des opérations de service selon la granularité souhaitée.

**Important**  
La modification de la visibilité des terminaux est un changement radical car elle affecte les dimensions métriques des signaux d'application pour les opérations de service. N'oubliez pas de mettre à jour vos seuils SLO, vos alarmes et vos and/or tableaux de bord en conséquence.

## AWS Solution de distribution pour OpenTelemetry (ADOT)
<a name="Application-Signals-EndpointVisibility-ADOT"></a>

Pour les clients utilisant AWS Distro for OpenTelemetry (ADOT), définissez la variable d'`OTEL_AWS_HTTP_OPERATION_PATHS`environnement avec une liste séparée par des virgules de modèles de chemins d'URL pour le service HTTP :

```
export OTEL_AWS_HTTP_OPERATION_PATHS="/path/to/endpoint, /another/{placeholder}/endpoint"
```

Cette variable utilise le plus long préfixe correspondant à l'`url.path`attribut span du serveur HTTP pour déterminer le nom de l'opération. Les modèles de caractères génériques correspondent à n'importe quel segment d'URL et peuvent être désignés par `{placeholder}``:placeholder`, ou. `*` Après avoir défini la variable, redémarrez votre application pour que les nouveaux groupements de points de terminaison prennent effet.

Cette variable est prise en charge dans ADOT pour Java Node.js, Python et .NET.

**Exemple**

Prenons l'exemple d'un service d'API qui reçoit le trafic suivant :

```
GET  /api/users
GET  /api/users/42
GET  /api/users/42/orders
POST /api/users/99/orders
POST /api/users/42/orders
GET  /api/users/42/orders/7/items
GET  /api/products
```

Par défaut, Application Signals regroupe tous ces indicateurs dans `GET /api` des métriques de `POST /api` service, ce qui rend impossible de distinguer les performances entre les points de terminaison.

Pour résoudre ce problème, définissez la variable d'environnement avec les modèles de chemin souhaités :

```
export OTEL_AWS_HTTP_OPERATION_PATHS="/api/users/{userId}/orders/{orderId}/items, /api/users/{userId}/orders, /api/users/{userId}, /api/users, /api/products"
```

Avec cette configuration, Application Signals affiche des opérations distinctes. Plusieurs demandes peuvent être résolues selon le même modèle configuré :


**Exemples de résultats de configuration de la visibilité des terminaux**  

| Demande entrante | Fonctionnement par défaut | Avec config | 
| --- | --- | --- | 
| GET /api/users | GET /api | GET /api/users | 
| GET /api/users/42 | GET /api | GET /api/users/{userId} | 
| GET /api/users/42/orders | GET /api | GET /api/users/{userId}/orders | 
| POST /api/users/99/orders | POST /api | POST /api/users/{userId}/orders | 
| POST /api/users/42/orders | POST /api | POST /api/users/{userId}/orders | 
| GET /api/users/42/orders/7/items | GET /api | GET /api/users/{userId}/orders/{orderId}/items | 
| GET /api/products | GET /api | GET /api/products | 

## OpenTelemetry Solution native
<a name="Application-Signals-EndpointVisibility-NativeOTel"></a>

Si vous utilisez le OpenTelemetry SDK natif (sans ADOT), vous pouvez soit remplacer le nom de l'intervalle à l'aide du processeur de transformation de votre OpenTelemetry Collector, soit directement dans le code de l'application.

**Note**  
Vous devez configurer votre collecteur avec un exportateur OTLP pour conserver le nom de l' OpenTelemetry intervalle afin de CloudWatch pouvoir l'analyser pour le nom de l'opération Application Signals. Pour plus d'informations, consultez la section [Envoi de données OTLP à CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-OTLPSimplesetup.html).

**Option 1 (recommandée) : Collector-side transformation**

Utilisez le [processeur de transformation](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/transformprocessor) pour définir les noms des intervalles en fonction des modèles d'URL. Le processeur de transformation utilise le langage OTTL (OpenTelemetry Transformation Language) et peut modifier directement le `name` champ span.

Classez les règles de la plus superficielle à la plus profonde : les instructions s'exécutent de manière séquentielle, de sorte que les correspondances plus spécifiques situées plus loin dans la liste remplacent les correspondances générales définies précédemment. Dans l'exemple suivant, la valeur de l'attribut span `url.path` est mise en correspondance et le nom de span obtenu est défini sur la méthode de demande suivie du modèle d'URL souhaité.

```
processors:
  transform/operation_names:
    trace_statements:
      - context: span
        conditions:
          - IsMatch(attributes["url.path"], "^/api/contests(/|$)")
        statements:
          - set(name, Concat([attributes["http.request.method"], "/api/contests"], " "))

      - context: span
        conditions:
          - IsMatch(attributes["url.path"], "^/api/contests/[^/]+$")
        statements:
          - set(name, Concat([attributes["http.request.method"], "/api/contests/{id}"], " "))

      - context: span
        conditions:
          - IsMatch(attributes["url.path"], "^/api/contests/[^/]+/leaderboard(/|$)")
        statements:
          - set(name, Concat([attributes["http.request.method"], "/api/contests/{id}/leaderboard"], " "))

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [resourcedetection, transform/operation_names, batch]
      exporters: [otlphttp/xray]
```

**Option 2 : définir le nom de l'intervalle dans le code de l'application**

Vous pouvez définir manuellement le nom de l'intervalle pour les serveurs dans le code de votre application à l'aide de l' OpenTelemetry API. Définissez le nom pour `{HTTP_METHOD} {route_template}` lequel le modèle d'itinéraire utilise des espaces réservés paramétrés. Notez qu'il s'agit d'une option de secours codée en dur et que vous devez mettre à jour manuellement le nom de l'intervalle dans chaque gestionnaire de requêtes HTTP pour appliquer cette modification.

**Java**

```
import io.opentelemetry.api.trace.Span;

// Inside your request handler
Span.current().updateName("GET /api/contests/{id}/leaderboard");
```

**Python**

```
from opentelemetry import trace

# Inside your request handler
span = trace.get_current_span()
span.update_name("GET /api/contests/{id}/leaderboard")
```

**Go**

```
import "go.opentelemetry.io/otel/trace"

// Inside your request handler
span := trace.SpanFromContext(ctx)
span.SetName("GET /api/contests/{id}/leaderboard")
```

**Node.js**

```
import { trace } from '@opentelemetry/api';

// Inside your request handler
const span = trace.getActiveSpan();
if (span) {
  span.updateName('GET /api/contests/{id}/leaderboard');
}
```