Logging : Collecte et agrégation des logs des conteneurs (architecture EFK/Loki)

Le deuxième pilier : comprendre les événements via les logs

Tandis que le monitoring nous donne une vue quantitative de la performance, le logging fournit un enregistrement chronologique des événements qui se produisent au sein de vos applications et de votre infrastructure. Les logs sont indispensables pour le débogage, l'audit, l'analyse de sécurité et la compréhension du comportement détaillé d'un système. Dans l'environnement dynamique et distribué de Kubernetes, où les conteneurs sont éphémères et potentiellement nombreux, la gestion centralisée des logs devient cruciale.

Par défaut, les applications conteneurisées écrivent leurs logs sur les flux de sortie standard (stdout) et d'erreur standard (stderr). Le runtime de conteneur (comme Docker ou containerd) capture ces flux et les écrit dans des fichiers sur le disque du noeud worker. La commande kubectl logs permet d'accéder à ces logs. Cependant, cette approche a des limites majeures : les logs sont perdus si le Pod est supprimé ou si le noeud tombe en panne, et il n'y a pas de moyen simple d'agréger ou de rechercher dans les logs de plusieurs Pods ou sur une longue période. Une solution de logging centralisée est donc nécessaire.

Architecture de logging centralisée : l'agent sur le noeud

L'approche la plus courante pour la collecte centralisée des logs dans Kubernetes repose sur l'exécution d'un agent de logging sur chaque noeud worker. Cet agent est généralement déployé en tant que DaemonSet, garantissant qu'une instance s'exécute sur chaque noeud (ou un sous-ensemble défini).

Le rôle de cet agent est de :

1. Détecter les fichiers de logs générés par le runtime de conteneur sur le noeud.
2. Lire (tail) ces fichiers en continu.
3. Parser les lignes de log (optionnel mais recommandé, par exemple pour extraire des structures JSON).
4. Enrichir chaque ligne de log avec des métadonnées pertinentes issues de l'API Kubernetes (nom du Pod, namespace, labels, etc.). C'est essentiel pour pouvoir filtrer et rechercher les logs par la suite.
5. Transmettre les logs enrichis vers un backend de logging centralisé pour stockage, indexation et analyse.

Plusieurs architectures de backend et combinaisons d'agents existent. Nous allons nous concentrer sur deux des plus populaires : la pile EFK et la pile Loki.

Architecture classique : la pile EFK (Elasticsearch, Fluentd, Kibana)

La pile EFK est une solution de logging open-source très mature et largement adoptée.

• E - Elasticsearch : C'est une base de données distribuée et un moteur de recherche et d'analyse extrêmement puissant. Il stocke les documents de log (souvent au format JSON) et les indexe de manière approfondie, permettant des recherches textuelles complexes, des agrégations et des analyses sur de grands volumes de données. Il est conçu pour être scalable horizontalement.
• F - Fluentd (ou Fluent Bit) : C'est l'agent de collecte de logs. Fluentd est un collecteur de données très flexible avec un riche écosystème de plugins pour différentes sources et destinations. Fluent Bit est une alternative plus légère, optimisée pour la performance et une faible consommation de ressources, ce qui en fait un choix populaire comme agent DaemonSet dans Kubernetes. L'agent (Fluentd ou Fluent Bit) lit les logs des conteneurs sur le noeud, les enrichit avec les métadonnées Kubernetes et les envoie à Elasticsearch.
• K - Kibana : C'est l'interface web de visualisation et d'exploration pour les données stockées dans Elasticsearch. Kibana permet aux utilisateurs de rechercher interactivement dans les logs (avec un langage de requête puissant comme KQL ou Lucene), de visualiser les données sous forme de graphiques et de créer des tableaux de bord de logging personnalisés.

Avantages d'EFK : Puissantes capacités de recherche et d'analyse full-text, écosystème mature, riche interface de visualisation.

Inconvénients d'EFK : Peut être gourmand en ressources (CPU, mémoire, disque) notamment côté Elasticsearch à cause de l'indexation complète, complexité de déploiement et de maintenance d'un cluster Elasticsearch à grande échelle.

Architecture moderne : la pile Loki (Promtail, Loki, Grafana)

Inspirée par Prometheus, la pile Loki adopte une approche différente de l'indexation des logs, visant une meilleure efficacité en termes de ressources et de coûts.

• Promtail : C'est l'agent de collecte de logs, conçu spécifiquement pour Loki. Déployé comme un DaemonSet, Promtail découvre les cibles de logs (conteneurs), lit leurs flux stdout/stderr, et surtout, extrait et attache des labels (similaires aux labels Prometheus) aux flux de logs (basés sur les métadonnées Kubernetes comme le namespace, le nom de l'application via les labels du Pod, etc.). Il envoie ensuite les lignes de log compressées et les labels associés à Loki. Crucialement, Promtail n'indexe pas le contenu complet des logs.
• Loki : C'est le backend d'agrégation de logs. Loki stocke les lignes de logs brutes (souvent dans un stockage objet comme S3 ou GCS pour le coût et la scalabilité) et ne construit qu'un index sur les labels fournis par Promtail. L'idée est d'indexer la même métadonnée que celle utilisée pour les métriques dans Prometheus. Quand une requête arrive, Loki utilise l'index des labels pour trouver rapidement les flux de logs pertinents, puis effectue une recherche par filtrage (grep) sur le contenu des lignes de ces flux.
• Grafana : Grafana sert également d'interface utilisateur pour Loki (tout comme pour Prometheus). Il permet d'interroger les logs en utilisant le langage LogQL (syntaxiquement similaire à PromQL), qui permet de sélectionner les flux de logs par leurs labels, puis de filtrer leur contenu. Grafana permet de visualiser les logs, de les corréler avec les métriques Prometheus dans les mêmes tableaux de bord.

Avantages de Loki : Très efficace en termes de ressources et de coût de stockage (grâce à l'indexation limitée aux labels), excellente intégration avec l'écosystème Prometheus/Grafana, plus simple à opérer qu'Elasticsearch à grande échelle.

Inconvénients de Loki : La recherche full-text sur de longues périodes ou de grands volumes peut être plus lente que dans Elasticsearch car elle implique un filtrage post-indexation. La puissance des requêtes sur le contenu brut est moins développée que celle d'Elasticsearch.

Choisir la bonne architecture

Le choix entre EFK et Loki (ou d'autres solutions) dépend de vos besoins spécifiques :

• Si vous avez besoin de recherches full-text très performantes sur d'immenses volumes de logs et d'analyses complexes sur le contenu, et que vous pouvez gérer la complexité et le coût des ressources, EFK est un choix solide et éprouvé.
• Si vous privilégiez l'efficacité des ressources, le coût de stockage, une intégration transparente avec votre monitoring Prometheus/Grafana existant, et que vos besoins de recherche se concentrent principalement sur le filtrage par métadonnées (labels) avec des recherches de contenu plus ciblées, Loki est une excellente alternative moderne.

Dans les deux cas, la mise en place d'une solution de logging centralisée, avec des agents sur les noeuds enrichissant les logs avec les métadonnées Kubernetes, est une étape fondamentale pour obtenir une observabilité complète de votre cluster.