Échantillonner les traces sans perdre l'incident

Soit un service à 200 requêtes par seconde avec 0,1 % d'erreurs, soit une erreur toutes les cinq secondes. On échantillonne 1 % des traces, décidé à l'entrée de la requête. On conserve donc une trace d'erreur toutes les 500 secondes en moyenne, environ sept par heure. Pour un incident qui touche un seul tenant représentant 2 % du trafic, il faut compter une trace utile toutes les sept heures.

L'échantillonnage en tête garde un échantillon fidèle du trafic normal, c'est-à-dire de ce que personne n'a besoin de regarder. Les requêtes intéressantes, lentes ou en échec, sont rares par définition, et un tirage uniforme les jette dans la même proportion que les autres. Le tail sampling promet de corriger cela. Il le fait, à un prix que les schémas d'architecture ne montrent pas.

Décider à l'entrée ou à la fin de la trace

La différence tient à l'instant de la décision.

Échantillonnage en tête (head)
  requête arrive -> tirage au sort -> décision propagée dans l'en-tête
                                   -> chaque service obéit, rien d'autre à faire

Échantillonnage en queue (tail)
  requête arrive -> tous les spans sont émis par tous les services
                 -> un collecteur les regroupe par trace
                 -> attend que la trace soit terminée
                 -> décide en connaissant la durée, le statut, les attributs

En tête, la décision est prise sans information, puisqu'on ne sait pas encore si la requête échouera. En contrepartie, elle ne coûte rien. Les services non retenus n'enregistrent pas les spans, rien ne transite, et la décision voyage avec le contexte de trace, si bien que tous les services d'une même requête sont d'accord.

En queue, la décision est informée : on garde toutes les erreurs, toutes les traces au-delà de deux secondes, tout ce qui concerne tel tenant, et 1 % du reste. Mais pour décider après coup, il faut avoir tout produit, tout transporté et tout gardé en mémoire jusqu'à la décision.

Mémoire, routage et délai du tail sampling

La mémoire tampon. Le collecteur garde chaque trace pendant un délai d'attente avant de trancher. À 200 requêtes par seconde, 25 spans par trace, 1 Ko par span et 30 secondes d'attente, on obtient 200 × 25 × 30 = 150 000 spans en mémoire, soit 150 Mo de données brutes, et nettement plus une fois comptées les structures qui les portent. C'est supportable. À 5 000 requêtes par seconde, le même calcul donne près de 4 Go, sur un composant qui devient critique.