Du clic à la base de données : traces front-end vers back-end avec Faro

1. Le principe #

Le navigateur commence la trace.

Propagation #

TracingInstrumentation crée un span pour chaque requête fetch ou XMLHttpRequest et ajoute l'en-tête W3C traceparent. Si le back-end est instrumenté avec OpenTelemetry (SDK ou Beyla), il continue la même trace.

2. Configurer #

SDK, CORS et back-end.

Côté navigateur #

new TracingInstrumentation({
  instrumentationOptions: {
    // En-tête ajouté aussi pour ces domaines (sinon seulement pour l'origine de la page)
    propagateTraceHeaderCorsUrls: [/https:\/\/api\.example\.org\/.*/],
  },
})

Côté API #

Pour une API sur un autre domaine, le navigateur envoie une requête préliminaire CORS : l'API doit autoriser l'en-tête traceparent.

# nginx devant l'API
add_header Access-Control-Allow-Origin "https://boutique.example.org" always;
add_header Access-Control-Allow-Headers "content-type, traceparent, tracestate" always;

Erreur Courante : Si l'en-tête n'est pas autorisé, le navigateur bloque la requête : déployez la configuration CORS côté API avant d'activer la propagation côté front.

3. Naviguer dans Grafana #

De la lenteur ressentie à la requête SQL.

Parcours #

1. Un LCP dégradé sur la page panier (requête Loki sur les mesures).
2. Les requêtes fetch lentes de cette page (traces Tempo avec service.name du front).
3. La trace complète : le span du navigateur, l'API, puis une requête SQL de 1,8 s.
4. Le profil CPU du service API pendant ce span (voir la formation Pyroscope).

{ resource.service.name = "boutique" && span.http.url =~ ".*/api/panier.*" && duration > 1s }