Fluentd est un collecteur de données open source qui unifie la collecte et la consommation des logs. Il suit, analyse, met en tampon et route les données de log depuis de nombreuses sources vers de nombreuses destinations, en dissociant la façon dont les logs sont produits de l’endroit où ils finissent : un index de recherche, un stockage objet, une plateforme d’analyse de logs, ou les trois à la fois.

Comment ça marche

Fluentd s’exécute comme un agent (souvent en DaemonSet Kubernetes, un par nœud) qui lit les données de log via des plugins d’entrée, les transforme éventuellement via des plugins de filtre, et les écrit via des plugins de sortie. Son architecture de plugins est ce qui permet à un même pipeline Fluentd de lire les logs de conteneurs depuis le système de fichiers d’un nœud et de les répartir vers plusieurs destinations avec des formats et des sémantiques de nouvelle tentative différents.

Concepts clés

• Plugin d’entrée : lit des événements de log depuis une source : un fichier, un socket TCP, le répertoire des logs de conteneurs Kubernetes, et bien d’autres.
• Plugin de filtre : transforme ou enrichit les événements dans le pipeline, par exemple en extrayant des champs structurés d’une ligne de log brute ou en ajoutant des métadonnées Kubernetes.
• Plugin de sortie : écrit les événements vers une destination : Elasticsearch, S3, Kafka, une plateforme de logs hébergée, et des dizaines d’autres.
• Buffer : la file d’attente interne de Fluentd entre les entrées et les sorties, qui absorbe la contre-pression et retente les écritures échouées.

Pourquoi les équipes adoptent Fluentd

• Neutre vis-à-vis des fournisseurs. Un vaste écosystème de plugins fait que changer de destination de logs est un changement de configuration, pas une refonte d’architecture.
• Conçu pour les gros volumes. Son modèle de mise en tampon et de découpage en chunks est pensé pour gérer de façon fiable des flux de logs en rafales et à haut débit.
• Un modèle de logs structuré. Les événements portent des champs structurés plutôt que du texte brut, ce qui rend le filtrage et le routage en aval bien plus précis.
• CNCF graduated. C’est l’équivalent, pour les logs, de la place de Prometheus dans la pile d’observabilité : largement adopté et activement maintenu.

Pour commencer

Déployez Fluentd en DaemonSet pour qu’un agent tourne sur chaque nœud, configurez-le pour suivre les logs de conteneurs, et ajoutez les plugins de sortie pour l’endroit où vous voulez que les logs aboutissent. Les guides ci-dessous couvrent les configurations de collecte et de routage les plus courantes.