Supervision (4/5) — Loki & les logs

L’idée reçue

« Pour lire les logs, je fais kubectl logs sur le Pod concerné. »

Et quand le Pod a été détruit et recréé (Phase 5) ? Ses logs sont perdus. Et quand tu as 30 Pods sur 3 nodes ? Tu ne vas pas tous les inspecter à la main. Il faut centraliser les logs en un seul endroit, consultable et durable. C’est le rôle de Loki.

À la fin de ce module, tu sauras…

Expliquer pourquoi kubectl logs ne suffit pas
Déployer Loki et son agent de collecte
Comprendre l’approche de Loki (indexer les labels, pas le texte)
Explorer les logs dans Grafana, à côté des métriques

01La limite de kubectl logs

Expérience 1

Prouver que les logs sont volatils

Manipule

kubectl -n lab-soria logs deploy/soria-web --tail=5
kubectl -n lab-soria delete pod -l app=soria-web
kubectl -n lab-soria logs deploy/soria-web --tail=5

Après recréation du Pod, les logs d’avant ont disparu : kubectl logs ne montre que le Pod actuel, et rien de l’historique. Pour un incident nocturne sur un Pod déjà remplacé, tu es aveugle.

Comprends pourquoi centraliser

Dans un cluster, les Pods sont éphémères : leurs logs locaux partent avec eux. La solution est la centralisation : un agent collecte en continu les logs de tous les Pods de tous les nodes, et les envoie vers un stockage durable et interrogeable. Ainsi, même le log d’un Pod mort il y a trois jours reste consultable. C’est un besoin universel, indépendant de l’outil choisi.

02Déployer Loki

Expérience 2

Loki + un agent de collecte

On installe Loki et un agent qui récolte les logs sur chaque node :

Manipule

helm install loki grafana/loki-stack -n observabilite \
--set promtail.enabled=true

Manipule

kubectl -n observabilite get pods -l app.kubernetes.io/name=promtail -o wide

Observe

promtail-xxxxx   1/1   Running   ... worker-1
promtail-yyyyy   1/1   Running   ... worker-2

Un agent de collecte (Promtail) tourne sur chaque node — c’est un DaemonSet. Il lit les logs de tous les conteneurs du node et les pousse vers Loki.

Comprends agent par node (DaemonSet)

Le collecteur (Promtail, ou une alternative comme Grafana Alloy) est déployé en DaemonSet : Kubernetes garantit une instance par node. Chaque agent lit les logs locaux des conteneurs, y attache des labels (namespace, pod, app…), et les envoie à Loki. Ce couple « agent qui collecte + serveur qui stocke » est le schéma classique de toute centralisation de logs — les noms changent, le motif reste.

03L’idée clé : indexer les labels, pas le texte

Loki est décrit comme « Prometheus, mais pour les logs ». Sa particularité : il n’indexe pas le contenu des messages, seulement leurs labels. C’est ce qui le rend léger et économique.

Comprends pourquoi ce choix change tout

Les moteurs de logs classiques indexent tout le texte (puissant mais coûteux en stockage et en ressources). Loki n’indexe que les labels (les mêmes que Prometheus : namespace, pod, app…) et garde le corps du log compressé. Tu filtres d’abord par labels (« les logs du pod soria-web »), puis tu cherches dans ce sous-ensemble réduit. Résultat : bien plus léger, et une cohérence de labels avec Prometheus qui permet de passer des métriques aux logs sans changer de vocabulaire.

04Explorer les logs dans Grafana

Expérience 3

Métriques et logs, au même endroit

Ajoute Loki comme datasource dans Grafana (URL interne http://loki.observabilite.svc.cluster.local:3100), puis ouvre Explore, choisis la datasource Loki, et tape une requête LogQL :

Manipule

{namespace="lab-soria", app="soria-web"}

Puis filtre sur les erreurs :

Manipule

{namespace="lab-soria", app="soria-web"} |= "error"

Observe

Les logs de ton application défilent, filtrables. Le premier {…} sélectionne par labels (rapide) ; |= “error” ne garde que les lignes contenant « error ». Tu lis enfin ce que l’application a dit.

Comprends LogQL, le cousin de PromQL

LogQL reprend la logique de PromQL : on sélectionne par labels {app=“soria-web”}, puis on filtre le texte (|= “error” contient, != ne contient pas, |~ regex). On peut même transformer des logs en métriques (compter les erreurs par minute). Comme les labels sont partagés avec Prometheus, tu passes d’un pic sur un graphe aux logs correspondants dans le même Grafana : la métrique repère, le log explique — les deux piliers réunis.

✓Ce que tu retiens

kubectl logs est volatil et local ; Loki centralise les logs de tout le cluster via un agent par node (DaemonSet, ex. Promtail). Sa force : il indexe les labels, pas le texte — léger, et cohérent avec Prometheus. On interroge en LogQL (sélection par labels + filtre texte) dans le même Grafana. Métrique et log enfin réunis : l’une repère, l’autre explique.

Mini-projet

Centralise les logs de ton infra

À faire

Prouve la volatilité : lis les logs d’un Pod, supprime-le, constate la perte de l’historique.
Déploie Loki + l’agent de collecte (un par node).
Ajoute Loki comme datasource dans Grafana.
Dans Explore, affiche les logs de soria-web, puis filtre sur « error ».
Génère une erreur (ex. requête une URL inexistante) et retrouve-la dans Loki.
Documente dans BookStack : volatilité des logs, agent/DaemonSet, indexation par labels, LogQL.

Fil rouge — Tu as les métriques et les logs, visibles dans Grafana. Mais tu regardes encore les écrans toi-même. Le dernier pilier automatise la vigilance : au module final, Alertmanager te prévient quand un seuil est franchi — pour ne plus découvrir les pannes à 3 h du matin par hasard.

?Auto-évaluation

1. Pourquoi kubectl logs ne suffit-il pas ?

Il ne montre que le Pod actuel : dès qu’un Pod est recréé, son historique est perdu. Et il n’agrège pas les logs de multiples Pods/nodes.

2. Qu’est-ce qui rend Loki léger ?

Il indexe seulement les labels des logs (namespace, pod, app…), pas tout le contenu texte, qu’il garde compressé. On filtre par labels d’abord, puis dans le texte.

3. Quel intérêt d’avoir les mêmes labels que Prometheus ?

La cohérence de vocabulaire permet de passer d’un pic de métrique aux logs correspondants dans le même Grafana : la métrique repère le problème, le log l’explique.