Bonnes pratiques Grafana Pyroscope : collecte, labels, analyse et coûts

1. Collecte #

Bien démarrer.

Principes #

• Commencer par eBPF sur tout le parc pour une vue CPU globale, puis ajouter les SDK sur les services critiques.
• Toujours définir service_name, env et version.
• Garder les symboles dans les binaires (pas de -ldflags="-s -w" en Go si vous voulez des noms de fonctions lisibles avec eBPF).
• Activer les profils mutex/block en Go avec un taux d'échantillonnage modéré (5 à 10).

2. Analyse #

Une culture du profil.

Habitudes #

• Comparer chaque déploiement à la version précédente (diff par label version).
• Relier traces et profils (span profiles) sur les services orientés latence.
• Placer un panneau flame graph dans le dashboard de chaque service critique.
• Revoir chaque trimestre le top 10 des fonctions qui consomment le plus de CPU sur tout le parc : c'est souvent le meilleur levier de réduction des coûts cloud.

3. Coûts et sécurité #

Garder la maîtrise.

Réglages #

• Rétention courte (7 à 30 jours).
• Labels à faible cardinalité uniquement.
• Limites d'ingestion par tenant.
• Accès restreint : les profils exposent la structure du code.

Bonne Pratique : Le surcoût du profiling continu (1 à 3 % de CPU) est presque toujours remboursé par la première optimisation trouvée.

Schéma de référence et vérification rapide #

Check-list.

Check-list #

1. Pyroscope avec stockage objet et rétention définie
2. Alloy eBPF en DaemonSet sur les nœuds
3. SDK avec labels sur les services critiques
4. Source Tempo configurée avec tracesToProfiles
5. Label version présent pour les comparaisons
6. Pyroscope supervisé via /metrics