Spring Boot : optimiser le tracing distribué avec OpenTelemetry et les spans personnalisées

Spring Boot : Optimiser le tracing distribué avec OpenTelemetry et les spans personnalisées

Introduction

Dans les architectures micro‑services basées sur Spring Boot, le tracing distribué est devenu indispensable pour détecter rapidement les défaillances. Pourtant, la plupart des implémentations se limitent à des spans génériques, ce qui complique la localisation précise des incidents. En enrichissant ces spans avec des tags métier et en adoptant OpenTelemetry, les équipes SRE peuvent réduire le MTTR (Mean Time To Recovery) de plusieurs dizaines de pourcents. Cet article propose une plongée approfondie dans le concept clé des spans personnalisées, en illustrant comment les concevoir, les instrumenter et les exploiter efficacement.

1. Comprendre le rôle des spans dans le tracing distribué

1.1 Qu’est‑ce qu’un span ?

Un span représente une opération unique (appel HTTP, requête DB, traitement interne) et possède un identifiant unique, un timestamp de début et de fin, ainsi que des métadonnées appelées attributes ou tags. Dans un système distribué, plusieurs spans s’enchaînent pour former un trace, qui décrit le parcours complet d’une requête à travers les services.

1.2 Limites des spans génériques

Absence de contexte métier : les tags standards (http.method, db.statement) ne renseignent pas sur la logique métier.
Difficulté d’agrégation : sans informations communes, les dashboards peinent à regrouper les incidents par fonction ou par entité métier.
MTTR élevé : les ingénieurs passent plus de temps à filtrer les logs pour identifier la cause racine.

Enrichir les spans avec des informations métier crée un fil conducteur entre le code et la surveillance, facilitant ainsi le diagnostic.

2. Concevoir des spans personnalisées avec OpenTelemetry

2.1 Principes de conception

Pertinence : chaque tag doit apporter une valeur ajoutée pour le diagnostic.
Stabilité : les clés de tags doivent rester identiques entre les versions du service.
Granularité contrôlée : éviter les tags trop détaillés qui gonflent le volume de données.

2.2 Exemple de modèle de tags métier

service.name : nom du micro‑service (ex. order-service).
operation.type : type d’opération métier (ex. checkout, payment).
customer.id : identifiant du client (hashé pour conformité RGPD).
order.id : identifiant de la commande concernée.
error.code : code d’erreur métier lorsqu’une exception est levée.

2.3 Implémentation dans Spring Boot

import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.trace.Tracer;
import org.springframework.stereotype.Component;

@Component
public class TracingHelper {
    private final Tracer tracer = GlobalOpenTelemetry.getTracer("lescopr-tracing");

    public Span startSpan(String operation, String service, String orderId, String customerId) {
        Span span = tracer.spanBuilder(operation)
                .setAttribute("service.name", service)
                .setAttribute("order.id", orderId)
                .setAttribute("customer.id", customerId)
                .startSpan();
        return span;
    }
}

Dans un contrôleur :

@GetMapping("/checkout/{orderId}")
public ResponseEntity<Void> checkout(@PathVariable String orderId, @RequestHeader("X-Customer-Id") String custId) {
    Span span = tracingHelper.startSpan("checkout", "order-service", orderId, custId);
    try {
        // logique métier
    } catch (Exception e) {
        span.setAttribute("error.code", e.getClass().getSimpleName());
        throw e;
    } finally {
        span.end();
    }
    return ResponseEntity.ok().build();
}

3. Collecte, agrégation et visualisation des spans enrichies

3.1 Pipeline de collecte OpenTelemetry

Exportateur : les agents OpenTelemetry envoient les spans vers un collector (ex. otel-collector).
Backend : le collector transmet les données à un backend compatible (ex. Jaeger, Prometheus + Grafana, ou la plateforme Lescopr).
Retention : configurez une politique de rétention adaptée (ex. 30 jours) pour éviter la saturation du stockage.

3.2 Tableaux de bord pertinents

Vue par service : regroupe les spans par service.name et montre le temps moyen de chaque opération.
Analyse d’erreur : filtre les spans contenant error.code pour identifier les points de friction.
Chemin de requête : trace le parcours complet d’une transaction (order.id) à travers les services.

3.3 Checklist d’optimisation

Limiter le nombre de tags : ne dépasser 5‑7 tags par span.
Hashage des données sensibles : appliquer SHA‑256 sur customer.id pour rester conforme RGPD.
Échantillonnage dynamique : augmenter le taux d’échantillonnage lors d’incidents et le réduire en période stable.

4. Impact mesurable sur le MTTR

4.1 Méthodologie de mesure

Définir un incident type : par exemple, un délai de réponse > 2 s sur le endpoint /checkout.
Chronométrer le temps de détection : depuis le déclenchement jusqu’à la première alerte.
Chronométrer le temps de résolution : depuis l’alerte jusqu’à la restauration du SLA.
Comparer : exécuter le même scénario avec et sans spans personnalisées.

4.2 Résultats attendus

Configuration	Temps moyen de détection (s)	Temps moyen de résolution (s)
Spans génériques	45	120
Spans enrichies	30	80

Ces chiffres illustrent une réduction du MTTR d’environ 33 % grâce à la visibilité accrue offerte par les tags métier.

5. Bonnes pratiques et pièges à éviter

Ne pas sur‑charger les spans : chaque tag supplémentaire augmente le volume de données et le coût de stockage.
Synchroniser les conventions de nommage : tous les services doivent adopter les mêmes clés (service.name, operation.type, …).
Surveiller la latence du collector : un collector saturé peut introduire un overhead de plusieurs millisecondes, impactant les SLO.
Tester en environnement de pré‑production : validez le schéma de tags avant le déploiement en production.

Conclusion

En enrichissant les spans OpenTelemetry avec des tags métier pertinents, les équipes Spring Boot gagnent en clarté opérationnelle et réduisent significativement le MTTR. Cette approche repose sur un équilibre entre granularité des métadonnées et performance du pipeline de collecte. Pour aller plus loin, la documentation Lescopr détaille la mise en place pas à pas.

Spring Boot : optimiser le tracing distribué avec OpenTelemetry et les spans personnalisées