L’observabilité moderne repose sur trois piliers : les métriques (what is broken), les logs (why it’s broken) et les traces distribuées (where it’s broken). En 2026, la stack Grafana Labs — Prometheus pour les métriques, Loki pour les logs, Tempo pour les traces, le tout unifié dans Grafana — est devenue la référence open source pour les équipes qui veulent éviter le vendor lock-in des solutions cloud (Datadog, New Relic, Dynatrace). Ce guide couvre le déploiement complet et la configuration pratique.
Architecture de la stack PLG (Prometheus + Loki + Grafana)
La stack PLG est souvent présentée comme une alternative à ELK (Elasticsearch + Logstash + Kibana) pour les logs, avec l’avantage d’une consommation de ressources drastiquement inférieure. Loki n’indexe pas le contenu des logs — uniquement les labels (metadata comme l’application, l’environnement, le namespace Kubernetes). Cette approche réduit les coûts de stockage et d’indexation de 90 % sur les volumes importants, au prix de recherches full-text moins performantes sur les logs non labellisés.
Prometheus est le composant de collecte de métriques. Il scrape les endpoints /metrics exposés par vos applications (instrumentation OpenMetrics/Prometheus) et les infrastructures (via des exporters : node_exporter pour les serveurs, kube-state-metrics pour Kubernetes, mysqld_exporter pour MySQL…). La retention par défaut de 15 jours en local peut être étendue via Thanos ou Cortex pour un stockage long terme en object storage (S3, GCS).
Tempo est le composant de tracing distribué, compatible avec les formats OpenTelemetry, Jaeger, Zipkin et Zipkin. Il stocke les traces en object storage (S3 ou GCS) avec un index minimal pour la recherche par trace_id. La recherche par attribut (TraceQL) est disponible depuis Tempo 2.0. L’intégration avec Loki via l’automatic log correlation (les logs incluent un trace_id, Grafana propose un lien direct vers la trace correspondante) est particulièrement puissante pour le debugging.
Déploiement avec Docker Compose (environnement dev/staging)
Pour un environnement de développement ou de staging, Docker Compose est le moyen le plus rapide de déployer toute la stack. Le dépôt officiel grafana/docker-otel-lgtm fournit un docker-compose.yml prêt à l’emploi avec Grafana, Prometheus, Loki, Tempo et un OpenTelemetry Collector configuré pour recevoir des données. Ce point de départ est idéal pour expérimenter avant de déployer en production.
La configuration Loki minimale en mode local (sans object storage) utilise le système de fichiers pour stocker les chunks. Cette configuration est suffisante pour traiter jusqu’à 10 Go de logs par jour sur un serveur correctement dimensionné. Pour aller au-delà, passez en mode ‘simple scalable’ ou ‘microservices’ avec object storage S3 — la documentation officielle de Loki couvre cette transition en détail.
Promtail est l’agent de collecte de logs pour Loki. Il lit les logs des fichiers locaux (journald, /var/log, fichiers applicatifs) et les envoie vers Loki avec les labels appropriés. Sur Kubernetes, Promtail tourne comme DaemonSet pour collecter les logs de tous les pods automatiquement. La configuration des pipelines de parsing (extraction de champs depuis les logs, transformation des niveaux de log) est la partie la plus technique de la configuration Promtail.
Configuration Prometheus et AlertManager
Prometheus est configuré via son fichier prometheus.yml qui définit les scrape_configs (quoi scraper, à quelle fréquence) et les alerting rules (conditions déclenchant des alertes). La fréquence de scrape par défaut est 15 secondes — un bon compromis entre granularité et charge serveur. Pour les métriques critiques (disponibilité, taux d’erreur), descendez à 5 secondes. Pour les métriques de tendance (utilisation disque, croissance de la mémoire), 60 secondes est suffisant.
AlertManager gère le routage et la déduplication des alertes générées par Prometheus. Sa configuration definit les receivers (email, Slack, PagerDuty, OpsGenie), les routes (quelle alerte va où), et les inhibition rules (pas d’alerte mémoire si le serveur est déjà en alerte critique). Le concept de ‘grouping’ est puissant : AlertManager regroupe les alertes similaires (par exemple, tous les pods du même déploiement en erreur) en une seule notification plutôt que d’envoyer 50 alertes pour 50 pods.
Les alertes Prometheus utilisent PromQL, le langage de requête de Prometheus. Les règles d’alerte courantes à implémenter en priorité : disponibilité service seuil (basé sur les histogrammes de durée de requête), utilisation CPU > 80 % sustained sur 5 minutes, utilisation disque > 85 %, et taux d’erreur > 1 % sur une fenêtre glissante de 5 minutes.
Exemple de configuration Docker Compose complète
Voici une configuration Docker Compose fonctionnelle pour la stack Grafana + Loki + Tempo + Prometheus :
# docker-compose.yml — Stack Grafana + Loki + Tempo + Prometheus
version: '3.8'
services:
grafana:
image: grafana/grafana:10.4.0
ports: ["3000:3000"]
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin123
- GF_FEATURE_TOGGLES_ENABLE=traceqlEditor
volumes:
- grafana-data:/var/lib/grafana
- ./grafana/provisioning:/etc/grafana/provisioning
depends_on: [prometheus, loki, tempo]
prometheus:
image: prom/prometheus:v2.51.0
ports: ["9090:9090"]
volumes:
- ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus-data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.retention.time=30d'
- '--web.enable-lifecycle'
loki:
image: grafana/loki:3.0.0
ports: ["3100:3100"]
volumes:
- ./loki/loki-config.yml:/etc/loki/config.yml
- loki-data:/loki
command: -config.file=/etc/loki/config.yml
tempo:
image: grafana/tempo:2.4.1
ports:
- "3200:3200" # Tempo HTTP
- "4317:4317" # OTLP gRPC
- "4318:4318" # OTLP HTTP
volumes:
- ./tempo/tempo-config.yml:/etc/tempo/config.yml
- tempo-data:/tmp/tempo
command: -config.file=/etc/tempo/config.yml
promtail:
image: grafana/promtail:3.0.0
volumes:
- /var/log:/var/log:ro
- ./promtail/promtail-config.yml:/etc/promtail/config.yml
command: -config.file=/etc/promtail/config.yml
# Exporter métriques système
node-exporter:
image: prom/node-exporter:v1.7.0
ports: ["9100:9100"]
volumes:
- /proc:/host/proc:ro
- /sys:/host/sys:ro
command:
- '--path.procfs=/host/proc'
- '--path.sysfs=/host/sys'
volumes:
grafana-data:
prometheus-data:
loki-data:
tempo-data:Instrumentation des applications avec OpenTelemetry
OpenTelemetry (OTel) est le standard CNCF pour l’instrumentation des applications. Il unifie la collecte de métriques, logs et traces dans un seul SDK par langage, envoyés vers un OpenTelemetry Collector qui redistribue vers les backends de votre choix (Prometheus pour les métriques, Loki pour les logs, Tempo pour les traces). Cette architecture découplée permet de changer de backend sans modifier le code applicatif.
Pour une application Node.js, l’instrumentation auto avec @opentelemetry/auto-instrumentations-node instrumente automatiquement Express, HTTP, gRPC, MongoDB, Redis, MySQL et de nombreuses autres librairies sans modification de code. Il suffit de démarrer l’application avec node –require @opentelemetry/auto-instrumentations-node/register server.js et de configurer les variables d’environnement OTEL_EXPORTER_OTLP_ENDPOINT et OTEL_SERVICE_NAME.
Pour Python (Flask, FastAPI, Django), opentelemetry-instrument fait l’équivalent. Pour les applications Java Spring Boot, le Java Agent OTel (opentelemetry-javaagent.jar) s’attache via -javaagent et instrumente automatiquement la grande majorité des frameworks Java populaires. La communauté OTel maintient une liste de compatibilité mise à jour régulièrement — vérifiez que vos dépendances spécifiques sont instrumentées avant de vous engager sur OTel.
Dashboards Grafana : bonnes pratiques et templates
Grafana Dashboards as Code est la pratique recommandée pour les équipes qui veulent versionner leurs dashboards dans Git. L’outil Grafonnet (bibliothèque Jsonnet) ou le provider Terraform Grafana permettent de définir les dashboards en code et de les déployer automatiquement. Grafana.com/dashboards propose plus de 20 000 dashboards communautaires téléchargeables directement — les IDs 1860 (Node Exporter Full), 15760 (Kubernetes / Views / Global) et 13639 (Loki Dashboard) sont les points de départ recommandés.
Les panels Grafana les plus utiles pour un dashboard opérationnel : les timeseries pour les métriques temporelles avec threshold bands (zones rouge/orange/vert), les stat panels pour les KPI clés (uptime, taux d’erreur actuel, latence P50/P99), les tables pour les top N (les 10 requêtes les plus lentes), et les logs panels pour afficher les dernières erreurs sans quitter le dashboard. La combinaison de ces quatre types couvre 80 % des besoins de monitoring opérationnel.
L’alerte unifiée de Grafana (Grafana Alerting, anciennement Grafana Unified Alerting) permet de créer des alertes directement depuis les panneaux de dashboard, sur n’importe quelle datasource (Prometheus, Loki, Tempo, mais aussi MySQL, PostgreSQL, Elasticsearch…). Les alertes sont définies en PromQL ou LogQL selon la datasource. Cette approche consolide la gestion des alertes dans une seule interface plutôt que de les répartir entre Prometheus AlertManager et les alertes Grafana legacy.
Déploiement en production : Kubernetes et scalabilité
En production sur Kubernetes, la stack Grafana s’installe via les Helm charts officiels : grafana/grafana, grafana/loki (en mode scalable avec S3), grafana/tempo-distributed, et prometheus-community/kube-prometheus-stack (qui installe Prometheus + AlertManager + les exporters Kubernetes en un seul chart). Le kube-prometheus-stack est le point d’entrée recommandé pour Kubernetes — il préconfigure tout le monitoring de l’infrastructure K8s automatiquement.
La rétention et le sizing sont les deux variables clés pour dimensionner la stack en production. Pour Prometheus : comptez 1-2 bytes par sample (chaque série temporelle à chaque scrape), avec une retention de 15 jours par défaut. Pour Loki : la compression est excellente (les logs texte se compressent à 5-10 % de leur taille originale en Snappy), prévoyez entre 0.5 et 2 Go/Go de logs selon la compressibilité de votre format. Pour Tempo : les traces sont volumineuses (10-50 Ko par trace), configurez le sampling (garder 10-20 % des traces) pour maîtriser les coûts.
L’authentification dans Grafana en production passe par l’intégration SSO (OAuth2 avec Google, GitHub, Keycloak, Okta) via les options grafana.ini. Activez également la signature des dashboards (Grafana Signed Plugins) pour n’autoriser que les plugins vérifiés, et configurez les rôles RBAC Grafana pour contrôler qui peut modifier les dashboards de production vs qui ne peut que les consulter. L’accès public aux dashboards (sans authentification) est utile pour les status pages, mais doit être limité aux métriques non-sensibles.
Coûts et alternatives cloud à la stack self-hosted
La stack Grafana self-hosted a un coût en infrastructure et en temps d’administration. Pour un volume de 10 Go de logs/jour, 500 000 séries Prometheus et 10 000 traces/heure, comptez un serveur de 4 vCPU / 16 Go RAM (environ 30-50 $/mois sur Hetzner ou DigitalOcean) avec un stockage objet S3 pour la rétention long terme (environ 5-10 $/mois pour 100 Go). C’est significativement moins cher que Datadog (estimez 20-40 $/host/mois + coûts logs qui peuvent exploser) mais demande 2 à 4 heures de maintenance mensuelle.
Grafana Cloud (la version SaaS de Grafana Labs) offre un plan gratuit généreux : 14 jours de métriques pour 10 000 séries, 3 mois de logs pour 50 Go, et 14 jours de traces pour 50 Go. Ce plan est suffisant pour un projet de taille modeste et permet d’éviter complètement l’administration serveur. Le plan Pro (29 $/mois pour 3 utilisateurs) couvre la majorité des PME avec des volumes raisonnables. La migration vers self-hosted reste possible si les volumes et les coûts deviennent problématiques — les agents de collecte (Grafana Agent) envoient vers cloud ou serveur avec le même fichier de configuration.
Victoria Metrics est une alternative à Prometheus + Thanos qui monte fortement en popularité en 2026 pour les déploiements à très grande échelle. Elle consomme 7 à 10 fois moins de RAM que Prometheus pour les mêmes volumes, est compatible avec le format PromQL et les dashboards Grafana existants, et intègre un stockage long terme natif sans besoin de Thanos. Pour les entreprises qui atteignent les limites de Prometheus (des dizaines de millions de séries actives), Victoria Metrics est la migration naturelle sans changer l’écosystème d’outillage Grafana.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.