1. Le quatrième signal #
Ce que métriques, logs et traces ne disent pas.
Du « quoi » au « quelle ligne de code » #
Les métriques disent qu'un service consomme 4 CPU, les traces disent quel appel est lent, les logs racontent ce qui s'est passé. Aucun ne dit quelle fonction consomme ce CPU ou alloue cette mémoire. C'est le rôle du profiling.
Le profiling continu échantillonne en permanence, en production, la pile d'appels des processus (par exemple 100 fois par seconde) avec un surcoût faible (souvent 1 à 3 % de CPU). On peut ainsi revenir sur un pic d'hier, comparer deux versions ou repérer la fonction qui coûte le plus cher à l'échelle d'un parc.
| Signal | Question | Outil Grafana |
|---|---|---|
| Métriques | Combien ? Est-ce normal ? | Prometheus, Mimir |
| Logs | Que s'est-il passé ? | Loki |
| Traces | Où le temps est-il passé entre services ? | Tempo |
| Profils | Quelle fonction consomme CPU ou mémoire ? | Pyroscope |
À savoir : Pyroscope est né en 2020 comme projet indépendant, racheté par Grafana Labs en 2023 et fusionné avec Grafana Phlare. Il est open source (AGPLv3). OpenTelemetry standardise aussi les profils comme signal à part entière (protocole OTLP profiles, encore en développement).
2. Les types de profils #
CPU, mémoire, verrous, goroutines.
Les principaux types #
| Type | Mesure | Langages |
|---|---|---|
CPU (process_cpu) | Temps CPU passé dans chaque fonction | Tous |
Wall clock (wall) | Temps réel, y compris les attentes | Java, Python, .NET, Ruby |
Allocations (alloc_objects, alloc_space) | Ce qui est alloué (pression sur le GC) | Go, Java, .NET |
Mémoire utilisée (inuse_objects, inuse_space) | Ce qui reste en mémoire (fuites) | Go |
Verrous (mutex, block, lock) | Temps d'attente sur les verrous et canaux | Go, Java, .NET |
| Goroutines | Nombre de goroutines par pile | Go |
Dans Pyroscope, un type de profil est identifié par une chaîne comme process_cpu:cpu:nanoseconds:cpu:nanoseconds (nom:type d'échantillon:unité:type de période:unité).
3. Lire un flame graph #
La visualisation de référence.
Principe #
- Chaque rectangle est une fonction ; ses enfants (en dessous dans Grafana) sont les fonctions qu'elle appelle.
- La largeur est la part des échantillons où cette fonction était dans la pile : plus c'est large, plus elle coûte.
- L'ordre horizontal n'a pas de sens temporel (tri alphabétique ou par taille).
- Le self time est la partie d'une fonction qui n'est couverte par aucun enfant : c'est le code de la fonction elle-même.
Bonne Pratique : Cherchez les « plateaux » : un rectangle large tout en bas d'une pile est une fonction qui travaille réellement. Le tableau « Top table » de Grafana trie les fonctions par self time : c'est souvent le point de départ le plus rapide.
4. Pyroscope dans la stack #
Collecte, stockage, exploration.
Trois façons d'envoyer des profils #
| Mode | Principe | Quand l'utiliser |
|---|---|---|
| SDK (push) | La bibliothèque Pyroscope dans l'application envoie ses profils | Labels métier, span profiles, langages sans pprof |
| Alloy (pull) | Alloy collecte les points pprof exposés (Go, Rust...) | Applications Go déjà instrumentées avec net/http/pprof |
| Alloy eBPF | Alloy profile tous les processus de l'hôte via le noyau | Profiling de tout un parc, sans modifier le code |
