L’observabilité est devenue un pilier incontournable de l’ingénierie moderne. Sans visibilité sur ce qui se passe réellement dans vos systèmes, chaque incident devient une enquête à l’aveugle et chaque déploiement un pari. La stack Grafana, Prometheus et Loki constitue aujourd’hui la combinaison open source la plus adoptée pour construire une observabilité complète : métriques, logs et dashboards réunis dans un environnement cohérent, extensible et particulièrement bien adapté aux architectures conteneurisées.
Qu’est-ce que l’observabilité et pourquoi elle diffère du monitoring
Le monitoring traditionnel consiste à surveiller des indicateurs connus à l’avance : CPU, mémoire, disponibilité d’un service. L’observabilité va beaucoup plus loin en vous permettant de comprendre l’état interne d’un système uniquement à partir de ses sorties externes, sans avoir à anticiper chaque scénario de panne possible. C’est une différence fondamentale qui change profondément la façon dont les équipes réagissent aux incidents.
Un système observable émet trois types de signaux : les métriques (valeurs numériques agrégées dans le temps), les logs (événements textuels horodatés) et les traces (chaînes d’appels entre services). La stack GPL — Grafana, Prometheus, Loki — couvre les deux premiers piliers de manière native, avec la possibilité d’intégrer Tempo pour les traces distribuées et compléter ainsi un dispositif d’observabilité complet.
L’adoption de cette approche se traduit concrètement par des Mean Time To Detect et Mean Time To Resolve significativement réduits. Les équipes qui instrumentent correctement leurs applications avec Prometheus et centralisent leurs logs dans Loki rapportent régulièrement des gains de 60 à 80 % sur le temps de diagnostic des incidents critiques. Ce n’est pas un luxe réservé aux grandes entreprises — c’est une nécessité pour tout projet en production.
Prometheus : l’architecture pull et le modèle de données en time series
Prometheus fonctionne selon un modèle pull : il scrape régulièrement les endpoints HTTP de vos applications et services pour y collecter les métriques exposées. Cette approche inverse la logique push traditionnelle et présente plusieurs avantages majeurs : vous savez exactement quand une cible devient injoignable, la configuration est centralisée côté Prometheus plutôt que dispersée dans vos applications, et le débogage de la collecte devient trivial.
Le modèle de données de Prometheus est basé sur les time series, chacune identifiée par un nom de métrique et un ensemble de labels clé-valeur. Par exemple, http_requests_total{method= »GET », status= »200″, handler= »/api/users »} représente une série distincte. Cette granularité permet des requêtes PromQL extrêmement précises : vous pouvez calculer le taux de requêtes par endpoint, filtrer par code de statut, comparer les performances entre différentes instances d’un service.
La rétention des données dans Prometheus est configurable mais limitée à quelques semaines par défaut, car le stockage local n’est pas conçu pour le long terme. Pour la rétention longue durée, on intègre généralement Thanos ou Cortex, qui ajoutent une couche de stockage objet compatible S3. Dans de nombreux projets de taille raisonnable cependant, quelques semaines de métriques suffisent amplement pour identifier les tendances de performance.
Déploiement Docker Compose pour un environnement local
La façon la plus rapide de tester la stack complète est de la déployer en local avec Docker Compose. Le fichier ci-dessous orchestre Prometheus, Grafana, Loki et Promtail — l’agent responsable de la collecte et du transfert des logs vers Loki. En moins de cinq minutes, vous disposez d’un environnement fonctionnel accessible via le navigateur pour explorer les interfaces respectives de chaque composant.
Une fois les conteneurs démarrés avec docker compose up -d, Grafana est accessible sur le port 3000 et Prometheus sur le port 9090. La première étape consiste à ajouter Prometheus et Loki comme sources de données dans Grafana via l’interface Configuration > Data sources. Utilisez les noms des services Docker comme hostnames — par exemple http://prometheus:9090 — car les conteneurs communiquent sur le réseau interne de Compose.
Pour la production, Docker Compose sera remplacé par des manifests Kubernetes ou des Helm charts officiels fournis par Grafana Labs. Les charts grafana/grafana, prometheus-community/prometheus et grafana/loki-stack sont les références standard. Ils incluent des configurations de production prêtes à l’emploi avec persistence des données, ressources CPU/mémoire ajustables et support des secrets Kubernetes.
version: "3.8"
services:
prometheus:
image: prom/prometheus:latest
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
ports:
- "9090:9090"
grafana:
image: grafana/grafana:latest
ports:
- "3000:3000"
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin
loki:
image: grafana/loki:latest
ports:
- "3100:3100"
promtail:
image: grafana/promtail:latest
volumes:
- /var/log:/var/log
- ./promtail-config.yml:/etc/promtail/config.yml
Loki : agrégation de logs sans indexation complète
Loki adopte une philosophie radicalement différente d’Elasticsearch pour la gestion des logs : au lieu d’indexer le contenu complet de chaque ligne, Loki n’indexe que les labels associés à un flux de logs (stream). Le contenu textuel des logs est compressé et stocké tel quel, sans parsing ni indexation. Cette approche réduit considérablement les coûts de stockage et la complexité opérationnelle, au prix d’une vitesse de recherche plein texte légèrement inférieure.
Les logs arrivent dans Loki via des agents comme Promtail, Alloy ou Fluentd. Promtail est l’agent officiel le plus simple à configurer : il lit les fichiers de logs sur le système, les associe à des labels (pod Kubernetes, namespace, application, environnement), et les envoie à Loki. La configuration de Promtail ressemble beaucoup à celle de Prometheus — un fichier YAML définissant les cibles à scraper et les règles de labellisation.
Le langage de requête LogQL de Loki est inspiré de PromQL et permet des opérations puissantes sur les logs : filtrage par labels, expressions régulières sur le contenu, extraction de métriques à partir de logs (metric queries), et calculs d’agrégation. Une requête comme {app= »nginx »} |= « ERROR » | rate() permet par exemple de calculer le taux d’erreurs Nginx en temps réel directement depuis les logs, sans avoir besoin d’une métrique Prometheus dédiée.
Grafana : dashboards, alerting et Explore
Grafana est l’interface de visualisation qui donne du sens à toutes les données collectées. Sa puissance réside dans sa flexibilité : un même dashboard peut combiner des panels Prometheus (métriques), Loki (logs) et Tempo (traces), permettant une vision unifiée d’un incident. Les dashboards sont définis en JSON et peuvent être versionnés dans Git, ce qui facilite leur gestion dans les équipes.
La fonctionnalité Explore est particulièrement précieuse pour le debugging ad hoc. Elle permet d’interroger directement les sources de données sans avoir à créer un dashboard : vous écrivez une requête PromQL ou LogQL et le résultat s’affiche immédiatement. La corrélation entre métriques et logs est intégrée — depuis un pic de latence dans un graphe Prometheus, vous pouvez basculer directement vers les logs Loki correspondant à la même période.
Le système d’alerting de Grafana a été complètement refait dans les versions récentes. Grafana Alerting unifie les règles d’alerte pour toutes les sources de données dans une interface centralisée, avec support des groupes de contact, des silences et des politiques de routage sophistiquées. Il remplace avantageusement Alertmanager de Prometheus pour les équipes qui souhaitent tout gérer depuis Grafana sans jongler entre plusieurs interfaces.
Instrumentation applicative avec les client libraries Prometheus
Pour que vos applications exposent des métriques Prometheus, vous devez les instrumenter avec une bibliothèque cliente adaptée à votre langage. Les bibliothèques officielles existent pour Go, Python, Java, Ruby et Node.js. Pour une application Node.js Express par exemple, prom-client permet d’exposer en quelques lignes un endpoint /metrics avec les métriques par défaut (CPU, mémoire, event loop) plus vos métriques métier personnalisées.
Les quatre types de métriques Prometheus couvrent la plupart des besoins : Counter (valeur toujours croissante, comme le nombre de requêtes), Gauge (valeur qui peut monter et descendre, comme la mémoire utilisée), Histogram (distribution de valeurs avec buckets configurables, idéal pour les latences) et Summary (similaire à Histogram avec des quantiles calculés côté client). Le choix du bon type impacte directement la qualité de vos dashboards.
L’instrumentation des endpoints HTTP constitue le minimum vital pour tout projet web. Comptez au moins : le nombre de requêtes par route et code de statut, la latence par percentile (p50, p95, p99), et le nombre d’erreurs. Ces trois indicateurs forment les RED metrics (Rate, Errors, Duration), recommandées par Tom Wilkie de Grafana Labs comme base de toute stratégie d’observabilité pour les microservices.
Configuration des alertes et intégration PagerDuty ou Slack
Une stack d’observabilité sans alertes correctement configurées n’a qu’une utilité partielle. L’objectif est de recevoir une notification dès qu’un seuil critique est dépassé, avant même que les utilisateurs ne rapportent un problème. Grafana Alerting permet de définir des règles basées sur des requêtes PromQL ou LogQL, avec des seuils d’alerte et des périodes d’évaluation configurables pour éviter les faux positifs.
Les canaux de notification disponibles dans Grafana incluent Slack, PagerDuty, OpsGenie, email, webhook générique et bien d’autres. L’intégration Slack est particulièrement populaire en équipe : chaque alerte déclenche un message dans un canal dédié avec le nom de la règle, les valeurs courantes et un lien direct vers le dashboard concerné. Les alertes peuvent être regroupées par équipe ou par criticité grâce aux politiques de routage.
La gestion des silences est essentielle pour éviter l’alert fatigue lors des maintenances planifiées. Grafana permet de créer des silences temporaires qui suppriment les notifications pour des alertes spécifiques pendant une fenêtre de temps définie. Une bonne pratique consiste à créer systématiquement un silence avant chaque déploiement de production et à le supprimer une fois la stabilité confirmée, généralement 15 à 30 minutes après le déploiement.
Passage à l’échelle et bonnes pratiques production
En production avec de nombreux services, quelques principes de labellisation deviennent critiques. Les labels Prometheus doivent rester à cardinalité faible — évitez d’utiliser des identifiants uniques comme des user_id ou des request_id comme labels, car cela crée des milliers de time series distinctes et explose la mémoire de Prometheus. Préférez des labels stables comme env, service, instance et region.
Pour Loki en production, la configuration des limites (limits_config) est indispensable : taille maximale des streams, débit d’ingestion par tenant, nombre maximal de séries actives. Sans ces limites, un service qui log massivement peut saturer l’ensemble du cluster Loki. La compression des chunks (snappy par défaut, zstd disponible) et le stockage objet S3-compatible permettent d’atteindre des coûts de stockage des logs très inférieurs à ceux d’une solution Elasticsearch.
La stack GPL s’intègre nativement dans les environnements Kubernetes grâce aux annotations de scraping Prometheus. En annotant vos pods avec prometheus.io/scrape: « true » et prometheus.io/port: « 8080 », le Discovery automatique de Prometheus détecte et scrape vos applications sans configuration manuelle supplémentaire. Cette approche dynamique est particulièrement adaptée aux déploiements avec autoscaling horizontal, où le nombre d’instances varie constamment.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.