TP : Corréler les quatre signaux de deux services auto-instrumentés

Ce que vous allez apprendre dans ce TP

• Auto-instrumenter tous les signaux
• Garantir une ressource commune
• Naviguer entre les signaux

Introduction #

Ce que vous allez apprendre dans cette section

• Auto-instrumenter tous les signaux
• Garantir une ressource commune
• Naviguer entre les signaux

Contexte. Une boutique de deux services renvoie des erreurs par intermittence. Vous instrumentez sans toucher au code et menez l'enquête en naviguant d'un signal à l'autre.

Prérequis : Docker et Python 3.10 ou plus ; la pile grafana/otel-lgtm (Collector, Tempo, Loki, Prometheus, Pyroscope et Grafana dans un seul conteneur)  ·  Durée estimée : 50 min

Une cause trouvée en quelques clics grâce à une ressource commune et aux identifiants partagés.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Démarrer la pile d'observabilité

   Pourquoi ? Une seule image fournit un Collector OTLP et tous les backends : on se concentre sur le signal.

   Lancez grafana/otel-lgtm, créez un environnement Python et pointez les exportateurs vers le port OTLP/HTTP 4318.

2. 2. Écrire les deux services

   Pourquoi ? Le code ne contient aucune ligne OpenTelemetry : tout viendra de l'auto-instrumentation.

   Créez front.py (port 8001) qui appelle stock.py (port 8002) ; le service stock échoue sur 15 % des requêtes avec un log d'erreur.

3. 3. Démarrer avec une ressource commune

   Pourquoi ? Les mêmes variables pour les trois signaux garantissent la même ressource : c'est la clé de la corrélation.

   Lancez chaque service avec opentelemetry-instrument, les trois exportateurs OTLP, la capture des logs et des attributs de ressource communs, puis générez du trafic.

4. 4. Partir de la métrique

   Pourquoi ? L'enquête commence comme une alerte : une métrique d'erreurs issue des conventions HTTP, identique pour tous les services.

   Dans Prometheus, calculez le taux d'erreurs 5xx par service à partir de l'histogramme http.server.request.duration (ou de son équivalent selon la version d'instrumentation). Activez les exemplars et ouvrez une trace depuis un point.

5. 5. De la trace aux logs

   Pourquoi ? La trace montre quel service a échoué ; ses logs disent pourquoi.

   Dans Tempo, cherchez les traces en erreur, ouvrez-en une, constatez que le span serveur de stock est en 503 et utilisez Logs for this span pour trouver le message « pool de connexions épuisé ». Faites le chemin inverse depuis Loki.

6. 6. Carte des services et métriques de spans

   Pourquoi ? Les métriques calculées depuis les spans donnent débit, erreurs et durée par service et une carte des dépendances.

   Ouvrez l'onglet Service Graph de Tempo dans Explore : vérifiez l'arête front vers stock et son taux d'erreur. Notez la ligne de configuration (connecteur servicegraph ou générateur de métriques de Tempo) qui la rend possible.

7. 7. Casser puis réparer la corrélation

   Pourquoi ? Une ressource différente suffit à couper tous les liens : on le vérifie pour s'en souvenir.

   Redémarrez stock avec OTEL_LOGS_EXPORTER=none, regénérez du trafic et constatez que Logs for this span ne renvoie plus rien. Remettez la configuration et arrêtez tout.

Niveau de difficulté : ●●●○○ (3/5)