RousselTMLEARNING

Observabilité

Déployer et exploiter Pyroscope sur Kubernetes

Installer Pyroscope avec Helm, collecter les profils du cluster avec Alloy (annotations et eBPF), dimensionner, sécuriser et superviser Pyroscope en production.

1. Installer avec Helm #

Monolithique ou microservices.

Commandes #

helm repo add grafana https://grafana.github.io/helm-charts && helm repo update
kubectl create namespace pyroscope
helm install pyroscope grafana/pyroscope -n pyroscope            # monolithique
# Microservices : récupérer values-micro-services.yaml dans le dépôt du chart
helm install pyroscope grafana/pyroscope -n pyroscope -f values-micro-services.yaml

Comme Mimir, Pyroscope est multi-tenant (en-tête X-Scope-OrgID) ; le paramètre multitenancy_enabled l'active.

2. Collecter les profils du cluster #

Annotations et eBPF.

Par annotations #

La convention profiles.grafana.com/* permet aux équipes d'activer la collecte pprof de leurs pods sans toucher à Alloy :

metadata:
  annotations:
    profiles.grafana.com/cpu.scrape: "true"
    profiles.grafana.com/cpu.port: "6060"
    profiles.grafana.com/memory.scrape: "true"
    profiles.grafana.com/memory.port: "6060" 

La configuration Alloy de référence (fournie par Grafana) découvre les pods, lit ces annotations et crée un pyroscope.scrape par type de profil.

eBPF en DaemonSet #

# values.yaml du chart grafana/alloy (extrait)
alloy:
  securityContext: { privileged: true, runAsUser: 0 }
controller:
  type: daemonset
  hostPID: true
discovery.kubernetes "pods" { role = "pod" }
discovery.relabel "local_pods" {
  targets = discovery.kubernetes.pods.targets
  rule {   // ne garder que les pods du nœud courant
    source_labels = ["__meta_kubernetes_pod_node_name"]
    regex         = sys.env("HOSTNAME")
    action        = "keep"
  }
  rule {
    source_labels = ["__meta_kubernetes_namespace", "__meta_kubernetes_pod_container_name"]
    separator     = "/"
    target_label  = "service_name"
  }
}
pyroscope.ebpf "cluster" {
  targets    = discovery.relabel.local_pods.output
  forward_to = [pyroscope.write.default.receiver]
}

3. Exploiter #

Coût, limites, supervision.

Points d'attention #

SujetRecommandation
VolumeLe volume dépend surtout du nombre de séries (service × labels) et de la diversité des piles ; commencez par CPU et mémoire
Rétention7 à 30 jours suffisent souvent : les profils servent au diagnostic, rarement à l'historique long
Limitesingestion_rate_mb, max_label_names_per_series par tenant
SupervisionPyroscope expose /metrics (Prometheus) : surveillez les échantillons rejetés et la latence des requêtes
SécuritéLes noms de fonctions révèlent l'architecture du code : protégez l'accès comme pour les logs

Articles liés

Le profiling continu avec Grafana Pyroscope : pourquoi et comment

Le quatrième signal de l'observabilité : ce qu'est le profiling continu, les types de profils (CPU, mémoire, …

Architecture et déploiement de Grafana Pyroscope

Les composants de Pyroscope (distributor, ingester, querier, store-gateway, compactor), le stockage objet, le…

Instrumenter ses applications pour Pyroscope : SDK, Alloy et eBPF

Envoyer des profils à Pyroscope depuis Go, Java, Python et Node.js avec les SDK, collecter les points pprof a…

Pour aller plus loin