Votre panier est vide!
🟡 Niveau : Intermédiaire | ⏱️ Lecture : 15 min | 🛠️ Mise en œuvre : 2-4 heures
📚 Prérequis
- Docker installé et fonctionnel (voir notre article précédent)
- Compréhension basique des concepts de monitoring (métriques, logs)
- Un serveur dédié au monitoring (recommandé : 4 Go RAM, 2 vCPU)
Dans un monde où les applications sont distribuées sur des dizaines de conteneurs et serveurs, avoir une visibilité complète sur son infrastructure n’est plus un luxe — c’est une nécessité absolue. La stack Prometheus + Grafana + Loki est devenue le standard open-source pour l’observabilité. Découvrons pourquoi et comment l’implémenter efficacement.
🤔 Le Problème : « Ça ne Marche Plus » à 3h du Matin
Vous connaissez ce scénario : votre application tombe en production, les utilisateurs se plaignent, et vous n’avez aucune idée de ce qui s’est passé. Vous vous connectez en SSH, vous lancez des tail -f sur différents fichiers de logs, vous regardez le top… et pendant ce temps, chaque minute qui passe coûte de l’argent et de la réputation.
L’observabilité, c’est la capacité à comprendre l’état de votre système uniquement à partir de ses sorties (métriques, logs, traces). C’est la différence entre « je pense que le problème vient du serveur 3 » et « je vois que le serveur 3 a atteint 95% de CPU à 2h47 suite à une augmentation soudaine du trafic ».
💰 Pourquoi l’Open-Source plutôt que Datadog ?
Les solutions SaaS comme Datadog ou New Relic sont excellentes, mais elles posent plusieurs problèmes pour beaucoup d’équipes :
Le coût explose vite. À $15-25 par serveur par mois, une infrastructure de 20 serveurs coûte $3 000 à $6 000 par an. Et le prix augmente avec le volume de données. Une startup ou une PME peut difficilement absorber ces coûts.
Vos données partent dans le cloud. Pour les entreprises soumises au RGPD, dans le secteur de la santé ou bancaire, envoyer des logs contenant potentiellement des données sensibles vers un tiers américain est souvent impossible.
Vous êtes dépendant. Si Datadog a une panne (ça arrive), vous perdez toute visibilité sur votre propre infrastructure au pire moment.
La stack Prometheus + Grafana + Loki est 100% open-source, auto-hébergée, et vous gardez le contrôle total. Le seul coût ? Le serveur qui l’héberge (un VPS à €50/mois suffit pour monitorer des dizaines de serveurs).
🧩 Les 3 Piliers : Chacun Son Rôle
Cette stack repose sur trois composants complémentaires, chacun spécialisé dans son domaine :
📈 Prometheus — Le Gardien des Métriques
Imaginez Prometheus comme un enquêteur qui fait sa ronde régulièrement. Toutes les 15 secondes (par défaut), il va interroger chaque serveur et application : « Combien de CPU tu utilises ? Combien de requêtes tu as reçues ? Des erreurs ? »
Ce sont les métriques : des chiffres horodatés qui racontent l’histoire de votre infrastructure. Prometheus les stocke et vous permet de les interroger avec PromQL, son langage de requête. Par exemple, pour voir le pourcentage de CPU utilisé par un serveur sur les 5 dernières minutes :
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
Ne vous inquiétez pas si cette syntaxe vous semble obscure — Grafana vous permet de construire ces requêtes visuellement, et des centaines de dashboards prêts à l’emploi existent.
📊 Grafana — Le Tableau de Bord Central
Grafana, c’est l’interface visuelle où tout prend sens. Il se connecte à Prometheus et Loki et transforme les données brutes en graphiques, jauges, tableaux et cartes interactives.
Concrètement, c’est là que vous verrez en un coup d’œil : l’utilisation CPU de tous vos serveurs, l’espace disque restant, le nombre de requêtes par seconde sur votre API, les logs d’erreur en temps réel.
Le meilleur ? La corrélation automatique. Vous voyez un pic sur un graphique ? Un clic, et Grafana vous montre les logs correspondant à cette période exacte. Plus de va-et-vient entre différents outils.
📝 Loki — Les Logs Sans le Prix
Traditionnellement, centraliser les logs signifie utiliser la stack ELK (Elasticsearch, Logstash, Kibana). Problème : Elasticsearch est gourmand en ressources car il indexe chaque mot de chaque ligne de log.
Loki adopte une approche différente : il n’indexe que les métadonnées (d’où vient le log, quel service, quelle instance), pas le contenu. Quand vous cherchez, il filtre d’abord par ces étiquettes, puis scanne le contenu brut. Résultat : 10x moins de ressources consommées qu’Elasticsearch, pour une expérience utilisateur similaire.
C’est particulièrement pertinent quand vos conteneurs Docker génèrent des gigaoctets de logs par jour — avec Loki, vous pouvez tout garder plusieurs semaines sans exploser votre stockage.
🏗️ Comment ça s’Organise Concrètement
En pratique, vous avez deux types de machines :
Un serveur de monitoring central qui héberge Grafana (l’interface), Prometheus (le stockage des métriques), Loki (le stockage des logs) et AlertManager (pour envoyer des alertes par email, Slack, etc.).
Des agents légers sur chaque serveur à monitorer : Node Exporter expose les métriques système (CPU, RAM, disque), cAdvisor expose les métriques des conteneurs Docker, et Promtail envoie les logs vers Loki.
Cette séparation est importante : vos serveurs de production ne sont pas alourdis par le stockage des données de monitoring. Ils se contentent de les exposer, et le serveur central les collecte.
📋 Par Où Commencer : Les Métriques Prioritaires
Quand on démarre, on peut vite se noyer sous la quantité de métriques disponibles. Voici les essentielles pour débuter :
Pour chaque serveur : surveillez le CPU (pic prolongé = problème), la RAM disponible (proche de zéro = le système va commencer à swapper puis à tuer des processus), et l’espace disque (saturation = catastrophe assurée).
Pour vos conteneurs Docker : surveillez la consommation mémoire par conteneur (fuite mémoire ?), les redémarrages (un conteneur qui redémarre souvent a un problème), et le CPU consommé versus les limits configurées.
Pour vos applications : le taux d’erreurs (combien de réponses 5xx ?), la latence (en combien de temps vos utilisateurs reçoivent une réponse ?), et le throughput (combien de requêtes par seconde ?).
🚨 Les Alertes : Moins c’est Mieux
L’erreur classique du débutant : créer une alerte pour chaque métrique. Résultat ? Après deux semaines, tout le monde ignore les notifications, car il y en a trop.
Une bonne alerte doit être actionnable. Si elle sonne, quelqu’un doit intervenir. Exemples d’alertes utiles :
- Espace disque < 10% : si vous ne faites rien, le serveur va tomber
- Conteneur « unhealthy » pendant 5 minutes : quelque chose ne va vraiment pas
- Taux d’erreurs 5xx > 5% sur 10 minutes : vos utilisateurs souffrent
- Certificat SSL expire dans 7 jours : vous avez le temps d’agir
Ce qu’il faut éviter : « CPU > 80% » (peut être normal pendant un pic), « une requête a échoué » (ça arrive), « latence haute pendant 30 secondes » (peut être un cas isolé).
La règle d’or : si vous ignorez régulièrement une alerte, supprimez-la ou ajustez son seuil.
🔧 Configuration : Un Aperçu Simplifié
Voici à quoi ressemble la configuration de Prometheus. En gros, vous lui dites : « toutes les 15 secondes, va interroger ces serveurs » :
global:
scrape_interval: 15s # Fréquence de collecte
scrape_configs:
# Métriques des serveurs (CPU, RAM, disque)
- job_name: 'serveurs'
static_configs:
- targets:
- 'serveur1.mondomaine.com:9100'
- 'serveur2.mondomaine.com:9100'
- 'serveur3.mondomaine.com:9100'
# Métriques des conteneurs Docker
- job_name: 'conteneurs'
static_configs:
- targets:
- 'serveur1.mondomaine.com:9200'
- 'serveur2.mondomaine.com:9200'
Le port 9100 est celui de Node Exporter (métriques système), le 9200 est celui de cAdvisor (métriques Docker). Chaque serveur à monitorer expose ces ports, et Prometheus les interroge régulièrement.
🚀 Passer à l’Action
Mettre en place cette stack manuellement est faisable, mais prend du temps : il faut installer et configurer chaque composant, générer les fichiers de configuration, gérer les mises à jour, etc.
C’est pourquoi nous avons créé un rôle Ansible qui automatise tout. En quelques variables, vous déployez :
- ✅ Mode Server : Grafana + Prometheus + Loki + AlertManager sur une machine centrale
- ✅ Mode Client : Node Exporter + cAdvisor + Promtail sur chaque serveur à monitorer
- ✅ Configuration automatique : Prometheus est configuré pour interroger tous les clients
- ✅ Dashboards inclus : des tableaux de bord Grafana prêts à l’emploi
Le rôle est testé sur Debian 12/13 et Ubuntu 22.04/24.04, avec une documentation complète.
Intéressé par une stack d’observabilité clé en main ? Découvrez notre rôle Ansible grafana_prometheus_loki.
📖 Glossaire
- Observabilité : Capacité à comprendre l’état interne d’un système à partir de ses sorties (métriques, logs, traces)
- Métriques : Données numériques horodatées décrivant l’état du système (CPU, RAM, requêtes/seconde)
- PromQL : Langage de requête de Prometheus pour interroger les métriques
- Node Exporter : Agent qui expose les métriques système (CPU, RAM, disque) au format Prometheus
- Scrape : Action de Prometheus qui collecte les métriques en interrogeant les endpoints configurés
- AlertManager : Composant qui gère les alertes générées par Prometheus et les route vers les canaux de notification
- Datasource : Source de données configurée dans Grafana (Prometheus, Loki, MySQL, etc.)
Dans notre prochain article, nous aborderons la sécurisation de vos images Docker avec Harbor et Trivy. Restez connectés !