Fluentd a un cousin plus léger : Fluent Bit, créé par un membre de l’équipe Fluentd spécifiquement pour les environnements où l’empreinte de Fluentd est trop lourde. Les deux sont des projets CNCF graduated sous la même ombrelle Fluent, et les deux suivent la même architecture entrée/filtre/sortie à base de tags présentée ailleurs dans cette série. Ce guide présente ce qui les distingue réellement, et l’architecture qui utilise les deux ensemble.

Le compromis central : empreinte contre écosystème

	Fluentd	Fluent Bit
Langage	Ruby, avec les parties sensibles aux performances en C	C
Empreinte mémoire typique	Quelques dizaines de mégaoctets	De l’ordre de quelques centaines de kilooctets
Écosystème de plugins	Vaste ; large éventail de plugins d’entrée/filtre/sortie matures	Plus restreint, mais substantiel et en croissance ; plus de 100 plugins intégrés
Convient le mieux à	L’agrégation centrale, un traitement plus lourd	La collecte à haut volume, l’edge et les environnements contraints en ressources

L’implémentation uniquement en C de Fluent Bit et ses dépendances minimales rendent son empreinte assez petite pour tourner à l’échelle de l’edge : appareils Linux embarqués, matériel IoT, partout où un processus Ruby de plusieurs mégaoctets n’est pas raisonnable à exécuter. La plus grande empreinte de Fluentd achète un écosystème de plugins plus vaste et plus mature, ce qui compte davantage quand on fait des transformations plus lourdes ou qu’on écrit vers une destination moins courante.

Même architecture, implémentation différente

Les deux outils reposent sur les mêmes concepts présentés dans toute cette série : les plugins d’entrée définissent les sources, les plugins de filtre transforment les données au vol, les plugins de sortie définissent les destinations, et les tags routent les données entre eux. Quelqu’un qui a configuré l’un peut lire la configuration de l’autre et en reconnaître immédiatement la forme, même si la syntaxe diffère dans le détail. Fluent Bit va aussi au-delà de la pure collecte de logs : il prend en charge nativement la collecte de métriques d’hôte et de conteneur (CPU, mémoire, disque) en plus des logs, ce qui, dans le monde de Fluentd, impliquerait typiquement un outil distinct comme les exporters de Prometheus plutôt qu’un agent unifié.

L’architecture combinée : Fluent Bit transfère, Fluentd agrège

Les deux outils peuvent jouer le rôle de forwarder (collecter et expédier les données plus loin) ou d’agrégateur (recevoir de nombreux forwarders, effectuer un traitement plus lourd et expédier vers le stockage final), et rien n’oblige à choisir un seul outil pour un déploiement entier. Un schéma courant, dans Kubernetes en particulier, tire parti des points forts de chacun :

┌────────────┐  ┌────────────┐  ┌────────────┐
│  Nœud 1     │  │  Nœud 2     │  │  Nœud 3     │
│ Fluent Bit  │  │ Fluent Bit  │  │ Fluent Bit  │   ← un par nœud (DaemonSet),
│ (DaemonSet) │  │ (DaemonSet) │  │ (DaemonSet) │     léger, se contente de transférer
└──────┬─────┘  └──────┬─────┘  └──────┬─────┘
       │                │                │
       └────────────────┼────────────────┘
                         ▼
                 ┌───────────────┐
                 │    Fluentd     │   ← agrégateur central,
                 │  (agrégateur)  │     analyse/enrichissement plus lourds,
                 └───────┬───────┘     accès à davantage de plugins
                         ▼
               Elasticsearch / S3 / Kafka / ...

Fluent Bit s’exécute en DaemonSet, une instance légère par nœud, qui fait le strict nécessaire pour collecter et transférer les logs sans entrer en concurrence de façon notable avec les vrais workloads du nœud pour le CPU ou la mémoire. Fluentd s’exécute de façon centralisée, en plus petit nombre, et fait le gros du travail : analyse complexe, enrichissement et routage vers toute destination nécessitant un plugin que Fluent Bit n’a pas. Chaque outil fait la part pour laquelle il est réellement conçu, plutôt qu’un seul outil qui fait tout de façon passable.

Choisir l’un des deux, si un seul suffit

• Fluent Bit seul convient quand le déploiement est contraint en ressources (appareils edge, forte densité de Pods, sensibilité aux coûts à grande échelle) et que les besoins en destinations et en traitement restent bien dans ce que couvre son jeu de plugins.
• Fluentd seul convient quand le déploiement n’est pas particulièrement contraint en ressources et qu’il faut un plugin, ou un degré de flexibilité de configuration, plus mature dans l’écosystème établi de longue date de Fluentd.
• Les deux ensemble conviennent exactement au schéma ci-dessus : collecte à haut volume par nœud où l’empreinte compte, alimentant un traitement centralisé plus lourd où elle compte moins.

Les modules de logging des offres Kubernetes managées des fournisseurs cloud ont de plus en plus adopté Fluent Bit par défaut au fil des ans, précisément pour les raisons de performance et d’empreinte du tableau ci-dessus, ce qu’il est utile de savoir si vous dépannez un cluster managé et vous attendiez à y trouver Fluentd : vérifiez lequel des deux est réellement déployé avant de le supposer.