Catégorie : Observabilité

Un client de Grafana Labs, DATEV eG, cherchait une ligne de log précise dans environ 1 To de données fraîchement ingérées. Avant, ça prenait trois minutes de scan. Avec la nouvelle recherche full-text annoncée le 20 octobre 2026 à ObservabilityCON, le même type de requête tombe à moins de trois secondes sur un volume effectif ramené à environ 100 Go. C’est le genre de chiffre qui parle plus qu’un slide marketing, et c’est loin d’être la seule annonce de l’événement.

Full-text search : la fonction la plus immédiatement utile

Basée sur la technologie Logline, rachetée par Grafana Labs en avril 2026, la recherche full-text pour Grafana Cloud Logs passe en GA sans surcoût. L’idée : retrouver une ligne précise (un request ID, un customer ID) sans avoir à scanner tout le volume de logs comme le fait une requête LogQL classique sur un gros intervalle de temps. D’après Grafana, la réduction du volume effectivement analysé tourne entre 80 et 90 % sur les cas d’usage de ce type.

Si tu gères un cluster avec une rétention de logs généreuse et que tes requêtes de debug mettent une éternité à remonter un incident précis dans la pile, c’est la fonctionnalité de cette liste à tester en premier — elle ne demande aucune migration, juste une mise à jour vers la version qui l’expose (section « niah » de la doc Grafana Cloud Logs).

Adaptive Telemetry : jusqu’à 50 % de coûts en moins, mais pas pour rien

Grafana avance une baisse moyenne de coûts de télémétrie de 30 % à 50 % chez ses clients grâce à l’ensemble des fonctions Adaptive Telemetry, désormais enrichi :

• Adaptive Metrics auto-apply (GA) : applique automatiquement les recommandations de réduction, avec un mode « cost-first » qui ne retient que celles qui ne font pas grimper le nombre total de séries actives — un garde-fou qu’on apprécie quand on a déjà vu une « optimisation » automatique faire l’inverse de ce qui était promis.
• Volumetric sampling (GA) : répartit le budget d’échantillonnage entre services et types de requêtes plutôt qu’un taux uniforme. Les tests précoces de Grafana montrent environ 25 % de densité d’information en plus qu’un échantillonnage probabiliste classique, à volume constant.
• Diversity sampling (GA) : conserve une combinaison unique d’attributs (service, route, code de statut) toutes les 15 minutes, sans logique de sampling à maintenir à la main.
• Adaptive Logs Archive (public preview) et replay à la demande (private preview, sur inscription) : envoie les logs froids vers un bucket objet que tu possèdes, pour l’audit ou la conformité, avec réhydratation possible plus tard.
• Requêtage des traces écartées (GA) : récupère par ID n’importe quelle trace des 24 dernières heures, même si Adaptive Traces l’avait jugée non pertinente et écartée — utile le jour où tu réalises après coup qu’une trace mise de côté aurait été exactement celle qu’il fallait garder.

Pour un lecteur qui suit déjà notre comparatif Prometheus 3.13 LTS vs 3.15, la logique est la même qu’avec le downsampling natif de Prometheus : réduire le volume stocké sans perdre l’information qui compte réellement en cas d’incident. Grafana pousse juste le curseur plus loin, côté SaaS, avec des algorithmes qui décident à ta place — ce qui est un gain de temps si tu leur fais confiance, et un sujet d’audit si tu dois justifier une rétention précise devant un régulateur.

Knowledge Graph : la promesse la plus ambitieuse, la plus en preview

Le Knowledge Graph se présente comme une couche de contexte runtime qui relie agents, applications, bases de données, services cloud et clusters Kubernetes entre eux, avec un accès par requête Cypher pour que les agents IA récupèrent des relations à la demande plutôt que de reconstruire ce contexte à partir de données brutes. Le statut varie fortement selon la brique :

• GA : Frontend Observability, Cloud Provider Observability (AWS, Azure, Google Cloud), entités et relations personnalisées, contexte runtime pour agents via Grafana Assistant ou gcx.
• Public preview : Synthetic Monitoring, Agent Observability (cartographie des agents IA et de leurs dépendances).
• Private preview : Database Observability pour SQL Server, service ownership (intégration Service Center), historique d’incidents lié à l’IRM.

Autrement dit, la partie vraiment solide aujourd’hui (GA) reste centrée sur la cartographie infra/cloud classique. Tout ce qui concerne spécifiquement les agents IA — Agent Observability en tête — est encore en preview, et Grafana ne détaille ni la configuration ni les métriques collectées à ce stade. Si ton équipe n’opère pas encore d’agents IA en production, cette partie de l’annonce peut attendre sans rien perdre.

Ce qui change concrètement pour ton setup existant

Si tu es déjà sur Grafana 13.2, aucune de ces annonces n’impose de montée de version lourde : full-text search et la plupart des fonctions Adaptive Telemetry sont des capacités Grafana Cloud, pas des changements de l’OSS auto-hébergé. Si tu fais tourner ta propre stack Prometheus/Grafana sans la couche Cloud, l’essentiel de ce qui sort le 20 octobre ne te concerne pas directement — à part comme indicateur de la direction que prend l’écosystème : de plus en plus de traitement intelligent du volume de télémétrie, plutôt que du simple stockage brut.

FAQ

Faut-il migrer vers Grafana Cloud pour profiter de ces annonces ?

Oui pour la quasi-totalité : full-text search, Adaptive Telemetry et Knowledge Graph sont des fonctionnalités de Grafana Cloud, pas de l’édition open source auto-hébergée.

Le mode « cost-first » d’Adaptive Metrics peut-il dégrader mes dashboards existants ?

Selon Grafana, ce mode n’applique que les recommandations qui ne font pas augmenter le nombre total de séries actives — il est pensé pour limiter ce risque, mais Grafana ne communique pas de garantie chiffrée au-delà de cette description.

Agent Observability remplace-t-il un outil d’AIOps dédié ?

Non, pas en l’état : c’est une cartographie des agents IA et de leurs dépendances dans le Knowledge Graph, encore en public preview, sans détail public sur les métriques collectées ni la tarification.

En pratique

Commence par activer la recherche full-text sur Grafana Cloud Logs si tu y as accès — c’est gratuit, GA, et c’est la fonction qui fera gagner du temps dès le prochain incident de prod, bien avant que le Knowledge Graph ou Agent Observability sortent de preview.

Sources : le récapitulatif officiel des annonces ObservabilityCON 2026 sur grafana.com et le communiqué de presse Grafana Labs du 20 octobre 2026.

Prometheus sort une version mineure toutes les six semaines. Si tu suis ce rythme à la lettre sur ton cluster de prod, tu passes ton temps à mettre à jour un composant qui, en théorie, ne devrait pas te réveiller la nuit. La 3.14 est sortie le 17 août 2026 ; elle a cessé de recevoir des correctifs le 30 septembre, soit six semaines plus tard quasiment au jour près. La 3.15, sortie le 24 septembre, sera à son tour en fin de vie le 6 novembre. Pendant ce temps, la 3.13 — sortie le 1er juillet — reste supportée jusqu’au 31 juillet 2027. Ce n’est pas un hasard de calendrier : c’est le modèle LTS de Prometheus, et la plupart des équipes qui tournent en prod devraient s’en servir plutôt que de courir après la dernière mineure.

Comment fonctionne le support LTS chez Prometheus

Le projet documente son cycle de release sans ambiguïté : une mineure classique sort toutes les six semaines, et passé ce délai, elle ne reçoit en général plus aucun correctif. Si un bug te touche sur une version qui n’est plus maintenue, la seule réponse officielle est de migrer vers la dernière mineure — pas vers un patch rétroporté.

Les versions LTS cassent cette règle pour une poignée de releases choisies : un an de support au lieu de six semaines. Mais ce support a un périmètre précis, pas un blanc-seing :

• seules les failles de sécurité avec un score CVSS supérieur ou égal à 7.0 sont corrigées sur une LTS ;
• d’autres correctifs de bugs ou de documentation peuvent s’ajouter, à la discrétion des mainteneurs ;
• la chaîne de compilation est maintenue à jour sur toute la durée du support ;
• deux LTS successives se chevauchent d’au moins un mois, pour laisser le temps de migrer sans courir.

Et c’est un effort communautaire assumé comme tel : « best effort », sans garantie contractuelle, sans SLA. Les fonctionnalités expérimentales (tout ce qui vit derrière un feature flag) et le support OpenBSD sont explicitement exclus du périmètre LTS, quelle que soit la version.

L’historique dit tout

Cinq versions ont porté l’étiquette LTS depuis que le modèle existe :

• 2.37 — sortie le 14/07/2022, fin de support le 31/07/2023
• 2.45 — sortie le 23/06/2023, fin de support le 31/07/2024
• 2.53 — sortie le 16/06/2024, fin de support le 31/07/2025
• 3.5 — sortie le 14/07/2025, fin de support le 31/07/2026
• 3.13 — sortie le 01/07/2026, fin de support le 31/07/2027 (en cours)

Le rythme est régulier : une nouvelle LTS environ chaque année, avec le chevauchement d’un mois prévu par la doc. La prochaine est attendue autour de juin 2027, pour une fin de support en juillet 2028. Si ton infra tourne encore en 3.5 aujourd’hui, tu es dans la fenêtre de chevauchement — mais plus pour longtemps vu l’échéance du 31 juillet 2026, déjà passée au moment où tu lis cet article.

Ce que tu rates en restant sur la 3.13 plutôt que la 3.15

La 3.15.0, sortie le 24 septembre, apporte des choses utiles mais rarement critiques pour un cluster déjà stable : scraping via sockets Unix, implémentation du format OpenMetrics 2.0, compression zstd des réponses de scrape derrière le flag zstd-scrape, et un --auto-gomemlimit.refresh-interval qui redétecte à chaud la limite mémoire du conteneur. Côté dépréciation, --log.level cède la place à runtime.log_level, rechargeable sans redémarrer le process — pratique, mais pas une raison de migrer en urgence.

Il y a aussi un paquet de corrections sur les histogrammes natifs (détection de reset manquée qui sous-estimait rate() et increase(), erreurs d’index dans Compact) et sur le mode Agent, où une écriture WAL échouée pouvait corrompre le fichier. Si tu exploites activement les histogrammes natifs ou le mode Agent, ces correctifs valent une mise à jour ciblée — même en dehors du calendrier LTS. Pour le reste, ça peut attendre la prochaine LTS.

Notre avis : arrête de courir après chaque mineure

Sauf si une fonctionnalité précise de la 3.14 ou de la 3.15 te manque vraiment, reste sur la 3.13 jusqu’à l’approche de juillet 2027. Tu gagnes un an de stabilité réelle, un correctif de sécurité garanti pour tout CVSS ≥ 7.0, et tu évites le cycle de mise à jour toutes les six semaines qui n’apporte, la plupart du temps, que du bruit opérationnel. À l’inverse, si tu es du genre à vouloir tester chaque nouveauté avant tout le monde — ou si tu fais tourner Prometheus sur un environnement de test plutôt qu’en prod critique — suivre les mineures reste parfaitement défendable. Ce n’est pas un mauvais choix dans l’absolu, juste un choix qui demande d’accepter le rythme qui va avec.

FAQ

Une faille CVSS 6.x découverte sur la 3.13 sera-t-elle corrigée ?
Pas via le canal LTS officiel : seul un CVSS ≥ 7.0 déclenche un correctif de sécurité garanti sur une LTS. Une faille moins sévère peut être corrigée si un mainteneur s’en occupe bénévolement, mais sans aucune garantie.

Peut-on sauter une LTS, par exemple passer directement de la 2.53 à la 3.13 ?
Oui techniquement, mais vérifie les guides de migration de chaque version majeure traversée (le passage 2.x → 3.x a changé pas mal de comportements par défaut) avant de sauter plusieurs cycles d’un coup.

Le mode Agent et les histogrammes natifs sont-ils couverts par le support LTS ?
Oui s’ils sont considérés stables selon les garanties de l’API Prometheus ; les fonctionnalités encore derrière un feature flag restent explicitement exclues du périmètre LTS, même sur une version LTS.

Ce qu’il faut retenir

Le choix de version Prometheus n’a rien d’arbitraire : c’est une question de politique de support documentée, avec des dates précises et un périmètre de sécurité clair. Pour la très grande majorité des clusters en prod, la bonne réponse en octobre 2026 est 3.13, pas 3.15 — et ça restera vrai jusqu’à l’été 2027. On avait déjà couvert l’arrivée de Prometheus 3 face à Grafana 13 et OpenTelemetry, et plus récemment les Saved Queries de Grafana 13.2 — la question de la version Prometheus sous-jacente, elle, se pose indépendamment de ce qui tourne par-dessus.

Depuis Grafana 13.2, tu n’as plus besoin d’un fichier tnsnames.ora pour connecter une source Oracle : une chaîne au format host:port/service suffit, via la nouvelle méthode Easy Connect Plus. C’est le genre de détail qui ne fait pas la une, mais qui t’évite un vrai point de friction en prod. Cette version, sortie fin septembre 2026, en aligne une bonne dizaine d’autres dans le même esprit : moins de configuration à la main, plus de fonctionnalités passées en disponibilité générale.

Dashboards et requêtes : ce qui passe en GA

Les saved queries (requêtes sauvegardées) sont désormais en disponibilité générale sur Grafana Enterprise et Grafana Cloud. Tu peux les ouvrir directement depuis la palette de commandes (Cmd/Ctrl+K) pour les lancer dans Explore, et surtout les provisionner avec Terraform — ce qui les fait enfin entrer dans ton flux infrastructure-as-code, au lieu de rester un artefact créé à la main dans l’UI.

Trois autres nouveautés GA sur les dashboards :

• L’éditeur de variables de requête a été redessiné : aperçu des valeurs en haut, éditeur à onglets en dessous, pour voir le résultat pendant que tu modifies la requête plutôt qu’après coup.
• Le regroupement multi-sélection permet, en mode édition, de sélectionner plusieurs panneaux à la fois pour les regrouper dans une ligne ou un onglet, sans les glisser un par un.
• L’indication d’auto-layout est plus claire quand glisser le coin d’un panneau n’a visiblement aucun effet — un bug UX mineur mais agaçant, enfin expliqué à l’écran.

Le panneau « View panel » avec barre latérale de contrôles arrive lui en préversion publique seulement : il permet à un utilisateur sans droits d’édition d’ajuster l’affichage d’une visualisation, notamment en découpant une série temporelle en un graphique par série ou par label. Pas encore stable, donc pas pour la prod si tu es sensible aux breaking changes.

Les sources de données qui t’évitent du throttling

Pour qui pilote des dashboards sur beaucoup de ressources Azure, la nouveauté qui compte vraiment est l’API Batch Metrics d’Azure Monitor, passée en GA. Avant, Grafana envoyait une requête de métriques par ressource. Maintenant, les requêtes éligibles sont regroupées en un seul envoi. Résultat concret : moins d’appels à l’API Azure, des dashboards qui chargent plus vite, et surtout moins de risque de passer en throttling sur les tableaux de bord qui interrogent des dizaines de ressources en parallèle. Si une partie de tes dashboards Azure Monitor rame aux heures de pointe, c’est la fonctionnalité à activer en priorité après la mise à jour.

Deux autres sources de données progressent :

• OpenSearch reçoit un sélecteur d’index en GA : bouton « Select index », nombre de documents et santé du cluster affichés par index, recherche par sous-chaîne, jokers ou expression régulière entre slashes.
• BigQuery et Google Cloud Monitoring passent en GA sur Grafana Cloud pour la fédération d’identité de charge de travail (Workload Identity Federation) : plus de fichier de clé de compte de service à gérer, le jeton OIDC de l’utilisateur connecté est échangé contre un jeton Google Cloud à courte durée de vie via le Security Token Service.

Git Sync s’ouvre enfin aux grandes organisations

Jusqu’ici, Git Sync — la synchronisation bidirectionnelle des dashboards et dossiers entre Git et Grafana, qu’on avait couverte à l’arrivée de Grafana 13.1 — ne gérait les webhooks temps réel et l’intégration de pull requests que pour GitHub, et seulement sur certains dépôts publics. La 13.2 corrige ce point sur deux fronts :

• Support de GitHub Enterprise (Server et Cloud) en GA — un vrai déblocage pour les organisations qui n’avaient tout simplement pas accès à Git Sync avant.
• Webhooks GitLab et Bitbucket en GA, avec les mêmes mises à jour en temps réel et la même intégration de pull requests que sur GitHub.

Ajoute à ça la possibilité de définir un auteur de commit personnalisé (« author override ») à partir de la 13.2.0 — sans quoi Grafana utilise par défaut le nom et l’e-mail de l’utilisateur connecté, ce qui peut vite polluer ton historique Git si plusieurs personnes modifient les mêmes dashboards.

Dépannage interne : exporter les traces sans déployer de collector

Dernier ajout notable : l’export des traces internes de Grafana vers un fichier, en GA sur OSS comme sur Enterprise. Tu peux désormais collecter les traces de Grafana lui-même pour du dépannage de performance, sans avoir à déployer un OpenTelemetry Collector ni un backend de tracing dédié juste pour ça — utile si tu veux diagnostiquer un ralentissement ponctuel sans monter toute une stack d’observabilité pour l’occasion. Pour creuser l’interopérabilité OpenTelemetry/Prometheus plus large, on l’avait détaillée dans cet article.

FAQ

Dois-je migrer tout de suite vers la 13.2 ?

Pas dans l’urgence, sauf si tu es bloqué par l’un des points ci-dessus (throttling Azure Monitor, Git Sync sur GitHub Enterprise). Dans tous les cas, passe par le guide de mise à jour officiel avant de toucher à un environnement de production.

Les saved queries sont-elles disponibles en version open source ?

La documentation confirme la disponibilité générale sur Enterprise et Grafana Cloud ; elle ne précise pas le statut pour la version open source, donc vérifie directement sur ton instance avant d’en dépendre.

L’API Batch Metrics d’Azure Monitor fonctionne-t-elle sur toutes mes requêtes ?

Non, seulement sur les requêtes de métriques éligibles au regroupement — pas sur l’ensemble du trafic Azure Monitor généré par tes dashboards.

Ce qu’il faut retenir

Pas de rupture majeure dans cette version, mais une accumulation de frictions résolues : moins d’appels API côté Azure, moins de bricolage côté Oracle, et Git Sync enfin utilisable dans les grandes organisations sous GitHub Enterprise. Si tu avais mis Git Sync de côté faute de support GitHub Enterprise, c’est le bon moment pour retester. Pour le détail complet de chaque changement, le changelog officiel de la 13.2 reste la référence à consulter avant de planifier ta montée de version — et si tu veux revoir d’où vient cette série, notre article sur l’arrivée de Grafana 13 pose les bases.

Grafana 13.1 est sorti cet été, et la fonctionnalité qui mérite vraiment ton attention n’est pas un nouveau type de panel. C’est Git Sync, qui transforme enfin tes dashboards en fichiers versionnés comme n’importe quel autre bout de code d’infra — fini le dashboard de prod modifié en direct sans trace.

Git Sync : tes dashboards deviennent du code versionné pour de vrai

Grafana proposait déjà une synchronisation Git basique. La 13.1 comble plusieurs trous pratiques : tu peux désormais importer un fichier JSON de dashboard directement depuis l’interface dans un dossier synchronisé avec Git, sans passer par une ligne de commande. La synchronisation fonctionne aussi au niveau racine du dépôt, sans obliger à passer par un dossier parent conteneur — un détail qui compte si ton dépôt de dashboards est organisé à plat. Les commits peuvent être signés automatiquement, via GPG, SSH ou S/MIME, et marqués « Verified » dans l’historique. Et les fichiers README.md du dépôt s’affichent nativement dans l’interface Grafana, à côté des dashboards qu’ils documentent.

Si plus d’une personne touche à tes dashboards de production, c’est la fonctionnalité qui élimine une classe entière d’incidents bêtes : le fameux dashboard modifié en direct par quelqu’un sans que personne ne le sache, découvert uniquement quand une alerte ne se déclenche plus comme prévu. Avec Git Sync et des commits signés, chaque changement a un auteur, un historique et un diff — exactement ce qu’on attend d’une infra gérée comme du code.

Grafana Assistant : huit nouvelles sources de données interrogeables directement

Sous Grafana Enterprise, l’Assistant est désormais préinstallé nativement, sans passer par un plugin séparé. Sous Grafana OSS, il reste disponible via un plugin à installer à part. Le vrai changement, c’est l’élargissement à huit nouvelles sources de données interrogeables directement depuis l’Assistant : Snowflake, MongoDB, Oracle, Elasticsearch, Dynatrace, Honeycomb, Zabbix et Jira.

L’intérêt concret : pouvoir poser une question qui croise observabilité et données métier sans changer d’outil — par exemple relier un pic de latence constaté dans tes métriques à un ticket Jira ouvert au même moment, ou croiser une alerte Zabbix avec une requête sur une base Oracle, directement dans l’interface Grafana. Ce n’est pas magique : l’Assistant interroge ce qu’on lui donne accès, et la qualité des réponses dépend toujours de la façon dont les sources sont connectées et nommées.

Côté dashboards : ce qui change au quotidien

Au-delà de ces deux chantiers, la 13.1 fait passer en disponibilité générale (GA) une série de fonctionnalités qui traînaient en preview :

• Variables multi-propriétés : une seule variable peut désormais être mappée à plusieurs valeurs à la fois.
• Transformation « Time series to table » : convertit une série temporelle en lignes de tableau avec des champs de tendance calculés.
• Clustering d’annotations : navigation plus lisible quand un dashboard accumule beaucoup d’annotations sur une période.
• Copier/coller les styles de panneaux : dupliquer la mise en forme d’un panel vers un autre sans tout reconfigurer à la main.
• Filtres rapides et regroupement (« Filter and Group by ») sans avoir à configurer de variable de template au préalable.
• Variables à portée de section : une variable peut désormais être limitée à une ligne ou un onglet spécifique du dashboard, plutôt que de s’appliquer partout.

Prises une par une, ce sont des améliorations mineures. Prises ensemble, elles réduisent le nombre de dashboards qu’il faut reconstruire à la main après un changement de structure — ce qui, sur un parc de dashboards qui grossit depuis des années, finit par représenter un vrai gain de temps.

Private Data Source Connect : MQTT, GitHub et IBM Db2 ajoutés

Pour les sources de données hébergées sur site, Private Data Source Connect (PDC) permet d’établir un tunnel sécurisé sans ouvrir de port entrant sur le pare-feu. La 13.1 étend la liste des sources compatibles avec MQTT, GitHub et IBM Db2 — utile si une partie de ton infra d’observabilité reste on-prem pendant que Grafana lui-même tourne dans le cloud.

FAQ

La mise à jour depuis Grafana 13.0 casse-t-elle quelque chose ?

Les notes de version officielles ne signalent pas de changement cassant majeur pour cette mise à jour mineure. Comme pour toute montée de version en production, teste d’abord sur une instance non critique, surtout si tu utilises des dashboards avec des variables ou des transformations personnalisées.

Git Sync remplace-t-il complètement la sauvegarde de dashboards via API ?

Non, ce sont deux approches complémentaires. Git Sync gère le versioning et la collaboration sur les définitions de dashboards ; une sauvegarde applicative classique (configuration des datasources, permissions, plugins installés) reste nécessaire pour une reprise après incident complète.

Le clustering d’annotations change-t-il le comportement existant ?

C’est une fonctionnalité passée en GA après une période de preview — elle était déjà testable, elle devient maintenant stable et recommandée en production. Si tu l’avais déjà activée en preview, le comportement ne devrait pas changer radicalement.

Pour commencer

Pas besoin de tout basculer d’un coup. Le plus simple pour se faire une idée concrète : choisir un seul dossier de dashboards, le synchroniser avec un dépôt Git existant, et observer comment l’équipe s’approprie le flux de commits avant de généraliser. Les détails techniques complets sont dans l’annonce officielle de la version 13.1 et la documentation dédiée à Git Sync. Et si tu veux remettre à plat ta stack d’observabilité dans son ensemble avant d’ajouter une brique de plus, notre tour d’horizon de Grafana 13, Prometheus 3 et OpenTelemetry reste un bon point de départ.

Traces, métriques, logs : les trois signaux historiques d’OpenTelemetry répondent bien à « quoi » et « quand », beaucoup moins bien à « pourquoi ce pod consomme 4 cœurs pour traiter 200 requêtes par seconde ». Pour répondre à cette question-là, il fallait jusqu’ici un profiler dédié — souvent propriétaire, souvent payant, rarement corrélé au reste de ta télémétrie. Depuis le 26 mars 2026, OpenTelemetry a un quatrième signal officiel pour ça : les profiles, entrés en alpha publique.

Six mois plus tard, où en est vraiment ce signal, et est-ce raisonnable de commencer à s’y intéresser sérieusement ?

Ce que le profiling continu apporte concrètement

L’idée n’est pas nouvelle — Pyroscope, Parca ou le Continuous Profiler de Datadog font ça depuis des années. Ce qui l’est, c’est la standardisation : un format commun pour représenter des stacks d’appel échantillonnées en continu, avec une corrélation native aux traces via les mêmes trace_id et span_id. Concrètement, tu peux passer d’une trace lente dans Grafana Tempo ou Jaeger directement au profil CPU du service concerné, sans changer d’outil ni recorréler manuellement par timestamp.

Techniquement, la représentation est dédupliquée : chaque call-stack unique n’est stocké qu’une fois, référencé ensuite par index. Avec le support de dictionnaires de chaînes ajouté au format, l’annonce officielle parle d’une réduction de 40 % de la taille sur le réseau par rapport à une représentation naïve. Pour un signal dont le volume de données peut vite dépasser celui des traces classiques, ce n’est pas un détail cosmétique.

Les runtimes déjà supportés par l’agent eBPF

L’agent de profiling eBPF (celui qui échantillonne sans toucher au code de l’application) couvre aujourd’hui :

• Go, avec symbolisation automatique sur la cible ;
• Node.js (moteur V8), y compris sur architecture ARM64 ;
• Ruby, avec des améliorations récentes sur le unwinding et la symbolisation ;
• .NET 9 et 10 ;
• BEAM (Erlang/Elixir), en support initial, donc encore limité.

Si tu es sur du Python ou du Java pur JVM, la couverture native n’est pas encore là — à vérifier avant de bâtir un business case dessus.

Le vrai statut en septembre 2026 : encore alpha, et ça compte

L’annonce officielle est sans ambiguïté sur ce point : « with the Alpha status of the release, the signal should not be used for critical production workloads ». Ce n’est pas une formule de prudence juridique standard — les backends capables d’ingérer et d’exploiter ce format en production ne sont eux-mêmes pas encore matures partout. Le Collector OpenTelemetry sait déjà traiter et transformer des données de profiling, mais les receivers/exporters spécifiques évoluent encore vite dans opentelemetry-collector-contrib, au rythme de plusieurs changements par semaine.

Ma position là-dessus : c’est le bon moment pour tester sur un environnement de dev ou de préproduction, pas pour remplacer ton profiler de production actuel. Si tu utilises déjà Pyroscope ou un profiler propriétaire qui te satisfait, garde-le en place et suis l’évolution du signal en parallèle — la bascule aura plus de sens quand le format atteindra au minimum le statut bêta et que ton backend d’observabilité (Grafana, Elastic, ou autre) l’exposera nativement.

Comment ça s’articule avec ce qu’on a déjà couvert

Si tu as suivi la mise en production de l’instrumentation eBPF zero-code (OBI), la logique est la même côté infrastructure : pas de modification de code, un agent qui observe depuis l’extérieur. La différence est dans la donnée produite — OBI génère des traces et métriques à partir du trafic réseau observé, les profiles génèrent des échantillons de call-stacks CPU/mémoire. Les deux sont complémentaires, pas substituables l’un à l’autre.

Et si ta stack repose déjà sur l’interopérabilité OpenTelemetry/Prometheus mise en place récemment pour tes métriques, il vaut mieux garder le profiling dans un pipeline séparé pour l’instant : mélanger un signal alpha à une chaîne de métriques qui tourne en production, c’est prendre un risque de stabilité pour un gain qui reste expérimental.

FAQ

Faut-il réécrire son instrumentation existante pour profiter des profiles ?

Non. L’agent eBPF fonctionne sans instrumentation manuelle du code, à condition que ton runtime figure dans la liste supportée. C’est justement l’intérêt du zero-code appliqué au profiling.

Le format de profiling OpenTelemetry remplace-t-il pprof ?

Il s’en inspire largement et vise l’interopérabilité avec l’écosystème existant, mais l’objectif est de devenir un format d’échange standard indépendant du langage, pas juste un pprof rebaptisé.

Quand ce signal deviendra-t-il stable (GA) ?

Aucune date n’est publiée à ce stade. Le passage d’alpha à bêta, puis à stable, suivra le même processus de spécification que les trois autres signaux — ça s’est compté en années pour les traces et métriques, pas en mois.

Ce qu’il faut retenir

Le quatrième signal d’OpenTelemetry tient ses promesses sur le papier : corrélation native avec les traces, format compact, zero-code sur les runtimes courants côté backend. Mais il reste un projet alpha avec un avertissement explicite contre un usage en production critique. Le bon réflexe maintenant : l’évaluer en préproduction, suivre les releases hebdomadaires du Collector Contrib, et prévoir de revisiter la question dans quelques mois plutôt que de migrer ta stack de profiling dès aujourd’hui.

Pendant longtemps, faire cohabiter OpenTelemetry et Prometheus dans la même stack d’observabilité relevait du bricolage : exporters à double emploi, noms de métriques qui ne correspondaient pas, labels à retraiter à la main. Une enquête publiée en 2026 par le projet OpenTelemetry, menée auprès de 81 utilisateurs actifs des deux écosystèmes, montre que cette friction a nettement reculé depuis 2024. Si tu hésites encore entre migrer intégralement vers OTel ou garder ton stack Prometheus historique comme évoqué dans notre tour d’horizon Grafana 13 / Prometheus 3 / OpenTelemetry, voici ce que dit ce retour terrain — et comment configurer l’interopérabilité concrètement sur ton cluster.

Ce que révèle l’enquête 2026

Le constat principal : la coexistence des deux écosystèmes est devenue nettement plus simple, et la tendance de fond n’est pas la migration totale vers l’un ou l’autre, mais la cohabitation assumée.

• Facilité d’usage perçue : la note moyenne passe de 3,1 à 3,6 sur 5 entre 2024 et 2026 ; la part des répondants trouvant l’intégration difficile chute de 29 % à 10 %, et plus personne ne la juge « très difficile » (contre 7 % en 2024)
• Instrumentation infra : 72 % utilisent encore des exporters Prometheus classiques, 57 % des receivers OTel — et près de la moitié des répondants font tourner les deux en parallèle plutôt que de migrer intégralement
• Instrumentation applicative : les SDK OTel sont en tête avec 65 % d’adoption, devant les SDK Prometheus natifs (52 %) ; 41 % des répondants utilisent exclusivement l’instrumentation OTel
• Traitement des données : 53 % passent par l’OpenTelemetry Collector open source, 54 % gardent des règles de relabeling Prometheus ; 65 % déclarent maintenir une stack « vanilla » sans surcouche propriétaire

Les points de friction qui restent, d’après les retours de la communauté : l’unification des modèles de données entre les deux mondes, la gestion des attributs de ressource (resource attributes), et les frictions de nommage entre conventions Prometheus et sémantique OTel.

Comment ça marche concrètement : Prometheus comme backend OTLP

Depuis Prometheus 3.x, le serveur peut recevoir directement des métriques au format OTLP, sans passer par un collector intermédiaire pour le stockage final. La documentation officielle Prometheus décrit la configuration minimale :

# Démarrer Prometheus avec le receiver OTLP activé
# (désactivé par défaut pour des raisons de sécurité)
prometheus --web.enable-otlp-receiver

# Côté application ou collector, pointer vers l'endpoint Prometheus
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://localhost:9090/api/v1/otlp

Le chemin /v1/metrics est ajouté automatiquement à l’URL — pas besoin de le préciser toi-même dans la variable d’environnement.

UTF-8 et noms de métriques

Depuis la version 3.x, Prometheus supporte l’UTF-8 dans les noms de métriques et de labels, ce qui règle une bonne partie des frictions de nommage évoquées dans l’enquête. Tu peux choisir entre quatre stratégies de traduction (translation_strategy), dont NoTranslation et NoUTF8EscapingWithSuffixes qui préservent les caractères UTF-8 des métriques OTel sans les réencoder — utile si tes métriques utilisent des points ou des caractères non-ASCII issus des conventions sémantiques OTel.

Attributs de ressource : à promouvoir en labels

Par défaut, les attributs de ressource OTel (service.name, service.instance.id, k8s.namespace.name…) ne sont pas automatiquement exposés comme labels Prometheus interrogeables en PromQL. La documentation recommande de les promouvoir explicitement — sans ça, tu perds une bonne partie de la valeur du contexte OTel une fois les métriques stockées côté Prometheus.

Temporalité delta : encore expérimental

OpenTelemetry gère nativement la temporalité delta pour certaines métriques, alors que Prometheus attend du cumulatif. Un processeur delta-to-cumulative existe côté collector, mais reste marqué comme expérimental et nécessite d’activer le feature flag otlp-deltatocumulative — à tester en environnement de non-prod avant de t’y fier en production. Le détail des transformations appliquées à l’export OTLP vers Prometheus est documenté sur la page de compatibilité officielle OpenTelemetry.

Faut-il migrer entièrement vers OTel, ou garder Prometheus ?

Le message de l’enquête est clair : la cohabitation n’est plus une solution de transition bancale, c’est devenu un choix d’architecture assumé par une majorité de répondants. Concrètement :

• Si ton parc applicatif est déjà majoritairement instrumenté en Prometheus (exporters, client libraries), le receiver OTLP de Prometheus 3.x te permet d’absorber progressivement les nouvelles applications instrumentées en OTel sans tout réécrire
• Si tu démarres un nouveau projet ou migres un service, l’instrumentation OTel-native (SDK OTel) te donne la portabilité vers d’autres backends si tu changes un jour de stack d’observabilité
• Dans tous les cas, prévois du temps pour la promotion des attributs de ressource en labels — c’est le point qui casse le plus souvent les dashboards PromQL existants après une migration partielle

Si tu utilises déjà l’instrumentation zero-code via eBPF (OBI) pour tes applications non instrumentées manuellement, cette interopérabilité Prometheus/OTLP s’applique de la même façon en aval — le format de sortie reste OTLP, quelle que soit la méthode de collecte utilisée en amont.

FAQ

Le receiver OTLP de Prometheus remplace-t-il l’OpenTelemetry Collector ?

Non. Le receiver OTLP permet à Prometheus de recevoir directement des métriques au format OTLP en fin de chaîne, mais l’OpenTelemetry Collector reste utile pour le traitement intermédiaire (filtrage, enrichissement, routage vers plusieurs backends) — d’ailleurs 53 % des répondants de l’enquête continuent à s’en servir même avec un backend Prometheus.

Dois-je réinstrumenter toutes mes applications pour profiter de cette interopérabilité ?

Non, c’est justement le point de l’enquête : près de la moitié des organisations font tourner exporters Prometheus classiques et receivers OTel en parallèle, sans migration forcée.

Le support OTLP de Prometheus est-il activé par défaut ?

Non, il faut explicitement démarrer Prometheus avec le flag --web.enable-otlp-receiver — désactivé par défaut pour limiter la surface d’exposition du endpoint.

En bref

L’interopérabilité OTel/Prometheus est passée d’un point de friction reconnu à un fonctionnement quasi transparent pour la majorité des équipes qui l’utilisent en 2026 — la cohabitation des deux écosystèmes, plutôt que le tout-ou-rien, est en train de devenir la norme. Si ta stack actuelle jongle encore entre exporters Prometheus et efforts d’instrumentation OTel séparés, active le receiver OTLP sur un environnement de test cette semaine et vérifie la promotion de tes attributs de ressource en labels avant de généraliser.

Tu as déjà vécu ça : un service qui plante en prod, zéro trace, zéro métrique, parce que personne n’a eu le temps d’ajouter le SDK OpenTelemetry avant la mise en prod. L’instrumentation manuelle, c’est la première victime des deadlines. En 2026, un projet change la donne : OpenTelemetry eBPF Instrumentation (OBI) capture traces et métriques directement dans le noyau Linux, sans toucher une ligne de code applicatif.

Dans cet article, tu vas voir comment OBI fonctionne, comment le déployer en quelques minutes sur une stack existante, et comment Azure propose son propre équivalent côté réseau avec Advanced Container Networking Services. De quoi décider si ça vaut le coup de l’ajouter à ta stack d’observabilité dès maintenant.

Le problème que l’instrumentation manuelle ne résout jamais complètement

Même avec les meilleurs SDK OpenTelemetry, l’instrumentation manuelle a trois angles morts récurrents : les services legacy que personne n’ose toucher, les dépendances tierces dont tu ne contrôles pas le code, et le délai entre le déploiement d’un nouveau service et le moment où quelqu’un pense à l’instrumenter. Résultat, ta couverture d’observabilité ressemble à un gruyère — complète là où ça compte le moins, trouée là où un incident finit par arriver.

C’est exactement le vide que l’approche eBPF comble : une visibilité automatique, appliquée au niveau du noyau, qui ne dépend d’aucune modification de code.

eBPF et OBI : comment ça marche concrètement

eBPF (extended Berkeley Packet Filter) permet d’exécuter du code sandboxé directement dans le noyau Linux, sans module noyau custom ni redémarrage. Appliqué à l’observabilité, ça veut dire intercepter les appels système et le trafic réseau d’un processus pour en déduire son comportement applicatif — sans jamais charger le moindre agent dans le processus lui-même.

De Grafana Beyla à OpenTelemetry eBPF Instrumentation

Le projet a démarré comme Grafana Beyla, avant d’être donné à la fondation OpenTelemetry et rebaptisé OBI. Cette bascule sous gouvernance CNCF/OpenTelemetry est ce qui a permis l’adoption large qu’on observe depuis le début d’année : les données produites respectent nativement le format OpenTelemetry (OTLP), donc elles s’intègrent directement à n’importe quel backend déjà en place — Grafana, Datadog, Azure Monitor, peu importe.

Ce qu’OBI capture réellement

Concrètement, OBI donne accès sans instrumentation à :

• Des traces distribuées, avec propagation de contexte à travers les appels HTTP et gRPC entre services
• Les métriques RED (Rate, Errors, Duration) par service et par endpoint
• Le support d’un nombre croissant de protocoles applicatifs — HTTP, gRPC, et l’expansion 2026 prévoit MQTT, AMQP, NATS, Redis pub/sub et MongoDB

Déployer OBI en pratique

Le déploiement le plus simple reste un conteneur sidecar ou un DaemonSet Kubernetes qui s’attache aux processus ciblés via leur cgroup ou leur port d’écoute. Exemple minimal en environnement Kubernetes :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: obi-instrumentation
  namespace: observability
spec:
  selector:
    matchLabels:
      app: obi
  template:
    metadata:
      labels:
        app: obi
    spec:
      hostPID: true
      containers:
        - name: obi
          image: otel/ebpf-instrument:latest
          securityContext:
            privileged: true
          env:
            - name: OTEL_EXPORTER_OTLP_ENDPOINT
              value: "http://otel-collector.observability:4317"
            - name: OTEL_EBPF_OPEN_PORT
              value: "8080"

Pas de redéploiement applicatif, pas de sidecar dans chaque pod métier : un seul DaemonSet observe tout le nœud. C’est cette simplicité opérationnelle qui explique l’engouement — tu factures le coût d’adoption une seule fois, pour tout le cluster.

Le pendant réseau côté Azure : Advanced Container Networking Services

Si OBI couvre la couche applicative, Microsoft a poussé une approche eBPF équivalente côté réseau pour AKS avec Advanced Container Networking Services (ACNS). Basé sur le data plane Cilium et l’intégration Hubble, ACNS capture la latence DNS, les flux pod-à-pod, les drops de policy réseau et les métriques HTTP au niveau 7 — le tout remonté nativement vers Azure Monitor managed Prometheus et Azure Managed Grafana.

Si ton budget ne justifie pas l’offre payante ACNS, l’alternative open source de Microsoft, Retina, couvre l’essentiel avec les mêmes fondations eBPF, en self-managed et gratuite — un bon point de départ avant d’envisager la version gérée.

Offre	Coût	Gestion	Cas d’usage
ACNS	Service Azure payant	Entièrement managé	Observabilité réseau entreprise, dashboards Grafana avancés
Network Observability (Azure Monitor)	Inclus avec Prometheus managé	Managé	Monitoring basique niveau nœud/cluster
Retina OSS	Gratuit, open source	Self-managed	Debug avancé, captures de paquets, multicloud

Où en est OBI en septembre 2026

Le projet vise une release stable 1.0 avec quatre priorités affichées pour l’année : la stabilisation du format de configuration avec schémas JSON documentés, l’expansion vers de nouveaux protocoles (dont les SDK cloud AWS, Google Cloud et Azure), une couverture .NET élargie (.NET 8+ ainsi que les frameworks legacy .NET 4.x), et surtout une intégration hybride fluide avec l’instrumentation manuelle existante — pour que tu puisses garder tes SDK OpenTelemetry là où tu en as déjà, et ajouter OBI en complément plutôt qu’en remplacement. Retrouve le détail complet sur la page officielle des objectifs 2026 d’OBI et la documentation OpenTelemetry zero-code.

Faut-il l’adopter maintenant ?

Si tu gères déjà une stack Grafana/Prometheus/OpenTelemetry — voir notre tour d’horizon de la stack d’observabilité 2026 — ajouter OBI en complément ne coûte quasiment rien : tu gagnes une couverture de base sur tous les services, y compris ceux que personne n’a instrumentés. En revanche, si ta stack est encore jeune, mieux vaut d’abord poser les fondations OTLP/collector avant d’ajouter une couche eBPF par-dessus, pour éviter d’empiler la complexité.

La documentation officielle de Grafana Beyla, le moteur historique derrière OBI, reste une excellente ressource pour comprendre les options de configuration fines : Grafana Beyla documentation.

FAQ

OBI remplace-t-il complètement l’instrumentation manuelle ?

Non, et ce n’est pas l’objectif du projet. OBI donne une visibilité de base immédiate ; l’instrumentation manuelle reste utile pour capturer des données métier spécifiques (un identifiant de commande, un montant de panier) que le noyau ne peut pas déduire du trafic réseau.

Est-ce que ça fonctionne sur Windows ?

Non, eBPF est une technologie noyau Linux. Pour des workloads Windows, il faut rester sur l’instrumentation SDK classique ou les agents Azure Monitor Application Insights.

Quel est l’impact en performance ?

Le surcoût est généralement de l’ordre de quelques pourcents de CPU par nœud, comparable aux sidecars de service mesh classiques — largement compensé par le gain de couverture obtenu sans effort d’instrumentation.

Est-ce compatible avec Kubernetes 1.37 ?

Oui, aucune contrainte de version particulière côté Kubernetes lui-même. Si tu viens de migrer, jette un œil à notre article sur les nouveautés de Kubernetes 1.37 pour vérifier qu’aucun changement ne touche tes DaemonSets privilégiés.

En résumé

OBI marque un vrai changement de philosophie pour l’observabilité : au lieu de courir après la couverture d’instrumentation service par service, tu pars d’une visibilité complète par défaut, et tu affines ensuite là où c’est utile. Teste-le sur un cluster non critique cette semaine, avec le DaemonSet ci-dessus — tu seras fixé en une heure sur ce qu’il t’apporte réellement.

Si ta facture d’observabilité augmente plus vite que ton infra elle-même, tu n’es pas seul. Entre l’explosion du volume de logs, la multiplication des outils et la pression pour réduire les coûts, 2026 marque un vrai tournant : Grafana 13, Prometheus 3 et la généralisation d’OpenTelemetry redessinent ce qu’une stack de monitoring moderne doit faire. Voici ce qui change concrètement, et comment en tirer parti sans tout réécrire du jour au lendemain.

Grafana 13 : de la donnée brute à l’action

Présentée à GrafanaCON 2026, cette version pousse Grafana au-delà du simple outil de visualisation, avec pour objectif de raccourcir le chemin entre une métrique et une décision :

• Tableaux de bord suggérés intégrant des méthodologies standard comme DORA (pour le delivery) et USE/RED (pour l’infra et les services), pour ne plus repartir d’une page blanche
• Tableaux de bord dynamiques qui s’adaptent au contexte et aux variables sélectionnées par l’utilisateur
• Workflows Git bidirectionnels avec gestion d’API versionnée, pour appliquer une vraie gouvernance (revue, historique, rollback) sur tes dashboards comme sur du code
• Un écosystème élargi à 170 sources de données et 120 panneaux de visualisation

Grafana revendique aujourd’hui 35 millions d’utilisateurs dans le monde — la plateforme n’est plus une simple couche de visualisation posée sur Prometheus, elle devient le point d’entrée unique pour l’exploitation au quotidien.

Loki repensé pour les gros volumes de logs

Le moteur de stockage de logs de Grafana a été retravaillé en profondeur pour tenir la charge des environnements modernes :

• Ingestion adossée à Kafka pour des pipelines plus durables et plus résilients aux pics
• Un planificateur de requêtes distribué qui exécute les analyses en parallèle
• Des gains annoncés de 10x sur les performances de requêtes agrégées, avec 20x moins de données scannées pour arriver au résultat

Concrètement, ça veut dire des requêtes de logs sur de larges fenêtres temporelles qui restent exploitables en interactif, là où elles auraient nécessité un job batch auparavant.

Prometheus 3 : OTLP natif et histogrammes natifs

Prometheus a lui aussi fait sa mue. Le changement le plus structurant pour les équipes qui utilisent OpenTelemetry : Prometheus embarque désormais un récepteur de métriques OTLP natif, sans passer par un exportateur intermédiaire.

# Activer la réception OTLP native dans prometheus.yml / au démarrage
prometheus --web.enable-otlp-receiver

# Les métriques OTLP sont alors acceptées directement sur :
# POST /api/v1/otlp/v1/metrics

Autres évolutions notables pour la migration :

• Support UTF-8 complet dans les noms de métriques et de labels par défaut (fini la conversion systématique des points en underscores, ce qui simplifie l’intégration avec des sources OpenTelemetry)
• Remote Write 2.0, qui transporte metadata, exemplars, timestamps de création et histogrammes natifs ensemble, avec interning de chaînes pour réduire la taille des payloads
• Une UI repensée façon PromLens, avec une vue arborescente qui décompose une requête PromQL en sa structure logique

Si tu migres depuis Prometheus 2.x (guide de migration officiel), passe d’abord par la version 2.55 : un rollback depuis la 3.0 n’est possible que vers cette version, pas plus loin en arrière. Vérifie aussi tes règles d’alerting utilisant des regex, puisque le matching inclut désormais les retours à la ligne.

OpenTelemetry devient le standard de facto

Tous les langages, plateformes et fournisseurs cloud majeurs supportent désormais OpenTelemetry nativement, ce qui élimine une bonne partie de l’instrumentation dupliquée qu’on devait maintenir manuellement il y a encore deux ou trois ans. Grafana accompagne ce mouvement avec Alloy, sa distribution de collecteur qui accepte une configuration YAML native OpenTelemetry, avec une installation en une seule commande sous Linux et un support renforcé de l’opérateur Kubernetes pour l’auto-instrumentation des workloads conteneurisés.

Les tendances à surveiller pour ta stratégie 2026

Une étude Grafana Labs menée auprès de 150 décideurs IT met en évidence plusieurs signaux à prendre en compte quand tu planifies ta stack :

• Valeur plutôt que volume : la télémétrie adaptative peut réduire le volume de données ingérées de 50 à 80 %, en ne conservant que les signaux réellement exploitables
• Consolidation encore difficile : 73 % des organisations ont adopté ou migrent vers une observabilité unifiée, mais seulement 14 % jugent leur consolidation « très réussie » — ne sous-estime pas l’effort de mise en cohérence entre équipes
• Les SLO sortent de la conformité : 86 % des équipes les utilisent déjà, et ils s’invitent de plus en plus dans la planification de sprint et les décisions business, pas seulement dans les rapports d’incident
• L’IA comme copilote : 84 % des organisations explorent l’IA en observabilité, avec un glissement progressif de l’assistance à la requête vers des agents capables d’investiguer un incident de façon autonome

FAQ

Faut-il migrer vers Prometheus 3 dès maintenant ?

Le moteur de stockage (TSDB) n’a pas changé, ce qui rend l’upgrade relativement sûr techniquement. Le vrai travail est de vérifier tes règles d’alerting et tes scrape configs avant de basculer, plutôt que d’attendre une contrainte externe pour t’y mettre.

OpenTelemetry remplace-t-il Prometheus et Grafana ?

Non, OpenTelemetry est un standard de collecte et de transport de la télémétrie (métriques, logs, traces), pas un outil de stockage ou de visualisation. Il vient en complément de Prometheus (stockage des métriques) et Grafana (visualisation), en simplifiant l’instrumentation en amont.

Par où commencer si on part de zéro ?

Instrumente avec OpenTelemetry dès le départ plutôt que des SDK propriétaires : tu gardes la liberté de changer de backend (Prometheus, Grafana Cloud, Datadog…) sans réinstrumenter ton code plus tard.

Pour aller plus loin

Une bonne stack d’observabilité ne vaut que si elle tourne sur une infra stable : si tu exploites Prometheus et Grafana sur Kubernetes, notre guide de sécurisation d’un cluster Kubernetes couvre les bases à ne pas négliger avant de brancher tes collecteurs. Et si tu veux automatiser le déploiement de ta stack de monitoring dans tes pipelines, jette un œil à notre article sur les nouveautés sécurité de GitHub Actions.