https://k8s-school.fr/labs/otel/fr/tags/opentelemetry/index.htmlHugofr-frCopyright (c) 2026 Fabrice Jammes - Licensed under CC BY-SA 4.0Wed, 08 Jul 2026 19:00:00 +0200https://k8s-school.fr/labs/otel/fr/0_prereqs/slides/index.htmlWed, 08 Jul 2026 19:00:00 +0200https://k8s-school.fr/labs/otel/fr/0_prereqs/slides/index.htmlLes diapositives de la formation, chapitre par chapitre : Chapitre 1 — Introduction Chapitre 2 — Instrumentation zero-code Chapitre 3 — Le collecteur Chapitre 4 — Grafana Chapitre 5 — Logs Chapitre 6 — Métriques Chapitre 7 — Traces Chapitre 8 — Sécurité & conformité Chapitre 9 — Framework Spring (facultatif) Chapitre 10 — Conclusionhttps://k8s-school.fr/labs/otel/fr/1_labs/10-otel-stack/index.htmlMon, 06 Jul 2026 09:00:00 +0200https://k8s-school.fr/labs/otel/fr/1_labs/10-otel-stack/index.htmlBienvenue dans l’équipe SRE de l’Astronomy Shop 🔭 — une boutique e-commerce composée d’une vingtaine de micro-services, instrumentée avec OpenTelemetry (démo officielle). Dans ce premier lab, entièrement guidé, vous démarrez la plateforme d’observabilité complète : le collecteur OpenTelemetry, Grafana, Jaeger (traces), Prometheus (métriques) et OpenSearch (logs), ainsi que la boutique elle-même et son générateur de trafic. 💡 Toute la stack tourne dans un cluster Kubernetes local (Kind). Kubernetes n’est pas le sujet de cette formation : toutes les commandes kubectl sont fournies, avec leur explication.https://k8s-school.fr/labs/otel/fr/1_labs/20-otel-zero-code/index.htmlMon, 06 Jul 2026 11:40:00 +0200https://k8s-school.fr/labs/otel/fr/1_labs/20-otel-zero-code/index.htmlL’équipe Java a livré review-service, un micro-service Spring Boot de gestion des avis produits (API REST + PostgreSQL). Il n’émet aucune télémétrie. Dans ce lab, vous allez le rendre observable sans toucher à son code, de deux manières : Partie 1 : avec l’agent Java OpenTelemetry (-javaagent) ; Partie 2 : avec le Spring Boot Starter OpenTelemetry (dépendance Maven). Le code du service est dans apps/review-service/. Le script ./scripts/deploy.sh fait tout le cycle : docker build → kind load → kubectl apply → attente du rollout. Pas de registry d’images : l’image est chargée directement dans le cluster Kind.https://k8s-school.fr/labs/otel/fr/1_labs/30-otel-collector/index.htmlMon, 06 Jul 2026 15:15:00 +0200https://k8s-school.fr/labs/otel/fr/1_labs/30-otel-collector/index.htmlLe collecteur OpenTelemetry est le cœur de la chaîne : il reçoit (receivers), transforme (processors) et exporte (exporters) la télémétrie. Dans ce lab, vous allez lire sa configuration réelle, puis l’enrichir pour collecter des métriques système (hostmetrics) et des métriques produit (PostgreSQL) — sans toucher aux applications. 💡 Dans la démo, le collecteur est déployé par Helm : modifier sa configuration = modifier les values du chart + helm upgrade. Pas de rebuild, pas de redéploiement manuel.https://k8s-school.fr/labs/otel/fr/1_labs/50-otel-logs/index.htmlMon, 06 Jul 2026 09:50:00 +0200https://k8s-school.fr/labs/otel/fr/1_labs/50-otel-logs/index.htmlreview-service écrit ses logs avec SLF4J/Logback, comme la plupart des applications Java. Dans ce lab, vous suivez le trajet complet d’un log : Logback → appender OpenTelemetry (injecté par l’agent) → OTLP → collecteur → OpenSearch — et surtout, vous exploitez la corrélation log ↔ trace. Prérequis Labs 1 à 3 terminés. Le port-forward des UIs actif (./scripts/open-ui.sh). Les variables de la formation chargées dans votre shell : . ./scripts/env.sh. Elles donnent le port du review-service ($APP_PORT, accès direct au service, pas via le frontend-proxy) ainsi que $PF_ADDR et $PF_HOST, l’adresse sur laquelle vos port-forward écoutent. Étapes Les logs « à l’ancienne » : kubectl logs -n otel-demo deployment/review-service --tail=20 kubectl logs lit la sortie console du conteneur : du texte brut, sans contexte, service par service. Impossible de croiser avec une trace.https://k8s-school.fr/labs/otel/fr/1_labs/60-otel-metrics/index.htmlMon, 06 Jul 2026 11:40:00 +0200https://k8s-school.fr/labs/otel/fr/1_labs/60-otel-metrics/index.htmlLe Lab 3 collectait des métriques d’infrastructure (système, PostgreSQL) ; le connector spanmetrics fournit déjà débit et latence par service. Il manque les métriques métier : combien d’avis créés ? En combien de temps ? Dans ce lab, vous instrumentez review-service avec Micrometer (un compteur + un histogramme), exportés vers Prometheus via l’agent OpenTelemetry, puis vous dérivez une métrique depuis les spans avec le connector count. Prérequis Labs 1 à 3 terminés, agent Java actif sur review-service (cf. Lab 5, étape 2). D’abord les variables de la formation chargées dans votre shell : . ./scripts/env.sh. Elles donnent le port du review-service ($APP_PORT, accès direct au service, pas via le frontend-proxy) ainsi que $PF_ADDR et $PF_HOST, l’adresse sur laquelle vos port-forward écoutent. Ensuite seulement le port-forward Prometheus, qui s’appuie sur ces variables : kubectl port-forward -n otel-demo --address $PF_ADDR svc/prometheus $PROM_PORT:9090 & Étapes Partie 1 — Compteur et histogramme dans le code Lire l’instrumentation Micrometer dans apps/review-service/src/main/java/fr/k8sschool/reviews/ReviewController.java : this.reviewsCreated = Counter.builder("reviews.created") .description("Number of product reviews created") .register(registry); this.reviewCreationTimer = Timer.builder("reviews.creation.time") .description("Time spent creating a review (catalog check + insert)") .publishPercentileHistogram() .register(registry); Pourquoi Micrometer plutôt que le SDK OpenTelemetry directement ?https://k8s-school.fr/labs/otel/fr/1_labs/70-otel-traces/index.htmlMon, 06 Jul 2026 14:55:00 +0200https://k8s-school.fr/labs/otel/fr/1_labs/70-otel-traces/index.htmlL’instrumentation automatique (Lab 2) trace les frontières techniques (HTTP, SQL). Pour tracer la logique métier, on crée des spans manuels. Dans ce lab : un span manuel via annotation, la propagation de contexte vers un autre service, le bagage, puis la maîtrise du volume avec le tail sampling. Prérequis Labs 1 à 6 terminés, agent Java actif sur review-service. Port-forward UIs actif (./scripts/open-ui.sh). Les variables de la formation chargées dans votre shell : . ./scripts/env.sh. Elles donnent le port du review-service ($APP_PORT, accès direct au service, pas via le frontend-proxy) ainsi que $PF_ADDR et $PF_HOST, l’adresse sur laquelle vos port-forward écoutent. Étapes Partie 1 — Spans manuels & propagation Lire l’instrumentation manuelle dans ProductCatalogClient.java : @WithSpan("product-catalog.lookup") public void checkProductExists(@SpanAttribute("app.product.id") String productId) { ... Span.current().setAttribute("app.product.found", true); et dans ReviewController.java (le bagage) :https://k8s-school.fr/labs/otel/fr/1_labs/80-otel-security/index.htmlMon, 06 Jul 2026 16:20:00 +0200https://k8s-school.fr/labs/otel/fr/1_labs/80-otel-security/index.htmlLa télémétrie est un canal de fuite : tokens, mots de passe, emails s’y retrouvent trop facilement — et un backend d’observabilité est rarement protégé comme la base de production. Dans ce lab, vous constatez une fuite réelle (déjà dans le code de review-service…), puis vous la neutralisez à deux niveaux : dans le SDK de l’application et, en filet de sécurité, dans le collecteur. 🇪🇺 RGPD : email, nom, téléphone sont des données personnelles. Leur présence dans les traces/logs crée les mêmes obligations (droit à l’effacement, rétention…) que dans une base — dans un système conçu pour tout garder.