Quand Grafana Labs rend l’observabilité ludique à la KubeCon EU 2025

Adrien Paysant 08 avr. 2025

L’observabilité est un besoin fondamental de tout système/application qui entend avoir une production exploitable. Comprendre ce qui se passe dans un système distribué, le diagnostiquer, anticiper ses dérives : autant de tâches qui reposent sur des signaux comme les logs, les métriques et les traces. Mais bien que ces outils soient puissants, ils restent souvent abstraits et trop peu priorisés.

À la KubeCon EU 2025, Grafana Labs a relevé le défi de rendre ces concepts accessibles, concrets et même amusants ! Avec leur conférence “Logs, Metrics, Traces and Mayhem”, Jay CLIFFORD et Tom GLENN ont présenté une démonstration interactive sous forme de jeu textuel, construite autour d’une stack Grafana complète et instrumentée avec OpenTelemetry. Revenons sur cette présentation ludique.

1. OpenTelemetry et la stack Grafana : fondations d’une observabilité cloud-native

L’observabilité n’est pas simplement un monitoring "amélioré" ou plus complet. Il s'agit d’un changement de paradigme : on ne se contente plus de surveiller des symptômes connus, on veut pouvoir expliquer le comportement d’un système à partir de ce qu’il émet.

Autrement dit :

Le monitoring s’appuie sur des métriques statiques définies à l’avance (CPU, latence, taux d’erreurs), souvent liées à des alertes connues.
L’observabilité, elle, repose sur la capacité à poser des questions ad hoc sur un système sans modifier son code ni redéployer. C’est une propriété émergente du système, rendue possible grâce à la qualité et à la richesse des signaux qu’il émet.

Cela devient crucial dans des architectures modernes, distribuées, où les bugs ne sont plus des exceptions mais des interactions imprévues entre composants. Quand un service appelle un autre via gRPC, qui publie dans Kafka, qui déclenche une fonction Lambda qui appelle une API tierce dont on veut tracer le webhook auprès d’un autre backend 🤯… la compréhension des flux d’exécution nécessite un outillage compétent.

C’est ici qu’intervient OpenTelemetry:

OpenTelemetry : standardiser l’émission des signaux d’observabilité

OpenTelemetry (OTel) est une boîte à outils open-source développée sous l’égide de la CNCF. Sa mission : fournir un standard unifié pour produire, collecter et exporter trois signaux clés de l’observabilité :

Les traces distribuées, qui permettent de reconstruire le parcours d’une requête à travers les services.
Les métriques, pour quantifier des comportements (temps de réponse, nombre d’objets en cache, etc.).
Les logs, pour conserver des informations précises sur les événements contextuels.

Depuis peu, OpenTelemetry étend son champ à un quatrième signal émergent : le profiling, c’est-à-dire la capture de données d’exécution (CPU, mémoire, allocation d’objets…) dans des environnements réels.

Une architecture modulaire : SDK, Collector, OTLP

OpenTelemetry s’organise autour de trois éléments clés :

Des SDK clients disponibles pour la majorité des langages utilisés en production (Go, Java, Python, .NET…). Ils permettent d’instrumenter les applications, manuellement ou via autoinstrumentation.
Un Collector, composant central qui reçoit les signaux via divers protocoles (OTLP, Jaeger, Zipkin, Prometheus), les transforme (filtrage, enrichissement, agrégation) et les exporte vers des backends comme Tempo, Loki, Prometheus ou Elasticsearch.
Un protocole standardisé, OTLP (OpenTelemetry Protocol), basé sur gRPC/HTTP, assurant un transport performant et extensible des signaux.

Cette modularité permet de découpler la production de la consommation des données. On peut par exemple changer de backend sans modifier le code applicatif, ou mutualiser la collecte entre plusieurs langages et frameworks.

Pourquoi OpenTelemetry change la donne

Ce qui rend OTel structurant, ce n’est pas seulement sa compatibilité large ou son design modulaire. C’est qu’il permet de résoudre plusieurs problèmes dans les systèmes observables :

Éviter le vendor lock-in : on peut envoyer ses données vers Grafana Tempo aujourd’hui, Datadog demain, ou Jaeger, sans changer le code.
Réduire la dette d’observabilité : plus besoin d’avoir un agent pour les logs, un SDK maison pour les traces, un exporter Prometheus à part. OTel fournit une stack complète et cohérente.
Faciliter le travail multi-équipes : les conventions OTel sur les noms de services, de span, les attributs, rendent les données interopérables et comparables.
Uniformiser l’observabilité dans des architectures polyglottes : un service en Go, un autre en Python et un troisième en Rust peuvent tous exposer les mêmes types de signaux, avec la même structure.

2. Une aventure d’observabilité interactive : le jeu Grafana Labs

Lors de leur conférence à Londres, Jay Clifford et Tom Glenn de Grafana Labs ont présenté un jeu baptisé “adventure”, entièrement conçu pour illustrer comment on peut observer, diagnostiquer et comprendre un système - ici, un monde d’heroic fantasy numérique.

L’architecture du jeu est simple, mais ingénieuse.

Chaque action dans le jeu (lancer un sort, affronter un monstre, réparer une forge) déclenche un événement logiciel accompagné de logs, métriques ou traces.

Le jeu est open source (disponible ici) et déployable localement. Il s’agit d’une application Web textuelle, avec un backend instrumenté et une stack d’observabilité complète.

OpenTelemetry trouve une application particulièrement efficace dans cette stack qui s’articule autour de trois composants clés :

Prometheus pour la collecte et le stockage des métriques ;
Tempo pour la gestion des traces distribuées ;
Loki pour l’agrégation et l’analyse des logs.

Chacun de ces outils est nativement compatible avec OpenTelemetry, notamment via le protocole OTLP ou le Collector (Grafana Alloy ici). Cela permet de construire une chaîne d’observabilité de bout en bout : instrumentation dans le code → ingestion/transformation dans le Collector → visualisation dans Grafana dont voici un exemple :

Ici la trace correspond à un cycle de jeu complet d’un utilisateur :

Notons que le setup grafana fourni permet aussi de voir les traces.

Ce jeu n’est pas qu’une manière d’amuser 500 devops lors d’une conférence. Il propose une expérience pédagogique forte pour comprendre concrètement l’intérêt d’une observabilité bien faite. Chaque événement devient une étude de cas technique miniature. C’est un moyen amusant et pertinent de sensibiliser à l’observabilité dans des équipes produit non techniques. Le jeu montre aussi comment construire une application observable dès sa conception : les bonnes pratiques OTel y sont appliquées dès le départ.

Conclusion : rendre l’observabilité humaine, interactive et mémorable

Ce que Grafana Labs démontre avec ce jeu interactif, c’est que l’observabilité ne doit pas rester un sujet réservé aux SRE. En la rendant concrète, accessible et même ludique, ils réussissent à transmettre une vision fondamentale : comprendre son système est un prérequis à sa maîtrise. OpenTelemetry fournit aujourd’hui les briques nécessaires pour construire cette compréhension : une instrumentation cohérente, standardisée, multi-langage, interopérable. Combinée à une stack comme celle de Grafana (Tempo, Loki, Prometheus), elle permet de corréler les signaux, de remonter aux causes profondes, et de bâtir une observabilité réellement exploitable. Ce jeu n’est pas juste une démo : c’est une métaphore du quotidien de nos systèmes modernes. Chaotiques, distribués, imprévisibles… mais analysables, traçables, compréhensibles — à condition d’avoir les bons outils et les bons réflexes.

PS: il faut 2 minutes pour lancer le jeu alors n’hésitez pas (il y a même un killer coda) !

-> https://github.com/grafana/adventure?tab=readme-ov-file#run-with-docker

Sources: