Les profils, le quatrième signal

1. Pourquoi un quatrième signal #

Ce que les traces ne disent pas.

Le profilage continu #

Une trace montre qu'un span a duré 2,3 secondes, mais pas quelle ligne de code a consommé ce temps. Le profilage échantillonne régulièrement (par exemple 20 à 100 fois par seconde) les piles d'appels des processus pour mesurer où partent le CPU, la mémoire allouée, les verrous ou les entrées-sorties. Le profilage continu le fait en permanence en production, avec un surcoût de l'ordre de 1 à 2 %.

Lire un flame graph #

• L'axe horizontal n'est pas le temps : c'est la part des échantillons, triée alphabétiquement.
• Chaque niveau est un appel de fonction ; les enfants sont au-dessus de leur parent (ou en dessous, selon l'outil).
• Une barre large sans enfants (« plateau ») est une fonction qui consomme elle-même : c'est la cible d'optimisation.

2. Les profils dans OpenTelemetry #

Un signal en cours de standardisation.

Ce qui existe #

Erreur Courante : Le signal profile n'est pas encore stable : formats et options peuvent changer d'une version à l'autre. En production, utilisez les intégrations éprouvées de votre backend et suivez l'évolution d'OTLP Profiles.

Activer les profils dans un Collector récent #

# feature gate à passer au démarrage du Collector (nom susceptible d'évoluer)
otelcol-contrib --config config.yaml --feature-gates=service.profilesSupport

# config.yaml : un pipeline de profils comme les autres
service:
  pipelines:
    profiles:
      receivers: [otlp]
      exporters: [otlp/pyroscope]

3. Relier profils et traces #

Le vrai gain : la corrélation.

Span profiles #

Le profileur étiquette chaque échantillon avec le span_id actif. Il devient possible d'afficher le profil d'une requête lente précise plutôt que celui de tout le processus. Avec Pyroscope, un span processor ajoute ce lien :

import pyroscope
from pyroscope.otel import PyroscopeSpanProcessor

pyroscope.configure(application_name="checkout",            # identique à service.name
                    server_address="http://pyroscope:4040",
                    tags={"env": "production"})
provider.add_span_processor(PyroscopeSpanProcessor())       # étiquette les profils avec le span_id

Les cas d'usage #

• Expliquer une régression de latence entre deux versions (comparaison de flame graphs).
• Réduire la facture cloud : 10 % de CPU en moins sur 200 instances.
• Trouver une fuite mémoire avant le redémarrage forcé (OOM).
• Comprendre un span lent sans ajouter de spans manuels partout.

4. Mettre en place #

Commencer simplement.

Démarche #

1. Choisir un backend de profils (Pyroscope est intégré à la pile Grafana).
2. Profiler sans instrumentation avec un agent eBPF (profileur OpenTelemetry, Alloy pyroscope.ebpf) pour obtenir une vue de toute la flotte.
3. Ajouter les SDK de profilage aux services critiques pour les profils mémoire et la corrélation span-profil.
4. Utiliser les mêmes service.name et attributs de ressource que les autres signaux.
5. Suivre la stabilisation d'OTLP Profiles pour unifier la collecte dans le Collector.

À savoir : La formation Grafana Pyroscope détaille l'installation, les SDK et l'analyse des profils.