Traçage distribué et télémétrie

1. Introduction

Dans le monde moderne des architectures orientées services (SOA), des microservices et des solutions cloud, une requête utilisateur peut « traverser » des dizaines de services avant de renvoyer un résultat. Chaque nœud de ce « trajet » écrit ses logs, mais comment savoir qu'une erreur ou une latence à un endroit est bien liée à cette requête particulière ?

Le traçage distribué est comme un système de tracking pour un colis en logistique : vous voyez par quels points votre colis est passé, où il a été retardé et où il y a eu un incident. En programmation, c'est la possibilité de suivre le « voyage » d'une requête à travers tous les services, de comprendre combien de temps elle a passé à chaque étape et où s'est produite une erreur ou un ralentissement.

Pourquoi avoir besoin du traçage ?

• Localisation des erreurs : Si quelque chose ne va pas, vous voyez immédiatement où exactement : dans quel service, à quelle étape et même quelle méthode précise a été appelée.
• Recherche des « goulots d'étranglement » : Le traçage montrera où vos services « ralentissent » et à quelle étape le plus de temps est perdu.
• Analyse des scénarios utilisateurs : On peut comprendre comment les clients utilisent réellement vos services et où il faut prioriser les optimisations.

Comment ça marche ?

Chaque requête reçoit un identifiant unique de trace (TraceId), qui « voyage » avec elle à travers tout l'ensemble de services : du frontend au backend, des API à la base de données et retour. À chaque étape sont créés des « spans », qui enregistrent le temps d'exécution d'une opération et des événements supplémentaires. Au final vous obtenez un arbre (ou graphe) d'opérations avec leurs durées et leurs relations.

Entités clés et termes du traçage distribué

2. OpenTelemetry : standard ouvert pour l'observabilité

Brève présentation d'OpenTelemetry

OpenTelemetry est un standard ouvert et un ensemble d'outils pour collecter la télémétrie (traces, metrics, logs) depuis différentes applications. Il est soutenu par la Cloud Native Computing Foundation (CNCF) et est devenu le standard de facto dans le monde des applications cloud et distribuées.

OpenTelemetry (abrégé OTel) sait :

• Collecter et envoyer automatiquement des traces, metrics et logs ;
• Fonctionner avec les principaux langages (y compris C#, Java, Python et d'autres) ;
• Transmettre les données vers des systèmes d'observabilité — Jaeger, Zipkin, Azure Monitor, Grafana, etc. ;
• S'étendre via des plugins et se configurer pour n'importe quel stack.

Pourquoi OpenTelemetry ?

• Indépendance vis-à-vis du vendor : OTel est un standard, pas le produit d'une seule entreprise.
• Compatibilité : Supporte les principaux formats de trace, s'intègre facilement aux systèmes APM.
• Automatisation : La plupart du boulot (par ex. le traçage des requêtes HTTP) peut être fait automatiquement, avec un minimum de configuration.
• Scalabilité : OTel marche bien aussi bien dans des petits que dans des très grands systèmes.

Architecture d'OpenTelemetry, simplement

Pour ne pas se perdre dans les « couches », visualisons le flux typique des données de trace dans OTel.

flowchart LR
    subgraph Application
        A[OpenTelemetry SDK]
    end
    A -->|Traces, metrics, logs| B[OpenTelemetry Collector]
    B -->|Export vers| C[Jaeger/Zipkin/Grafana/Azure/Application Insights etc.]

1. OpenTelemetry SDK : S'intègre directement dans votre application (par ex. via des packages NuGet pour .NET).
2. OTel Collector : Service concentrateur séparé (souvent déployé en conteneur Docker), qui reçoit les données de trace de toutes vos applications et les exporte où vous l'indiquez.
3. Frontend d'observabilité : Le système où vous voyez des jolis graphiques, arbres, filtrez et analysez les traces.

3. Démarrage rapide du traçage en C#/.NET

Ajoutons du traçage distribué basique à notre application pédagogique. Les étapes principales sont assez simples.

Installer les packages NuGet

dotnet add package OpenTelemetry
dotnet add package OpenTelemetry.Exporter.Console

OpenTelemetry — l'implémentation SDK de base ;
OpenTelemetry.Exporter.Console — exporte les traces vers la console (peut être remplacé par Jaeger, Zipkin, etc.).

Configuration minimale du traçage

Dans le fichier Program.cs (pour une application console) :

using OpenTelemetry;
using OpenTelemetry.Trace;

class Program
{
    static void Main(string[] args)
    {
        // On configure le traçage
        using var tracerProvider = Sdk.CreateTracerProviderBuilder()
            .AddSource("DemoApp") // On indique le nom de la source
            .AddConsoleExporter() // On exporte les traces vers la console
            .Build();

        var source = new System.Diagnostics.ActivitySource("DemoApp");

        // On démarre une nouvelle trace (span racine)
        using (var activity = source.StartActivity("Operation principale"))
        {
            DoWork();
        }
    }

    static void DoWork()
    {
        // Un peu de logique applicative...
        System.Threading.Thread.Sleep(300);
    }
}

Ce qui se passe ici :

• On crée le provider de traçage, on enregistre la source ("DemoApp") et on ajoute l'exporteur console AddConsoleExporter().
• On lance une nouvelle « activity » (span) via ActivitySource au démarrage du programme.
• À l'intérieur on effectue le travail utile qu'on veut tracer.

Résultat :

Activity.Id:          0b69e3e97ca5f14d
Activity.Operation:   Operation principale
Duration: 00:00:00.3001082
...

Traçage automatique des HTTP et bases de données

OpenTelemetry supporte l'instrumentation — le traçage automatique des bibliothèques courantes. Par exemple les appels via HttpClient et les requêtes vers la BD (ADO.NET) peuvent être collectés sans changer votre code métier.

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddHttpClientInstrumentation() // Requêtes HTTP
    .AddSqlClientInstrumentation()  // Requêtes SQL (si vous utilisez)
    .AddConsoleExporter()
    .Build();

Maintenant tous vos appels via HttpClient et les opérations SQL apparaîtront automatiquement dans les traces.

4. Visualisation des traces

La sortie console n'est qu'un premier pas. Pour en tirer un réel bénéfice, mieux vaut utiliser un frontend de visualisation.

Jaeger

Jaeger est l'un des systèmes open-source les plus populaires pour visualiser les traces.

1. Déployez Jaeger (par exemple via Docker).
2. À la place de AddConsoleExporter() utilisez :

   .AddJaegerExporter(options =>
   {
       options.AgentHost = "localhost";
       options.AgentPort = 6831;
   })
   

3. Maintenant toutes les traces apparaîtront dans l'UI Jaeger — vous pouvez filtrer par TraceId, regarder les diagrammes temporels détaillés.

Instructions complètes : OpenTelemetry Jaeger Exporter pour .NET

5. Subtilités utiles

Comparaison des approches

Sans OTel vous copiez manuellement le TraceId dans les logs, en espérant ne pas oublier de le transmettre et vous galérez à analyser les incidents. Avec OTel toute la chaîne se construit automatiquement et se visualise en un clic.

Exemple d'architecture

[Client web] --> [Service API] --> [Service d'auth] --> [Service base de données]

Quand l'utilisateur clique sur un bouton, la requête traverse tous ces services. Avec OTel vous pouvez « tirer le fil » (TraceId) à travers chacun d'eux, en joignant automatiquement la logique en une seule trace.

• Dans chaque service le SDK OTel reconnaît automatiquement le TraceId depuis les en-têtes HTTP et poursuit la chaîne.
• En résultat, vous pouvez ouvrir une trace unique — et voir où les millisecondes ont été consommées, ce qui s'est passé et où l'erreur est survenue.

Usage en projets réels et lors des entretiens

• Systèmes microservices et applications distribuées (fintech, marketplaces, SaaS, etc.).
• DevOps/SRE : localisation rapide des problèmes.
• Amélioration des SLA et de la réactivité des services.
• Profiling et optimisation.
• Aux entretiens — démontrer une pratique d'ingénierie mature.

6. Erreurs typiques et particularités d'implémentation

Oublié de transmettre le TraceContext. Si le TraceId n'est pas transmis entre services (par exemple on a oublié de passer les bons en-têtes HTTP), les traces seront cassées — elles apparaîtront comme des points isolés, et toute la valeur de l'observabilité disparaîtra.

Code non instrumenté. Si votre bibliothèque ou framework ne supporte pas l'instrumentation, certaines opérations manqueront dans la trace (mais on peut toujours créer des spans manuellement via ActivitySource et StartActivity()).

Saturation de données. Collecter des traces pour chaque requête coûte cher, surtout en gros prod. En général on active le traçage que pour une partie des requêtes (sample rate) ou sur déclencheur (erreurs, requêtes lentes).

Performance. L'intégration d'OTel a un impact minimal si on utilise l'export asynchrone, mais sous très lourd trafic surveillez l'overhead et ajustez le taux d'échantillonnage.