Fluent Bit es el recolector ligero del ecosistema Fluentd. Proyecto graduado de la CNCF, escrito en C, binario de unos 1,5 MB y consumo de memoria que rara vez pasa de 30 MB en régimen normal. Para quien sopesa Promtail, Vector o el agente de Datadog, entra en la conversación como algo serio, sobre todo con nodos escasos de recursos o alta densidad. En 2024, con la rama 3.x ya estable, se ha convertido en una opción por defecto razonable para flotas Kubernetes.
La propuesta me gusta porque invierte la pregunta habitual: en lugar de discutir cuántos recursos darle al agente, partimos de un coste casi despreciable y ampliamos según haga falta.
Por qué importa el tamaño
Un binario diminuto no es una curiosidad ingenieril. Cuando el recolector se despliega como DaemonSet, el coste se multiplica por nodos y cualquier memoria residente compite con las cargas útiles. He visto clústeres donde Filebeat se comía cientos de megabytes por nodo, dinero real gastado en un sidecar cuya única labor era mover texto. Fluent Bit, escrito en C y sin tiempo de ejecución por debajo, juega en otro orden de magnitud.
La densidad también importa en el borde. Un router industrial, un Raspberry Pi o una VM pequeña tienen muy poco margen, y la diferencia entre 10 y 100 MB decide si la observabilidad cabe o no. El rendimiento acompaña al tamaño: cerca de 100.000 eventos por segundo por nodo sin recalentarse, porque la ruta caliente evita memoria dinámica innecesaria.
Cómo se organiza internamente
La tubería conceptual tiene cuatro etapas que se repiten en casi cualquier configuración: entradas que leen datos, parsers que los estructuran, filtros que los enriquecen o descartan, y salidas que los despachan. Las entradas típicas son la lectura incremental de archivos, el lector de journald, el módulo de Kubernetes y puertos TCP o syslog.
Los filtros son donde ocurre la magia. El de Kubernetes consulta la API del clúster y añade a cada evento el espacio de nombres, el pod, el contenedor y las etiquetas pertinentes. El grep descarta ruido predecible, el modify añade o retira campos antes de que los datos salgan del nodo, y el Lua permite escribir una función corta sin recompilar nada cuando la lógica se complica. Las salidas más habituales son Loki, Elasticsearch y OpenSearch, Kafka, S3, Splunk y endpoints HTTP genéricos. Un mismo evento puede ir a varias a la vez, lo que abre patrones de fan-out sin broker intermedio.
Instalación en la práctica
En Kubernetes el camino más cómodo es el chart oficial de Helm, que instala un DaemonSet con montajes y permisos resueltos. Basta con añadir el repositorio fluent y lanzar el comando siguiente con un values.yaml apuntando a nuestra salida de preferencia. En Docker se arranca un contenedor con el archivo de configuración montado como volumen, y en máquinas sueltas el binario estático de GitHub Releases funciona sin sorpresas.
helm install fluent-bit fluent/fluent-bit --namespace logging --create-namespaceLos archivos siguen un formato tipo INI con bloques SERVICE, INPUT, PARSER, FILTER y OUTPUT. Cada bloque declara un nombre, un patrón de etiqueta para encajar eventos con filtros y salidas, y los parámetros del plugin. La curva es moderada: el primer día cuesta orientarse, en una semana el formato se vuelve predecible.
Salidas frecuentes y cuándo elegirlas
La salida hacia Loki es la combinación natural si el stack de visualización es Grafana. Se configura con host, puerto y un puñado de etiquetas estáticas para filtrar después. Conviene elegir etiquetas con cardinalidad baja, porque cada valor distinto crea un índice en Loki y la factura de memoria crece rápido.
Para Elasticsearch u OpenSearch la salida nativa gestiona reintentos, formato Logstash e inserciones por lotes. Si ya hay una plataforma Elastic, Filebeat está mejor integrado con Kibana y sus módulos prefabricados, pero Fluent Bit gana en consumo y en flexibilidad hacia otros destinos. La salida a S3 con compresión gzip y ventanas temporales es perfecta para archivo barato: un patrón que uso a menudo es mandar a Loki solo lo reciente y, en paralelo, empujar todo a un bucket que luego pase a Glacier.
Filtros y parsers que merece la pena dominar
El filtro de Kubernetes es casi obligatorio en clústeres: sin él los eventos pierden la mitad de su utilidad porque no se correlacionan con la carga que los emitió. Necesita permisos RBAC para leer metadatos de pods; cuando no enriquece, la causa casi siempre está ahí.
Los parsers regex son la herramienta para logs antiguos o propietarios. Conviene evitar patrones golosos y anclarlos bien al principio y al final de la línea: un regex mal escrito pasa desapercibido hasta que la CPU de un nodo empieza a subir sin motivo aparente. Cuando la aplicación puede emitir JSON, merece la pena cambiarla antes que sufrir parseos frágiles. El filtro Lua es la válvula de escape para casos que no encajan en ningún plugin estándar: veinte líneas de código en vez de un microservicio.
Fluent Bit frente a sus alternativas
| Aspecto | Fluent Bit | Promtail | Vector | Filebeat |
|---|---|---|---|---|
| Tamaño del binario | ~1,5 MB | ~10 MB | ~50 MB | ~30 MB |
| Memoria en reposo | 10-30 MB | 30-100 MB | 50-200 MB | 80-200 MB |
| Lenguaje | C | Go | Rust | Go |
| Catálogo de salidas | Amplio | Centrado en Loki | Amplio | Centrado en Elastic |
| Ecosistema | CNCF | Grafana | Datadog | Elastic |
Promtail es elegante cuando Loki es el único destino, porque comparte convenciones con Grafana y la integración cuesta cero. Vector aporta una capa de transformación muy potente y tipado estricto, a cambio de pagar el peaje de memoria. Filebeat es la opción mejor engrasada si se vive dentro del universo Elastic. Fluent Bit gana casi siempre que hay varios destinos, varios formatos o varios tipos de nodo en juego.
Mi lectura
Fluent Bit es la elección por defecto razonable para recolección de logs en Kubernetes y en el borde en 2024. No por ser el más nuevo ni el más lujoso, sino porque el triángulo entre coste de recursos, catálogo de integraciones y estabilidad está mejor equilibrado que en el resto. La graduación CNCF y el ritmo de publicación, ya en la 3.x, confirman que no es un proyecto de fin de semana.
Lo que he visto funcionar mejor es tratarlo como un bus de eventos ligero, no como una tubería punto a punto. Un único DaemonSet recoge todo, separa por etiquetas y reparte a Loki para consulta corta, a S3 para archivo y a Kafka cuando seguridad pide streaming. Ese patrón reduce el número de agentes distintos en el clúster y, con ello, la superficie operativa.
Donde todavía pondría un ojo es en la cardinalidad de etiquetas y en los parsers personalizados: son las dos fuentes habituales de problemas en producción. Una Loki que se queda sin memoria porque alguien metió un UUID como etiqueta, o un regex mal anclado que dispara la CPU bajo una tormenta de logs. Con disciplina en esos dos puntos, Fluent Bit desaparece de las reuniones de postmortem durante meses, que es el mayor cumplido para una pieza de infraestructura.
