Une seule application qui écrit dans un seul fichier de log est facile à lire. Un vrai système, composé de plusieurs services, d’une base de données, d’un broker de messages, d’un proxy d’entrée, chacun journalisant dans son propre format à son propre emplacement, ne l’est pas. Ce guide explique pourquoi cela devient un vrai problème à grande échelle, et le modèle de pipeline que Fluentd utilise pour le résoudre.

À quoi servent réellement les logs

Les logs ne sont pas qu’un outil de débogage après coup. Les mêmes données de log servent généralement plusieurs usages distincts à la fois :

• Le débogage, retracer ce qui s’est passé autour d’une erreur.
• La sécurité, détecter une activité suspecte, comme des échecs de connexion répétés depuis une même adresse, qui n’apparaît qu’en corrélant des événements dans le temps ou entre sources.
• La conformité, certains secteurs exigeant de conserver des enregistrements précis pendant une durée définie.
• L’audit, répondre après coup à « qui a accédé à quoi, et quand ».

Chacun de ces usages exige que les données soient au même endroit, consultables, et non éparpillées sur des machines individuelles.

Où la journalisation naïve atteint ses limites

Deux points de départ courants se heurtent au même mur à mesure que le système grandit :

Écrire dans des fichiers locaux. Simple, et c’est exactement la façon dont la plupart des logiciels journalisent par défaut, mais un fichier texte brut n’est pas conçu pour l’analyse. Comparer les horodatages entre les fichiers de log de cinq applications différentes, chacune dans un format différent, pour reconstituer le chemin d’une requête à travers un système est fastidieux au mieux, et souvent impraticable à la main.

Journaliser directement dans une base de données. Envoyez tout directement vers Elasticsearch ou un stockage similaire, et chaque application a désormais besoin de sa propre bibliothèque cliente, de sa propre gestion des connexions et de son propre accord sur les champs et formats à utiliser. Chaque développeur résout en pratique le même problème d’intégration, et rien ne garantit qu’il le résolve de la même façon deux fois.

Aucune des deux approches ne gère les composants tiers dont vous ne maîtrisez pas le code, une base de données, un broker de messages, un ingress controller ou de simples logs système, qui produisent des logs dans le format avec lequel ils ont été conçus, et non dans celui sur lequel vos propres applications se sont accordées.

Le modèle de pipeline : collecter, transformer, expédier

L’approche de Fluentd consiste à s’insérer comme couche à part entre l’endroit où les logs sont produits et celui où ils aboutissent, structurée en pipeline à trois étapes :

   sources                      Fluentd                     destinations
┌─────────────┐          ┌───────────────────┐          ┌──────────────────┐
│ logs applis  │          │                   │          │ Elasticsearch     │
│ logs système │ ───────▶ │ collecte → analyse│ ───────▶ │ S3                │
│ stdout des   │          │ → filtre/enrichit │          │ Kafka             │
│ conteneurs   │          │                   │          │ une BDD, etc.     │
└─────────────┘          └───────────────────┘          └──────────────────┘

Fluentd collecte les logs là où ils sont produits, quelle que soit la source ou le format d’origine. Il les analyse et les transforme en une structure cohérente, en faisant des données clé-valeur à partir de texte non structuré. En chemin, il peut enrichir les entrées avec du contexte utile (quel pod, quel hôte, quel conteneur a produit cette ligne) ou les filtrer, en écartant ce qui n’est pas nécessaire ou en masquant des champs sensibles. Enfin, il expédie le résultat vers une ou plusieurs destinations, plateforme d’analyse, datastore, stockage froid, sans que chaque application en amont ait besoin de savoir ni de se soucier de l’endroit où ses logs finissent par atterrir.

Les tags : comment Fluentd route les données dans le pipeline

Chaque entrée de log que Fluentd collecte reçoit un tag, une chaîne que vous attribuez lors de la configuration de l’origine de l’entrée. Les tags sont ce que les étapes suivantes du pipeline utilisent pour décider ce qui s’applique à quoi : « analyser les entrées taguées apache.access avec le format de log Apache », « filtrer les entrées taguées app.* pour retirer un champ », « envoyer les entrées taguées *.errors vers cette destination et tout le reste vers celle-là ». Les détails de la rédaction de cette configuration font l’objet du guide suivant de cette série ; ce qui compte ici est le concept : un tag est le fil qui relie une donnée à sa source d’origine, jusqu’à l’endroit où elle est finalement expédiée.

Pourquoi cela justifie une couche dédiée

L’alternative à un tel pipeline n’est pas « aucun travail » : c’est la même logique d’analyse, d’enrichissement et de routage réimplémentée dans chaque application qui journalise quoi que ce soit, de façon incohérente, chacune un peu différemment. La centraliser dans une seule couche configurable signifie que cette logique est écrite une fois, et que chaque nouvelle application n’a qu’à produire des logs dans le format qui lui est le plus simple (texte brut, JSON, ce qu’un outil tiers écrit déjà) pour que Fluentd se charge ensuite de les rendre cohérents.