Depuis le 1er novembre 2025, Grafana Agent ne reçoit plus aucun correctif, pas même de sécurité. Fin de vie, point final. Les trois variantes (static, flow, operator) sont sorties du support après une période de LTS qui s'est arrêtée le 31 octobre 2025. Si vous faites encore tourner un Agent sur vos hosts, vous collectez des métriques avec un binaire abandonné. Le remplaçant officiel s'appelle Grafana Alloy, et c'est un autre outil.
Alloy est la distribution Grafana de OpenTelemetry Collector. Pas un fork maison, pas un agent propriétaire de plus : une distribution OTel avec des composants Grafana greffés par-dessus, 100 % compatible OTLP. C'est un changement de nature, pas une montée de version, et ça change la façon dont on écrit la config.
Ce qui meurt avec Grafana Agent
Grafana Agent a vécu trois vies. Le mode static, historique, configuré en YAML monolithique. Le mode flow, qui a introduit la syntaxe à composants. Et l'operator Kubernetes, qui pilotait des Agent via des CRD. Les trois sont morts le même jour.
Le piège classique au moment d'un EOL : laisser tourner parce que « ça marche encore ». Ça marche jusqu'au premier CVE sur une dépendance du binaire. Là, plus personne ne patche en amont, et vous vous retrouvez à maintenir vous-même un fork d'un projet mort, ou à migrer dans l'urgence pendant un incident. La règle qu'on applique : un composant en EOL sur le chemin de la télémétrie, c'est un chantier de migration planifié, pas un risque qu'on accepte. La collecte de métriques n'est pas critique tant que tout va bien. Le jour où elle tombe, vous êtes aveugle pendant la panne que vous essayez de diagnostiquer.
Alloy, une distribution de l'OTel Collector
Le cœur d'Alloy, c'est OpenTelemetry Collector. Alloy embarque plus de 120 composants OTel standard et y ajoute des composants Grafana, dont des pipelines Prometheus natifs. Concrètement, vous collectez des métriques au format Prometheus et des signaux OTLP dans le même binaire, sans bricoler deux agents côte à côte.
Le périmètre couvre les quatre signaux. Les métriques par scrape Prometheus et remote_write. Les logs vers Loki. Les traces en OTLP. Et les profils vers Pyroscope. Un seul collecteur pour tout ce qui sort de vos machines. C'est l'argument structurel face à un parc où traînent un node_exporter, un Promtail, un agent de traces et un agent de profiling séparés : Alloy consolide la collecte.
Pour la mécanique du standard sous-jacent et pourquoi l'instrumentation OTel survit aux changements de backend, voir notre décryptage sur OpenTelemetry et la fin du lock-in d'instrumentation.
La syntaxe Alloy : des composants qu'on câble
Là où l'Agent static utilisait du YAML plat, Alloy reprend la syntaxe à composants héritée de River, le langage du mode flow. La logique ressemble à du Terraform ou du HCL : on déclare des blocs de composants, chacun expose des sorties, et on les câble en référençant la sortie de l'un vers l'entrée du suivant. Le pipeline n'est plus une liste de sections, c'est un graphe de dépendances explicite.
En prod, ça donne ça, un scrape Prometheus poussé vers un backend distant :
prometheus.scrape "node" {
targets = [
{"__address__" = "localhost:9100"},
]
forward_to = [prometheus.remote_write.default.receiver]
}
prometheus.remote_write "default" {
endpoint {
url = "https://prometheus.example.com/api/v1/write"
}
}
Le composant scrape envoie vers le receiver exposé par le composant remote_write. La dépendance est lisible dans le code : on voit d'où vient la donnée et où elle va. Sur une config qui empile metrics, logs et traces, ce graphe explicite vaut mieux qu'un YAML de 400 lignes où les relations entre sections restent implicites. Le revers : la courbe d'apprentissage. Une équipe habituée au YAML Prometheus doit réapprendre à penser en composants câblés.
Les outils de conversion font le gros du travail
Personne ne réécrit une config de production à la main. Alloy embarque une commande convert qui prend une config existante et sort l'équivalent en syntaxe Alloy. Trois sources gérées : grafana-agent (depuis le static), prometheus (depuis un prometheus.yml) et otelcol (depuis une config OTel Collector vanilla).
alloy convert --source-format=prometheus \
--output=alloy-config.alloy prometheus.yml
Pour le mode flow, pas besoin de convertir : Alloy utilise le même format de configuration, certaines fonctionnalités ont juste été retirées. Côté operator, les types de moniteurs Kubernetes (PodMonitor, ServiceMonitor, Probe, ScrapeConfig, PodLogs) sont supportés nativement par Alloy, ce qui évite de tout repenser quand on vient d'un déploiement piloté par CRD.
La règle qu'on applique sur ces conversions : le convertisseur produit une base, pas un livrable. On relit la sortie, on vérifie les avertissements qu'il émet, et on teste la collecte en staging avant de basculer la prod. Un convertisseur automatique ne connaît pas vos intentions, juste votre syntaxe.
Clustering : répartir la charge de collecte
Sur un gros parc, un collecteur unique devient un point de saturation et de panne. Alloy sait former un cluster : plusieurs instances se coordonnent pour se répartir automatiquement le travail de scrape. Une cible n'est collectée que par un membre du cluster, et la charge se redistribue quand un membre tombe ou qu'on en ajoute. C'est une fonctionnalité de production intégrée, là où le même résultat avec un OTel Collector vanilla demande de monter soi-même la mécanique de sharding.
Pour la supervision Kubernetes où ce clustering prend tout son sens, on a détaillé les patterns dans notre guide sur le monitoring d'un cluster Kubernetes.
Alloy, OTel Collector vanilla ou Vector
La vraie question n'est pas « faut-il quitter l'Agent », c'est tranché par l'EOL. La question, c'est vers quoi. Trois candidats sérieux selon le contexte.
| Critère | Grafana Alloy | OTel Collector vanilla | Vector |
| Base technique | Distribution OTel | OTel de référence | Moteur Rust dédié |
| Pipelines Prometheus natifs | Oui | Limité | Via sources/sinks |
| Profils (Pyroscope) | Oui | Composants à assembler | Non |
| Clustering intégré | Oui | À monter soi-même | Non natif |
| Neutralité backend | Orienté écosystème Grafana | Totale | Forte, axé logs et métriques |
| Config | Syntaxe Alloy (River) | YAML | TOML/YAML |
Vers quel collecteur basculer. Si votre observabilité tourne déjà autour de l'écosystème Grafana (Loki, Tempo, Mimir, Pyroscope), Alloy est le choix par défaut : pipelines Prometheus natifs, profils gérés, clustering intégré, et c'est le chemin de migration officiel depuis l'Agent. Vous restez dans une stack cohérente.
Si vous visez la neutralité maximale, multi-backend, sans dépendance à un éditeur, l'OTel Collector vanilla est le bon socle. Vous assemblez vos composants, vous gérez le sharding, mais vous ne dépendez d'aucune distribution. Et si votre problème est avant tout le traitement de logs et de métriques à haut débit avec des transformations lourdes, Vector reste un outil taillé pour ça, même s'il ne couvre ni les traces OTLP de bout en bout ni les profils.
Migrer une stack de collecte n'est jamais une formalité : il faut convertir les configs, valider la collecte signal par signal, et basculer sans trou de télémétrie. Si votre supervision doit changer de socle sans perdre de visibilité pendant l'opération, on peut prendre en charge la migration et l'exploitation en infogérance.
Pour rappel des briques sous Alloy, notre guide de référence sur la stack Prometheus, Grafana et Alertmanager couvre le socle métriques et alerting que la collecte vient alimenter.
Sources
- Grafana Alloy documentation : doc officielle, distribution OTel Collector, syntaxe à composants, signaux supportés.
- Migrate to Grafana Alloy : guides de migration depuis Agent static, flow et operator, commande de conversion.
- Grafana Agent stability and end-of-life : statut de dépréciation, LTS jusqu'au 31 octobre 2025, EOL au 1er novembre 2025.
- From Agent to Alloy : pourquoi Grafana a basculé : annonce et FAQ, raisons du passage à une distribution OTel.
- Grafana Alloy sur GitHub : dépôt officiel, pipelines programmables, plus de 120 composants, clustering natif.
