ADR-0012 : Loki + Grafana + Prometheus comme stack d’observabilité
| Statut | Accepté |
| Date | 2025-11 |
| Décideurs | Équipe Edukit (dev + ops) |
| Périmètre | Observabilité, tous les services Edukit et l’infrastructure |
Contexte
Edukit fait tourner plusieurs services en même temps (OrgService, VmService, RabbitMQ, etc.). Quand quelque chose se passe mal, il faut pouvoir comprendre ce qui s’est passé et où. Sans outil dédié, on est aveugle.
L’équipe a besoin de :
- métriques : suivre l’utilisation CPU, mémoire, la latence des APIs, le nombre de messages en attente dans RabbitMQ… pour détecter un problème avant qu’il affecte les étudiants ;
- logs centralisés : regrouper les logs de tous les services en un seul endroit pour investiguer un incident ;
- tableaux de bord : visualiser l’état de la plateforme en temps réel ;
- alertes : être prévenu automatiquement quand quelque chose ne va pas (service planté, disque presque plein, latence anormale).
La solution doit tourner sur l’infrastructure existante, sans abonnement payant.
Décision
Utiliser la stack Prometheus + Loki + Grafana (PLG) pour toute l’observabilité.
- Prometheus collecte les métriques : état des pods K3s, consommation des nœuds, métriques des services .NET, de RabbitMQ et de Proxmox. Chaque source expose ses métriques dans un format standard, et Prometheus vient les lire régulièrement.
- Loki centralise les logs de tous les pods K3s. Un agent léger appelé Promtail tourne sur chaque nœud et envoie les logs à Loki.
- Grafana est l’interface unique pour tout visualiser : tableaux de bord, exploration des métriques, recherche dans les logs. On peut passer d’un graphique de métriques directement aux logs correspondants.
- Les alertes sont configurées dans Grafana ou dans Prometheus, avec notification vers le canal de communication de l’équipe.
- La stack est déployée dans K3s via un Helm chart géré par ArgoCD (voir ADR-0010).
Conséquences
Bénéfices
- Tout dans Grafana : métriques et logs dans une seule interface, avec la possibilité de naviguer de l’un à l’autre. Pas besoin d’ouvrir plusieurs outils pour investiguer un incident.
- Gratuit : Prometheus, Loki et Grafana sont open source. Pas de coût de licence.
- Standard Kubernetes : presque tous les composants Kubernetes exposent déjà des métriques au format Prometheus. Les exporters pour Proxmox, RabbitMQ et .NET sont disponibles.
- Configurable : on choisit combien de temps on garde les données selon l’espace disque disponible.
Coûts et limites
- À maintenir : la stack PLG ne se gère pas toute seule. Il faut surveiller l’espace disque, mettre à jour les composants et ajuster les paramètres de rétention.
- Pas de tracing distribué : PLG couvre les métriques et les logs, mais pas le suivi d’une requête de bout en bout à travers plusieurs services (tracing). Si ce besoin apparaît, Tempo (du même éditeur que Grafana) peut être ajouté sans casser ce qui existe.
- Loki n’est pas fait pour tout : Loki est optimisé pour rechercher des logs par tags. Les analyses complexes sur le contenu des logs peuvent être lentes.
Alternatives écartées
- Datadog / New Relic : solutions SaaS très complètes, mais avec un prix par machine ou par utilisateur qui dépasse rapidement le budget. Écartées.
- Grafana Cloud (version hébergée) : l’éditeur de Grafana propose une version cloud hébergée. Pratique, mais avec un coût récurrent et les logs de production qui partent chez un hébergeur externe. Écarté au profit d’un déploiement on-premise.
- Zabbix : outil de monitoring très répandu, mais pensé pour surveiller des serveurs traditionnels (via SNMP ou agents). Moins adapté à un environnement Kubernetes où les services démarrent et s’arrêtent dynamiquement.