Le profilage continu en production : des profils par échantillonnage permanents et les questions auxquelles ils répondent

Ce que c'est

La documentation de Parca définit le profilage continu comme la production systématique de profils de programmes (CPU, mémoire, E/S et autres), puis leur collecte, leur stockage et leur interrogation au fil du temps. L'unité stockée est une série de profils identifiée par un type de profil et des étiquettes clé/valeur, interrogeable avec un langage de sélection par étiquettes. Parca explique pourquoi cela peut fonctionner en permanence : l'outil utilise le profilage par échantillonnage, qui relève une trace de pile à intervalles plutôt que d'instrumenter chaque appel, ce qui entraîne un surcoût suffisamment faible pour rester activé en permanence en production. Grafana Pyroscope se décrit de la même façon, comme un système d'agrégation de profils continus qui met les profils en corrélation avec les métriques, les journaux et les traces.

Les profils proviennent de trois types de sources : les points d'accès des environnements d'exécution (le paquet net/http/pprof de Go enregistre sous /debug/pprof/ des gestionnaires qui fournissent des profils CPU sur le nombre de secondes demandé, ainsi que des profils de tas, de goroutines, de blocage et de mutex), les SDK qui envoient des profils depuis l'intérieur du processus, et les agents eBPF qui profilent tous les processus d'un hôte sans modification de l'application.

Pourquoi c'est important

Un profil ponctuel répond à la question « à quoi le temps est-il consacré maintenant ? ». Un historique continu de profils répond aux questions qui se posent en exploitation : ce qui a changé entre la version déployée hier et celle d'aujourd'hui, quelle fonction consomme le plus de CPU au total sur toutes les instances, pourquoi la consommation mémoire augmente au fil d'une semaine, et ce que faisait le processus à 03:12 quand la latence a augmenté. Ces questions ne peuvent pas être résolues en recueillant un profil après coup.

Comment l'appliquer

• Commencer par les profils CPU et d'allocation pour les services qui contribuent le plus aux dépenses ou à la latence ; ajouter des profils de mutex et de blocage en cas de suspicion de contention (Go ne les fournit qu'après appel à runtime.SetBlockProfileRate ou runtime.SetMutexProfileFraction).
• Étiqueter les profils par service, version et instance, pour pouvoir comparer deux versions en calculant la différence entre deux flame graphs.
• Faire écouter les points d'accès de profilage des environnements d'exécution sur localhost ou sur un port privé ; l'exemple Go les expose sur localhost:6060, et un collecteur y accède via le réseau privé.
• Conserver les profils bruts peu de temps et s'appuyer sur les séries agrégées pour les tendances.
• Vérifier le surcoût sur une copie en préproduction soumise à une charge réaliste avant d'activer le profilage sur tout le parc, et consigner la mesure avec le déploiement.
• Fournir un lien depuis la fenêtre temporelle d'une alerte de latence vers le profil de cette même fenêtre.

Pièges

Les points d'accès de profilage exposés publiquement divulguent la structure du code et permettent à n'importe qui de déclencher une collecte de profils coûteuse. Les binaires dépourvus de symboles ou l'absence de pointeurs de trame produisent des piles sans noms. Les profileurs par échantillonnage sous-représentent les processus de courte durée et les événements rares isolés ; ils montrent à quoi le temps est consacré en moyenne, pas pourquoi une requête particulière a été lente, ce qui relève du traçage.