[Artículo] Los perfiles, la cuarta señal

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 %.

Type de profil	Répond à
CPU	quelles fonctions consomment le processeur ?
Allocation mémoire	qui alloue le plus (pression sur le ramasse-miettes) ?
Mémoire utilisée (heap)	qui retient la mémoire (fuite) ?
Verrous / mutex	où les threads attendent-ils ?
Wall clock	où le temps réel passe-t-il, attentes comprises ?

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 #

Brique	État (à vérifier sur opentelemetry.io)
Modèle de données et OTLP	signal `profiles` ajouté à OTLP, inspiré de pprof, avec déduplication des piles et lien vers trace_id/span_id ; statut développement/alpha
Profileur eBPF	profileur système donné par Elastic au projet en 2024 : profile tous les processus d'un hôte sans instrumentation (Go, Java, Python, Node.js, .NET, Rust, C/C++…)
Collector	receivers et exportateurs de profils derrière une option d'activation (feature gate) ; distribution du profileur eBPF sous forme de Collector
SDK de langage	pas encore d'API Profiles stable : on utilise des agents ou les SDK des outils (Pyroscope, async-profiler…)
Backends	Grafana Pyroscope, Elastic Universal Profiling, Datadog, Polar Signals… acceptent ou annoncent l'OTLP Profiles

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 #

Du span au profil — Depuis Grafana Tempo, le bouton « Profiles for this span » ouvre le flame graph du span.

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 #

Choisir un backend de profils (Pyroscope est intégré à la pile Grafana).
Profiler sans instrumentation avec un agent eBPF (profileur OpenTelemetry, Alloy pyroscope.ebpf) pour obtenir une vue de toute la flotte.
Ajouter les SDK de profilage aux services critiques pour les profils mémoire et la corrélation span-profil.
Utiliser les mêmes service.name et attributs de ressource que les autres signaux.
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.

Los perfiles, la cuarta señal