Suivi des traces applicatives avec Tempo

Objectifs du chapitre et prérequis

1. Contexte et prérequis

Prometheus et Loki permettent de collecter respectivement des métriques et des logs. Toutefois, lorsqu’une requête traverse plusieurs composants d’un système distribué (API, service métier, base de données, files de messages, etc.), il devient difficile de reconstituer son parcours uniquement à partir de métriques ou de journaux.

C’est là que les traces distribuées peuvent intervenir afin d’observer le cheminement d’une requête au sein d’un système complexe. À noter que ces trois concepts (métriques, logs et traces distribués) sont à l’origine d’un concept un peu plus large : la notion d’observabilité.

Ce chapitre s’attardera sur la mise en place de l’outil Grafana Tempo. Le chapitre suivant s’attardera sur la notion d’observabilité, notamment à travers la mise en place d’un agent de collecte compatible OpenTelemetry : Grafana Alloy.

2. Fichiers téléchargeables

Vous pouvez récupérer les exemples sur le repository GitHub suivant : https://github.com/EditionsENI/prometheus-grafana

Vous pouvez également récupérer ces fichiers dans l’archive chapitre-18.tar.gz sur la page du livre sur le site des Éditions ENI.

À propos de Tempo

1. Origine de Tempo

Les outils de gestion de traces distribuées remontent au début des années 2000 avec, dans un premier temps, l’arrivée de Dapper (chez Google). D’autres acteurs majeurs des réseaux sociaux américains (Amazon, Twitter et Facebook/Meta) ont également travaillé sur ces sujets.

Durant les années 2010, plusieurs outils open source ont été mis à disposition, parmi lesquels Zipkin en 2012 (créé initialement par Twitter) puis Jaeger en 2016 (créé initialement par la société Uber). C’est un peu plus tard que le projet OpenTelemetry a unifié ces différentes sources de données afin de les rendre interchangeables.

Comme indiqué, Jaeger et Zipkin étaient les solutions disponibles. Elles réclamaient néanmoins la mise en place d’un moteur Elasticsearch, ce qui posait toujours la question de la complexité de mise en œuvre : notamment le besoin d’indexation des données ou, tout simplement, la difficulté à opérer un moteur Elasticsearch.

Tempo est né d’un constat un peu similaire à celui qui avait donné naissance à Loki : pour beaucoup d’organisations, l’indexation massive des traces n’était pas indispensable. Tempo ne garde que les informations...

Mise en place de Tempo

1. Mode d’exécution

Le mode de fonctionnement de Tempo est très similaire à celui de Loki. Tout comme lui, il est possible d’opérer ce dernier en mode monolithique ou microservices. Il est également en mesure de stocker les données dans des Buckets S3.

Là encore, ces différentes options d’installation entraînent une complexité relativement importante qui ne sera pas abordée dans cet ouvrage.

Tout comme pour Loki, il est possible d’opérer Tempo à l’aide de paquets système Debian. C’est ce type d’installation qui sera privilégié pour la suite du chapitre.

Grafana Labs met à disposition des services managés de ses produits, ce qui permet de disposer d’une instance prête à l’emploi très rapidement. Là encore, faites attention aux coûts que pourrait engendrer l’utilisation de ces services (surtout à grande échelle) ainsi qu’aux problèmes éventuels de confidentialité que cela pourrait poser.

2. Installation de Tempo

À l’heure de la rédaction de ces lignes, Tempo est disponible en version 2.7.2 à l’adresse suivante : https://github.com/grafana/tempo/releases

Récupérez le paquet système tempo_2.7.2_linux_amd64.deb à l’aide des instructions suivantes :

$ export GHDL=https://github.com/grafana/tempo/releases/download  
$ export PKG="$GHDL/v2.7.2/tempo_2.7.2_linux_amd64.deb"  
$ wget $PKG  
$ sudo apt install ./tempo_2.7.2_linux_amd64.deb

Lors de l’installation du paquet, le système va démarrer le service associé.

Vérifiez l’état du service à l’aide de l’instruction status de la commande systemctl :

$ sudo systemctl status tempo

Ci-dessous un exemple de résultat attendu :

 tempo.service - Tempo service   
    Loaded: loaded (/etc/systemd/system/tempo.service; enabled;
preset: enabled)   
    Active: active (running) since Tue 2025-05-06 18:37:44 CEST; 
2 days ago   
  Main PID: 290024 (tempo)   
     Tasks: 17 (limit: 37766)   
    Memory: 22.9M...