Fluentd tiene un hermano más ligero: Fluent Bit, creado por un miembro del equipo de Fluentd específicamente para entornos donde la huella de Fluentd resulta demasiado pesada. Ambos son proyectos graduados de la CNCF bajo el mismo paraguas Fluent, y ambos siguen la misma arquitectura de entrada/filtro/salida basada en tags que se cubre en otras guías de esta serie. Esta guía cubre qué difiere realmente entre ellos y la arquitectura que usa ambos juntos.

El equilibrio fundamental: huella frente a ecosistema

	Fluentd	Fluent Bit
Lenguaje	Ruby, con las partes sensibles al rendimiento en C	C
Huella de memoria típica	Decenas de megabytes	Del orden de cientos de kilobytes
Ecosistema de plugins	Grande; amplia gama de plugins maduros de entrada/filtro/salida	Más pequeño, pero sustancial y en crecimiento; más de 100 plugins incorporados
Más adecuado para	Agregación central, procesamiento más pesado	Recopilación de alto volumen, entornos edge y con recursos limitados

La implementación solo en C de Fluent Bit y sus dependencias mínimas son lo que hace que su huella sea lo bastante pequeña para ejecutarse a escala edge real, dispositivos Linux embebidos, hardware IoT, cualquier lugar donde un proceso Ruby de muchos megabytes no sea algo razonable de ejecutar. La huella mayor de Fluentd compra un ecosistema de plugins igualmente mayor y más maduro, lo que importa más cuando haces una transformación más pesada o escribes en un destino menos común.

La misma arquitectura, distinta implementación

Ambas herramientas se construyen en torno a los mismos conceptos que se cubren a lo largo de esta serie: los plugins de entrada definen las fuentes, los plugins de filtro transforman datos en tránsito, los plugins de salida definen destinos y los tags enrutan los datos entre ellos. Quien haya configurado una puede leer la configuración de la otra y reconocer la forma de inmediato, aunque la sintaxis difiera en los detalles. Fluent Bit también va más allá de la simple recopilación de logs: admite de forma nativa la recopilación de métricas de host y de contenedores (CPU, memoria, disco) junto con los logs, algo que en el mundo de Fluentd normalmente significaría una herramienta aparte, como los exporters de Prometheus, en lugar de un único agente unificado.

La arquitectura combinada: Fluent Bit reenvía, Fluentd agrega

Ambas herramientas pueden actuar como forwarder (recopilar y enviar datos hacia adelante) o como aggregator (recibir de muchos forwarders, hacer un procesamiento más pesado y enviar al almacenamiento final), y nada obliga a elegir solo una herramienta para todo un despliegue. Un patrón común en Kubernetes en concreto aprovecha los puntos fuertes de cada una:

┌────────────┐  ┌────────────┐  ┌────────────┐
│  Nodo 1     │  │  Nodo 2     │  │  Nodo 3     │
│ Fluent Bit  │  │ Fluent Bit  │  │ Fluent Bit  │   ← uno por nodo (DaemonSet),
│ (DaemonSet) │  │ (DaemonSet) │  │ (DaemonSet) │     ligero, solo reenvía
└──────┬─────┘  └──────┬─────┘  └──────┬─────┘
       │                │                │
       └────────────────┼────────────────┘
                         ▼
                 ┌───────────────┐
                 │    Fluentd     │   ← agregador central,
                 │  (aggregator)  │     parseo/enriquecimiento más pesado,
                 └───────┬───────┘     acceso a más plugins
                         ▼
               Elasticsearch / S3 / Kafka / ...

Fluent Bit se ejecuta como un DaemonSet, una instancia ligera por nodo, haciendo lo mínimo necesario para recopilar y reenviar logs sin competir de forma significativa con las cargas de trabajo reales del nodo por CPU o memoria. Fluentd se ejecuta de forma central, en menor número, haciendo el trabajo pesado: parseo complejo, enriquecimiento y enrutamiento a cualquier destino que necesite un plugin que Fluent Bit no tiene. Cada herramienta hace la parte para la que realmente está construida, en lugar de que una sola herramienta lo haga todo de forma adecuada.

Elegir una sola, si solo necesitas una

• Solo Fluent Bit encaja cuando el despliegue tiene recursos limitados (dispositivos edge, alta densidad de Pods, sensibilidad al costo a escala) y las necesidades de destino y procesamiento están bien dentro de lo que cubre su conjunto de plugins.
• Solo Fluentd encaja cuando el despliegue no tiene recursos especialmente limitados y necesita un plugin, o un grado de flexibilidad de configuración, más maduro en el ecosistema de Fluentd, que lleva más tiempo establecido.
• Ambos juntos encaja exactamente en el patrón anterior: recopilación por nodo de alto volumen donde la huella importa, alimentando un procesamiento centralizado más pesado donde la huella importa menos.

Los complementos de logging de Kubernetes administrado de los proveedores de nube han ido adoptando cada vez más Fluent Bit en lugar de Fluentd a lo largo de los años, precisamente por los motivos de rendimiento y huella de la tabla anterior, algo que conviene saber si estás solucionando problemas en un clúster administrado y esperabas encontrar Fluentd ejecutándose en él: comprueba cuál de los dos está realmente desplegado antes de suponer.