Concepts et architecture d'X-Ray

Surveillance et dépannage sur AWS

John Q. Martin

Principal Consultant

Le défi des systèmes répartis

Application monolithique

Flux linéaire, contenu dans un seul processus
Débogage simple

Application répartie

Une requête touche plusieurs services, BD et API externes
En cas d'échec, quel service en est la cause ?

Un gros nœud emmêlé de fils colorés illustrant la difficulté de suivre une requête dans un système réparti

Qu'est-ce qu'AWS X-Ray ?

X-Ray est un service de traçage réparti qui :

Suit les requêtes de bout en bout entre les services
Mesure la latence et détecte les erreurs à chaque étape
Visualise l'architecture sous forme de carte des services

Exemple de parcours de requête :

Schéma d'un parcours de requête à travers plusieurs services dans un traçage réparti

Cinq capacités clés

Cinq capacités clés d'X-Ray : traçage des requêtes, analyse de performance, détection d'erreurs, carte des services et perspectives

Fonctionnement du traçage

Flux de traçage réparti : une requête entre dans Service A, appelle Service B puis Service C, chacun transmet l'ID de trace dans l'en-tête HTTP ; chaque service émet un segment avec le même ID de trace vers le démon X-Ray, qui les transmet à X-Ray où ils sont assemblés en une trace complète

Propagation de l'ID de trace et de l'en-tête

Format d'ID de trace :

Format d'ID de trace X-Ray avec numéro de version, horodatage Unix en hexadécimal et identifiant unique

En-tête HTTP :

X-Amzn-Trace-Id:
  Root=1-5e8c1234-...;
  Parent=abc123;
  Sampled=1

Root, ID de trace, identique pour tous les services
Parent, ID du segment amont
Sampled, 0 ou 1, tracé ou ignoré

Le démon X-Ray

Rôle :

Écoute sur le port UDP 2000
Reçoit les données de segments de votre application
Met en mémoire tampon, regroupe et transfère à l'API X-Ray
Désolidarise votre appli du service X-Ray

Déploiement selon l'environnement :

Déploiement du démon X-Ray selon l'environnement : automatique sur Lambda, service sur EC2 et conteneur sidecar sur ECS

Échantillonnage

Règle par défaut :

Première requête par seconde : toujours tracée
5 % des requêtes supplémentaires : échantillonnées

Champs de règle personnalisée :

fixed_target : requêtes/s toujours tracées
rate : pourcentage des requêtes supplémentaires
priority : le plus petit nombre l'emporte

Stratégie d'exemple :

Rule 1 (priority 1):
  5xx errors -> 100% sampling

Rule 2 (priority 10):
  Normal traffic -> 5% sampling

Segments

Ce qu'un segment enregistre :

Nom du service
Heures de début et de fin
ID de trace
Détails de la requête et de la réponse HTTP
Compte et région AWS

États des segments :

Cinq états de segment X-Ray : en cours, ok, erreur, panne et limitation

Sous-segments

Comparaison de chronologies : sans sous-segments une seule barre totale de 800 ms ; avec sous-segments, les mêmes 800 ms découpés en DynamoDB 50 ms, PaymentService 400 ms mis en évidence comme goulot, et InventoryService 300 ms

Rôle des sous-segments :

Offrent un minutage fin à l'intérieur d'un segment
Suivent les appels en aval
Transforment 800 ms en :
- DynamoDB.PutItem : 50 ms
- Appel à PaymentService : 400 ms
- Appel à InventoryService : 300 ms

Espaces de noms :

Trois espaces de noms de sous-segment : aws pour les appels AWS, remote pour HTTP externe et local pour le code personnalisé

Annotations

Points clés :

Paires clé-valeur indexées – recherchables et filtrables
Limite : 50 indexées par trace
Types : chaîne, nombre, booléen

À utiliser pour :

user_id, order_id, environnement
version, indicateurs de fonction, codes d'erreur

Syntaxe de filtre :

annotation.user_id = "user-123"

annotation.environment = "production"
AND annotation.version = "1.2.3"

Métadonnées

Points clés :

Non indexées – ni recherche ni filtrage
Aucune limite de taille
Prend en charge toute structure JSON

À utiliser pour :

Corps complets de requêtes et de réponses
Messages d'erreur et traces de pile
Contexte d'affaires (articles de commande, adresses)

Annotations vs métadonnées :

Tableau comparatif : annotations indexées et recherchables, versus métadonnées détaillées et non indexées

Structure de trace complète

Structure de trace complète avec quatre segments et l'API de paiement externe comme opération la plus lente

Résumé de la leçon

X-Ray : service de traçage réparti pour une visibilité de bout en bout entre services
Mécanisme de traçage : propagation de l'ID de trace via en-têtes HTTP, segments collectés par le démon, règles d'échantillonnage configurables
Composants d'une trace :
- Segments : enregistrements du travail au niveau service
- Sous-segments : minutage fin des opérations en aval
- Annotations : paires clé-valeur indexées pour filtrage et recherche
- Métadonnées : contexte détaillé, non indexé

Passons à la pratique !

Surveillance et dépannage sur AWS