Cloudflare Traces : suivez vos requêtes HTTP

Introduction

Une requête HTTP traverse parfois une dizaine de couches avant d'atteindre votre serveur d'origine. Règles de pare-feu, cache, Workers, load balancing : chaque étape peut ralentir ou bloquer la réponse. Sans outil de traçage, identifier le maillon faible relève de la devinette.

Cloudflare a annoncé en bêta ouverte une fonctionnalité nommée Cloudflare Traces. Son rôle : rendre visible le parcours complet d'une requête à travers leur infrastructure. Fini l'angle mort. Chaque décision prise par la plateforme, du déclenchement d'une règle WAF à la mise en cache, devient lisible et analysable.

Cet article détaille les fonctionnalités de Cloudflare Traces, la configuration pas à pas, les options de personnalisation, l'exportation des données et les erreurs fréquentes à éviter.

Tracer les requêtes de bout en bout

Cloudflare Traces permet de suivre le parcours complet d'une requête à travers la plateforme Cloudflare. Chaque étape franchie génère un span, c'est-à-dire un segment temporel qui décrit une opération précise : évaluation d'une règle de sécurité, recherche en cache, exécution d'un Worker, etc.

Le mécanisme repose sur OpenTelemetry, une norme ouverte de collecte de données de télémétrie. Concrètement, cela signifie que les traces produites par Cloudflare respectent un format standard, compatible avec la plupart des plateformes d'observabilité du marché.

Le résultat est direct. Vous obtenez une chronologie ordonnée de toutes les opérations subies par la requête, avec pour chaque span son nom, sa durée et ses attributs. Vous pouvez ainsi repérer une règle de sécurité trop lente, un cache ignoré ou un Worker qui consomme trop de temps.

Visibilité et contrôle précis

Le tableau de bord Cloudflare affiche les traces sous forme de chronologies détaillées. Vous voyez chaque span, son horodatage et ses métadonnées. Voici un exemple de structure JSON représentant une trace simple :

{
  "trace_id": "abc123",
  "spans": [
    {
      "name": "http_request",
      "start_time": "2026-10-02T12:00:00Z",
      "duration": 50,
      "attributes": {
        "http.method": "GET",
        "http.url": "https://example.com"
      }
    }
  ]
}

Ce document JSON décrit une trace contenant un seul span. Le champ trace_id identifie la trace. Le span http_request enregistre une requête GET vers https://example.com, démarrée à midi, d'une durée de 50 millisecondes.

Lire une chronologie de spans

Une trace contient souvent plusieurs spans imbriqués. Chaque span peut avoir un span parent, formant un arbre. Ce principe est simple. Un span racine représente la requête entrante. Ses enfants représentent les sous-opérations : évaluation WAF, recherche cache, appel au serveur d'origine.

Cette structure arborescente permet de localiser le goulot d'étranglement. Si un span enfant dure 200 ms sur une requête totale de 220 ms, la cause du ralentissement est identifiée sans ambiguïté.

Configuration et personnalisation

Activer Cloudflare Traces ne demande ni plugin ni bibliothèque externe. C'est rapide. Une fois la fonctionnalité activée depuis le tableau de bord, Cloudflare génère des spans pour chaque requête entrante, sans modification de votre code applicatif.

Vous contrôlez la quantité de données collectées grâce au taux d'échantillonnage de base. Ce taux définit le pourcentage de requêtes tracées. Un taux de 0.01 signifie qu'une requête sur cent sera tracée, ce qui réduit le volume de données et les coûts de stockage associés.

Règles de trace

Les règles de trace modifient le comportement du traçage pour des requêtes ciblées. Par exemple, si un utilisateur signale un problème, vous pouvez tracer 100 % de ses requêtes en ciblant son User-Agent :

# Règle pour tracer toutes les requêtes d'un client spécifique
rules:
  - name: "Trace Specific Client"
    conditions:
      - header: "User-Agent"
        value: "SpecificClient"
    actions:
      - set_sampling_rate: 1.0

Le champ conditions filtre les requêtes selon un en-tête HTTP. Le champ actions applique un taux d'échantillonnage de 1.0, soit 100 %. Cette règle reste active tant que vous ne la désactivez pas.

Exemples de filtrage avancé

Vous pouvez aussi filtrer par chemin d'URL pour ne tracer que les requêtes vers votre API :

# Tracer uniquement les requêtes vers /api/
rules:
  - name: "Trace API requests"
    conditions:
      - path_prefix: "/api/"
    actions:
      - set_sampling_rate: 0.5

Ici, la moitié des requêtes commençant par /api/ seront tracées. Ce filtrage évite de noyer vos données avec des traces de ressources statiques (images, CSS, JavaScript) qui ne présentent pas d'intérêt pour le diagnostic.

Propagation du contexte de trace

Le traçage distribué repose sur un principe clé : chaque service traversé par la requête doit transmettre un identifiant de trace au service suivant. Sans cela, la chaîne est rompue.

Cloudflare Traces utilise l'en-tête traceparent, défini par le W3C Trace Context. Cet en-tête contient l'identifiant de la trace et l'identifiant du span parent. Quand Cloudflare transmet la requête à votre serveur d'origine, il inclut cet en-tête. Votre application peut alors le lire et créer ses propres spans rattachés à la même trace.

"La propagation du contexte de trace permet une vue unifiée et continue de la requête à travers tous les services de votre infrastructure."

Fonctionnement de l'en-tête traceparent

L'en-tête traceparent suit un format précis :

# Format de l'en-tête traceparent (W3C Trace Context)
# version-trace_id-parent_id-trace_flags
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

Le premier segment (00) indique la version du format. Le deuxième est l'identifiant de trace sur 16 octets. Le troisième est l'identifiant du span parent sur 8 octets. Le dernier (01) active l'enregistrement de la trace. Ce format standardisé garantit la compatibilité entre Cloudflare et vos outils internes.

Exportation vers des plateformes d'observabilité

Collecter des traces ne suffit pas. Il faut les analyser. Cloudflare Traces permet d'exporter les données vers toute plateforme compatible avec le protocole OTLP (OpenTelemetry Protocol). Vous centralisez ainsi vos traces Cloudflare avec celles de vos autres services dans un seul outil.

L'exportation se configure depuis le tableau de bord. Vous renseignez l'endpoint OTLP de votre plateforme d'observabilité, et Cloudflare y envoie les traces collectées.

Comparatif des options d'observabilité

Voici un aperçu des principales différences entre les approches de traçage disponibles :

Critère	Cloudflare Traces (natif)	Agent OpenTelemetry externe	Logs Cloudflare classiques
Installation	Aucune - activation dans le tableau de bord	Déploiement d'un collecteur sur vos serveurs	Aucune - activé par défaut
Granularité	Span par span (chaque opération)	Span par span (côté serveur)	Par requête (une ligne par requête)
Format de données	OpenTelemetry (OTLP)	OpenTelemetry (OTLP)	JSON propriétaire
Couverture Cloudflare	Complète (WAF, cache, Workers, DNS)	Aucune (côté serveur uniquement)	Partielle (métadonnées de requête)
Traçage distribué	Oui, via traceparent W3C	Oui, via traceparent W3C	Non
Personnalisation	Règles de trace, taux d'échantillonnage	Configuration du collecteur	Filtres de logs limités

Ce tableau montre que Cloudflare Traces comble un vide. Les logs classiques ne descendent pas au niveau du span. Un agent externe ne voit pas ce qui se passe à l'intérieur de Cloudflare. Traces combine les deux perspectives.

Pièges et erreurs courantes

Plusieurs erreurs reviennent souvent lors de la mise en place du traçage. Les voici.

Taux d'échantillonnage trop élevé : tracer 100 % des requêtes sur un site à fort trafic génère un volume massif de données. Les coûts de stockage et de transfert augmentent vite. Commencez par un taux bas (0.01 ou 0.05) et augmentez-le uniquement pour des requêtes ciblées via les règles de trace.
Aucune exportation configurée : sans exportation vers une plateforme d'observabilité, les traces restent consultables uniquement dans le tableau de bord Cloudflare. Vous perdez la possibilité de corréler ces données avec les traces de vos propres services.
Règles de trace obsolètes : une règle créée pour diagnostiquer un problème ponctuel peut rester active des mois après sa résolution. Elle continue à collecter des données inutiles. Revoyez vos règles après chaque incident résolu.
Propagation du contexte ignorée côté serveur : si votre application ne lit pas l'en-tête traceparent, la trace s'arrête à Cloudflare. Le traçage distribué perd tout son intérêt. Vérifiez que votre framework ou votre SDK OpenTelemetry est configuré pour extraire cet en-tête.
Confusion entre traces et logs : les traces montrent la chronologie et la durée des opérations. Les logs contiennent des messages textuels. Ce sont deux outils complémentaires, pas interchangeables.

Conclusion

Cloudflare Traces rend visible ce qui était opaque : le parcours d'une requête à travers l'infrastructure Cloudflare, span par span. Voici les points à retenir.

Cloudflare Traces offre une visibilité complète sur chaque opération subie par une requête.
L'activation ne demande ni plugin ni modification de code.
Le format OpenTelemetry garantit la compatibilité avec les outils d'observabilité existants.
Les règles de trace permettent un traçage ciblé selon les en-têtes ou les chemins d'URL.
L'en-tête traceparent du W3C relie les traces Cloudflare à celles de vos propres services.
L'exportation via OTLP centralise vos données de télémétrie dans une plateforme unique.
Gérez le taux d'échantillonnage avec soin pour éviter une surcharge de données.

Commencez par activer Cloudflare Traces sur une zone de test, configurez un taux d'échantillonnage bas, puis affinez vos règles de trace selon vos besoins de diagnostic.

Sources

Introducing Cloudflare Traces: follow requests through our entire platform (Cloudflare, le 2026-10-02)

#Performance #Cloudflare #tracing #observability #security

Découvrez Cloudflare Traces : suivez vos requêtes