Kubernetes en production sans observabilité, c’est conduire sans tableau de bord : vous avancez, mais vous ne savez ni à quelle vitesse, ni si le moteur va lâcher. En 2026, l’observabilité est passée de ‘nice to have’ à prérequis absolu pour tout cluster Kubernetes sérieux. L’émergence d’OpenTelemetry comme standard de l’industrie pour l’instrumentation, la maturité de la stack Prometheus + Grafana, et l’arrivée de Grafana Alloy comme collecteur universel ont simplifié considérablement la mise en place d’une observabilité complète. Ce guide couvre les fondamentaux et les configurations avancées pour les environnements de production.
Les trois piliers de l’observabilité : métriques, logs, traces
L’observabilité repose sur trois types de données complémentaires. Les **métriques** sont des mesures numériques agrégées dans le temps (CPU à 85%, 1200 requêtes/sec, latence P99 à 250ms). Elles permettent de détecter des anomalies et de poser des alertes sur des seuils. Les **logs** sont des événements textuels horodatés (‘Erreur de connexion à la base de données pour l’utilisateur user123 à 14:35:22’). Ils fournissent le contexte détaillé d’un incident. Les **traces** représentent le chemin d’une requête à travers les microservices (request A → service Auth → service User → base de données → réponse, avec le temps passé à chaque étape).
La corrélation entre ces trois piliers est la vraie valeur de l’observabilité. Un dashboard Grafana montre une spike de latence à 14h35. Vous cliquez sur le point de spike pour voir les logs correspondants dans Loki — une erreur de connexion DB apparaît. Vous cliquez sur un trace ID dans le log pour voir la trace Tempo et identifier exactement quelle requête SQL bloque. En moins de 30 secondes, vous avez localisé le problème précis. Sans corrélation, ces trois investigations seraient indépendantes et prendraient 20 à 30 minutes chacune.
OpenTelemetry (OTel) est le standard CNCF qui unifie la collecte de métriques, logs et traces dans un protocole unique (OTLP). En 2026, la quasi-totalité des nouveaux projets d’observabilité utilisent OpenTelemetry pour l’instrumentation. L’avantage majeur : changez de backend (de Jaeger à Tempo, de Prometheus à Cortex) sans réécrire votre code d’instrumentation. L’OpenTelemetry Collector est un proxy qui reçoit les données OTel et les route vers les backends de votre choix.
Prometheus en production : configuration et bonnes pratiques
Prometheus scrape les métriques de vos applications et services à intervalles réguliers (défaut 15 secondes). Chaque service expose un endpoint `/metrics` en format Prometheus (texte lisible). Le kube-prometheus-stack (Helm chart) déploie Prometheus, les exporters pour Kubernetes (node-exporter, kube-state-metrics), et Grafana avec des dashboards préconfigurés en quelques commandes. C’est le point de départ recommandé pour tout cluster Kubernetes.
La rétention et le stockage sont les défis principaux de Prometheus en production. Prometheus stocke les données localement dans une base TSDB — par défaut 15 jours de rétention. Pour de la longue durée (90 jours, 1 an), vous avez besoin d’un stockage externe. Thanos et Cortex sont les deux solutions de référence pour Prometheus en haute disponibilité et longue rétention. Ils utilisent du stockage objet (S3, GCS, Azure Blob) pour les données historiques et permettent la déduplication entre instances Prometheus redondantes.
Les alertes Prometheus via AlertManager sont la colonne vertébrale de votre on-call. Définissez des alertes en Prometheus Recording Rules et Alerting Rules dans des fichiers YAML versionés dans Git. Les bonnes pratiques : alerte sur les symptômes (latence élevée, taux d’erreur élevé, SLO en danger) plutôt que sur les causes (CPU élevé, mémoire élevée — pas forcément un problème) ; utilisez des ‘inhibition rules’ pour éviter les orages d’alertes (si le cluster est down, ne pas alerter sur chaque service individuel) ; et testez vos alertes en production avec des défaillances simulées (Chaos Engineering).
# AlertManager — alerte sur le taux d'erreur HTTP 5xx
groups:
- name: http-errors
rules:
- alert: HighErrorRate
expr: |
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0.05
for: 5m
labels:
severity: critical
annotations:
summary: 'Taux d erreur HTTP 5xx > 5% depuis 5 minutes'
description: 'Taux actuel: {{ $value | humanizePercentage }}'Grafana Loki pour les logs Kubernetes
Grafana Loki est la solution de logs recommandée pour les environnements Kubernetes — léger, économique en stockage (ne parse pas les logs au stockage, seulement à la requête), et nativement intégré avec Grafana. Loki utilise le même modèle de labels que Prometheus : un log stream est identifié par ses labels (`{namespace=’production’, app=’api’, pod=’api-7d9f6b4c8-xk2p1′}`). La query language LogQL permet de filtrer et d’agréger les logs de manière expressive.
La collecte des logs Kubernetes avec Promtail (l’agent Loki pour Kubernetes) ou Grafana Alloy (son successeur) est configurée en DaemonSet — un agent sur chaque nœud collecte les logs de tous les pods du nœud. Les logs sont automatiquement enrichis avec les labels Kubernetes (namespace, pod, container, node) permettant le filtrage granulaire. Pour les logs d’application structurés (JSON), Loki peut extraire des champs additionnels via les pipelines de parsing LogQL.
L’intégration Loki-Grafana permet de naviguer directement depuis une trace Grafana Tempo ou une métrique Prometheus vers les logs correspondants via le ‘Explore’ de Grafana. Cette corrélation nécessite que vos traces incluent un champ `trace_id` et que vos logs incluent ce même `trace_id` — ce que OpenTelemetry fait nativement quand votre application est instrumentée avec le SDK OTel. La corrélation métriques-logs-traces complète est le Saint Graal de l’observabilité, maintenant accessible sans infrastructure complexe.
OpenTelemetry : instrumenter votre code pour la production
L’instrumentation auto-instrumentée est le chemin le plus rapide vers l’observabilité. Les SDKs OpenTelemetry pour Python, Java, Node.js, Go et .NET incluent des ‘auto-instrumentations’ qui capturent automatiquement les traces des bibliothèques populaires (Django, Flask, FastAPI, Spring, Express, gRPC) sans modifier votre code. En démarrant votre application avec l’agent OTel (`OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317 opentelemetry-instrument python app.py`), vous obtenez des traces complètes en quelques minutes.
L’instrumentation manuelle permet d’ajouter du contexte métier à vos traces. `tracer.start_as_current_span(‘calculate-pricing’, attributes={‘user.tier’: ‘premium’, ‘cart.items’: 12})` crée un span custom dans votre trace avec des attributs métier qui n’existent pas dans l’instrumentation auto. Ces attributs permettent de filtrer les traces par dimension business (toutes les requêtes pour des clients premium ayant plus de 10 articles dans le panier) — essentiel pour diagnostiquer des problèmes qui ne touchent qu’un segment d’utilisateurs.
Le sampling est critique pour la gestion des coûts en production. Collecter 100% des traces sur un service à 10 000 requêtes/seconde génère des volumes ingérables. Le ‘Head-based sampling’ (décider au début de la requête si elle est tracée) est simple mais perd des traces d’erreurs. Le ‘Tail-based sampling’ (décider après la complétion de la requête) permet de toujours capturer les requêtes lentes ou en erreur. OpenTelemetry Collector supporte le tail-based sampling via le processeur `tailsamplingprocessor` — configurez 100% de sampling pour les erreurs et 5% pour les requêtes normales.
SLOs et SLAs en production Kubernetes : définir et automatiser les objectifs de fiabilité
Les SLO (Service Level Objectives) sont des engagements quantifiés de fiabilité (‘99,9% de requêtes répondues en moins de 500ms par mois’) que votre équipe se fixe pour chaque service critique. Ils sont mesurés en continu via des ‘Error Budgets’ : si votre SLO est 99,9% de disponibilité mensuelle, vous avez un budget d’erreur de 43 minutes d’indisponibilité par mois. Quand le budget est épuisé, vous stoppez les déploiements risqués jusqu’au mois suivant — c’est une règle de gouvernance technique rationnelle.
Prometheus + Grafana rendent les SLOs opérationnels avec les ‘Recording Rules’ et les tableaux de bord dédiés. Définissez vos SLIs (Service Level Indicators — les métriques qui mesure l’expérience utilisateur : taux de succès HTTP, latence P99) sous forme de Prometheus Recording Rules qui calculent en continu le burn rate de votre error budget. Un burn rate > 1 signifie que vous consumez votre budget trop vite et devez agir. Grafana Labs propose des dashboards SLO prêts-à-l’emploi dans son catalogue.
Le ‘Sloth’ framework (open source) génère automatiquement les Recording Rules et Alerting Rules Prometheus à partir d’une spécification SLO en YAML. Plutôt que d’écrire manuellement des dizaines de règles Prometheus complexes, vous déclarez votre SLO en quelques lignes YAML et Sloth génère les règles multiburn-rate standards (alertes à 1h, 6h et 3 jours de horizon) recommandées par le SRE Book de Google.
# Spécification SLO avec Sloth (YAML → Prometheus Rules)
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
name: api-disponibilite
namespace: monitoring
spec:
service: 'api-gateway'
slos:
- name: 'requetes-correctes'
objective: 99.9 # 99.9% de disponibilité
description: 'Moins de 0.1% de requêtes en erreur'
sli:
events:
error_query: |
sum(rate(http_requests_total{job='api',code=~'5..'}[{{.window}}]))
total_query: |
sum(rate(http_requests_total{job='api'}[{{.window}}]))
alerting:
name: ApiHautTauxErreur
page_alert:
labels: {severity: critical}
ticket_alert:
labels: {severity: warning}Grafana Tempo et le tracing distribué en production
Grafana Tempo est le backend de traces distribués recommandé pour les environnements Kubernetes en 2026. Contrairement à Jaeger qui requiert Elasticsearch ou Cassandra, Tempo stocke les traces directement dans du stockage objet (S3, GCS, Minio) — moins cher et plus scalable pour les gros volumes. Tempo accepte les traces au format Jaeger, Zipkin ou OTLP, ce qui facilite la migration depuis d’autres backends.
Déployé avec Helm (`helm install tempo grafana/tempo-distributed`), Tempo s’intègre nativement dans Grafana comme datasource. La fonctionnalité ‘TraceQL’ (le query language de Tempo, introduit en 2024) permet des requêtes avancées sur les traces : `{span.http.status_code = 500 && duration > 2s}` filtre les spans HTTP en erreur prenant plus de 2 secondes. Pour le debugging d’incidents, cette précision de requête est indispensable.
La corrélation Loki-Tempo dans Grafana est le cas d’usage qui change réellement le quotidien des équipes ops. Depuis un log Loki qui contient un `trace_id`, un clic ouvre directement la trace Tempo correspondante dans l’UI Grafana. Depuis la trace Tempo, un clic sur un span ouvre les logs Loki de ce service pendant la durée du span. Cette navigation bidirectionnelle entre logs et traces réduit le temps moyen de diagnostic (MTTR) de 40 à 60% selon les équipes qui l’ont implémentée.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.