Suivre le devis jusqu’à son service destinataire

Introduction

PARCEL est une boutique de cadeaux fictive. Les visiteurs découvrent Arc lamp ou Clay vase et comparent livraison et retrait. Le retrait renvoie déjà une estimation, mais la livraison échoue. Votre mission consiste à suivre une nouvelle requête en échec depuis l’entrée jusqu’au service qui répond, puis à rétablir les bons tarifs sans casser le retrait.

Les bases du terminal suffisent. Vous modifierez deux courts fichiers Nginx, lirez de vrais journaux et testerez de vraies réponses. Aucun développement applicatif, SDK, compte externe, achat ou renseignement personnel n’est nécessaire. Tous les services partagent une instance d’entraînement préparée : il s’agit de corrélation de requêtes, pas d’une plateforme complète de traçage distribué.

Utilisez Website pour parcourir le site et demander des estimations. Exécutez toutes les commandes dans Workstation, initialement dans /home/labex/project/parcel. Chaque unité dispose de sa propre instance. L’entrée sur le port 8081 transmet chaque demande à un backend. La livraison écoute sur 8091, le retrait sur 8092. Un port identifie un service réseau ; dans Workstation, 127.0.0.1 désigne cette instance de laboratoire.

Donner une référence commune à une nouvelle requête

Dans cette étape, vous découvrirez le parcours client normal, observerez l’échec et relierez une nouvelle requête dans deux journaux réels. Commencez dans Website.

Découvrir la boutique

Ouvrez Arc lamp sous Two good things. La fiche affiche $48 et une illustration locale. Choisissez Estimate collection, gardez Arc lamp et Near, puis cliquez sur Get estimate. Vous devez voir $2.00 et HTTP 200. C’est la fonction normale à préserver. Revenez à l’accueil avec PARCEL↗, ouvrez Delivery, puis cliquez sur Get estimate : Estimate unavailable et HTTP 404 apparaissent.

HTTP est le protocole de requête/réponse du navigateur. 200 signifie que la réponse réussit ; 404, que le service destinataire n’a pas trouvé le chemin demandé. Une erreur de connexion est différente : aucune réponse serveur exploitable n’a été reçue. La référence indique actuellement not available, ce qui empêche de relier facilement la réponse client aux journaux.

Comprendre les éléments observés

Le journal d’entrée enregistre déjà l’identifiant que Nginx génère pour chaque requête. Le backend peut enregistrer celui qui lui est transmis. Une fois les deux reliés, une requête en échec produit des enregistrements de cette forme ; les points représentent votre propre identifiant :

entry:    {"id":"...","path":"/api/delivery","status":404,"upstream":"127.0.0.1:8091","upstream_status":"404"}
delivery: {"service":"delivery","id":"...","path":"/v1/shipping","status":404}

Le chemin d’entrée est celui demandé par le navigateur. Le chemin backend est celui que l’entrée a réellement transmis. upstream désigne l’adresse contactée et upstream_status son véritable état de réponse. Le même identifiant relie ces observations ; comparer seulement les horaires serait moins fiable avec de nombreuses requêtes. Aucun corps de requête ni secret n’est journalisé.

Relier l’identifiant

Passez dans Workstation. pwd affiche le répertoire courant, cat le contenu d’un fichier :

pwd

Le résultat doit être /home/labex/project/parcel. Si vous avez quitté ce dossier, exécutez cd /home/labex/project/parcel ; cd change le répertoire courant. Un chemin sans / initial, comme correlation.conf, est relatif à ce répertoire.

cat correlation.conf

Le fichier ne contient qu’un commentaire. Nginx est le serveur d’entrée préparé. Sa configuration contient des directives terminées par des points-virgules. Le serveur principal inclut ce petit fichier ; vous ne modifiez donc pas sa structure principale.

Un en-tête est une valeur nommée transportée avec une requête ou une réponse HTTP. proxy_set_header définit celui envoyé au backend ; add_header en ajoute un à la réponse client. $request_id est la valeur générée par Nginx pour cette requête. always inclut l’en-tête aussi bien en cas d’échec que de succès. X-Request-ID est la convention commune ici. L’entrée génère son propre identifiant au lieu de faire confiance à celui d’un visiteur.

cat > correlation.conf remplace le fichier par un here-document. Collez tout le bloc, y compris le dernier CONF seul sur sa ligne. Les guillemets de 'CONF' conservent littéralement $request_id pour que Nginx, et non le shell, l’interprète :

cat > correlation.conf <<'CONF'
proxy_set_header X-Request-ID $request_id;
add_header X-Request-ID $request_id always;
CONF

Relisez le fichier sauvegardé, puis appliquez-le avec l’outil fourni. bash exécute ce script shell. Il vérifie d’abord la syntaxe et ne recharge Nginx que si elle est valide ; il ne répare pas les routes et ne juge pas les prix.

cat correlation.conf

bash reload.sh

Attendez un test de configuration réussi et Configuration accepted. Send a new request to test it. Si une ligne est signalée, comparez orthographe, points-virgules et signes dollar littéraux au bloc, réécrivez et recommencez. Si le test échoue, la configuration précédente reste en service. Recharger ne change pas une ancienne réponse : envoyez une nouvelle requête.

Suivre votre propre nouvel échec

Dans Delivery de Website, cliquez encore sur Get estimate. La demande échoue toujours, mais Request reference contient maintenant 32 caractères hexadécimaux. Copiez cette nouvelle valeur exacte, pas les points ci-dessus ni un identifiant d’une capture.

Revenez dans Workstation. Une variable shell conserve une valeur pour les commandes suivantes. Remplacez PASTE_YOUR_NEW_REQUEST_REFERENCE_HERE par la nouvelle référence exacte copiée depuis Website. Gardez les guillemets simples, sans espace autour de =. Ils préservent le texte littéral ; n’exécutez pas le texte de remplacement inchangé :

REQUEST_ID='PASTE_YOUR_NEW_REQUEST_REFERENCE_HERE'

grep affiche les lignes correspondantes. -F traite la valeur comme du texte simple ; les guillemets doubles gardent la valeur entière. Ces chemins absolus fonctionnent depuis tout répertoire :

grep -F "$REQUEST_ID" /var/log/parcel/entry.jsonl

grep -F "$REQUEST_ID" /var/log/parcel/delivery.jsonl

Les deux enregistrements doivent avoir exactement le même identifiant, le chemin backend /v1/shipping et l’état 404. Vous avez prouvé que la livraison atteint un backend qui répond : il ne s’agit pas d’un service arrêté ni d’une connexion absente. Une sortie vide signifie souvent une référence ancienne ou mal copiée : redemandez dans Website, copiez la nouvelle valeur et affectez à nouveau REQUEST_ID. Avec seulement l’en-tête de réponse, le backend conserverait - ; les deux directives sont nécessaires.

Le contrôle de cette étape envoie de nouvelles requêtes en lecture seule. Il n’exige pas de variable shell particulière, d’historique de commandes ni de fichier de journaux copié.

Rétablir la route et préserver les deux estimations

Dans cette étape, vous utiliserez les deux enregistrements et le contrat de service pour réparer la livraison. Commencez dans Workstation.

Séparer l’adresse du chemin

Affichez la configuration de routage avec cat :

cat routes.conf

Un bloc location = correspond à un chemin public exact ; les accolades regroupent ses directives. proxy_pass indique à Nginx où envoyer la requête. Dans http://127.0.0.1:8091/v1/shipping, l’adresse et le port sélectionnent un service, tandis que /v1/shipping sélectionne une opération. Chacune de ces parties peut être erronée. Avec ces locations exactes, le chemin backend configuré remplace le chemin public correspondant ; les options de requête continuent à être transmises.

Voici le contrat des services préparés :

Les deux services répondent aussi à /health, mais leur bonne santé ne prouve pas le routage. Les journaux montrent que la livraison arrive sur 8091 à /v1/shipping. Ce service possède bien la livraison, mais pas ce chemin. Le contrat demande /v1/delivery. L’adresse et le chemin du retrait sont déjà corrects.

Appliquer la petite réparation

Remplacez uniquement le fichier éditable en préservant le retrait :

cat > routes.conf <<'CONF'
location = /api/delivery {
    proxy_pass http://127.0.0.1:8091/v1/delivery;
}
location = /api/collection {
    proxy_pass http://127.0.0.1:8092/v1/collection;
}
CONF

bash reload.sh

Si la syntaxe échoue, comparez accolades et points-virgules, réécrivez le fichier et recommencez. Ne modifiez ni backend, ni site, ni journaux, ni configuration principale. Retourner 200 sans véritable estimation correcte masquerait le défaut.

Tester les prix réels et la corrélation

Dans Website, ouvrez Delivery et redemandez Arc lamp / Near : vous devez voir $6.00, HTTP 200 et une nouvelle référence. Demandez Clay vase / Far : attendez $13.00. Dans Collection, Arc lamp / Near doit toujours donner $2.00 et Clay vase / Far, $4.00. Chaque clic envoie une nouvelle requête, donc les références doivent différer. Les fiches ouvertes depuis PARCEL↗ doivent garder leurs images et prix.

Revenez dans Workstation. curl envoie une requête HTTP. -sS masque la progression mais affiche les erreurs de connexion ; -i inclut les en-têtes. Les guillemets simples gardent & dans l’URL au lieu de laisser le shell l’interpréter. Les options après ? choisissent l’objet et la distance :

curl -sS -i 'http://127.0.0.1:8081/api/delivery?item=vase&zone=far'

Attendez HTTP/1.1 200 OK, un en-tête X-Request-ID et du JSON avec "service": "delivery", "amount": 13, "currency": "USD". JSON est un format texte de valeurs nommées. Le request_id du corps doit être égal à l’en-tête. La casse des noms d’en-tête peut varier sans changer leur sens.

Prenez la référence de cette réponse et affectez à nouveau REQUEST_ID, puis répétez les deux grep -F de l’étape 1. Les deux journaux affichent maintenant 200 et celui de delivery indique /v1/delivery. Les anciens 404 restent utiles : ne les effacez ni ne les réécrivez.

Testez séparément la fonction préservée :

curl -sS -i 'http://127.0.0.1:8081/api/collection?item=lamp&zone=near'

Attendez 200, "service": "collection" et "amount": 2. Un 404 reste une réponse HTTP : curl sans option d’échec sur statut HTTP peut se terminer normalement. Une erreur de connexion indique plutôt un processus indisponible ou une mauvaise adresse ; revenez à la dernière configuration fonctionnelle au lieu de la confondre avec la preuve de chemin précédente.

Le contrôle final demande toutes les combinaisons objet/distance des deux opérations, rapproche les nouveaux identifiants des vrais journaux et teste le site complet. Seuls les enregistrements d’accès ordinaires s’ajoutent ; l’évaluation ne recharge pas la configuration, ne réécrit pas de fichier et ne crée pas de commande client.

Résumé

Vous avez relié les journaux d’entrée et de backend d’une nouvelle requête par une référence générée, distingué un chemin absent d’une erreur de connexion et réparé la véritable route. Vous avez testé plusieurs résultats métier en préservant le retrait. Le défi indépendant change le service destinataire avec les mêmes méthodes d’adresse/chemin et de corrélation.