Fluent Bit: recolección ligera de logs en producción
Actualizado: 2026-05-03
Fluent Bit[1] 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 en nodos escasos de recursos o en despliegues de alta densidad. Con la rama 3.x ya estable, se ha convertido en una opción por defecto razonable para flotas Kubernetes.
Puntos clave
- Binario de ~1,5 MB en C sin runtime: el coste de overhead se multiplica por nodos en un DaemonSet.
- Arquitectura de cuatro etapas: entradas → parsers → filtros → salidas, con fanout a múltiples destinos simultáneos.
- El filtro de Kubernetes es casi obligatorio: añade namespace, pod, contenedor y etiquetas a cada evento.
- Loki, Elasticsearch, S3, Kafka y HTTP genérico son las salidas más usadas; una misma instancia puede servir a varias a la vez.
- La cardinalidad de etiquetas y los parsers regex mal anclados son las dos causas habituales de incidentes en producción.
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. He visto clústeres donde Filebeat consumí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. 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: lectura incremental de archivos, journald, módulo de Kubernetes, puertos TCP o syslog.
- Parsers: estructuran los datos en campos tipados. JSON nativo o regex para logs propietarios.
- Filtros: donde ocurre la mayor parte del trabajo de enriquecimiento. El filtro de Kubernetes añade metadatos del pod; grep descarta ruido; modify añade o retira campos; Lua permite lógica arbitraria.
- Salidas: Loki, Elasticsearch, OpenSearch, Kafka, S3, Splunk, HTTP genérico. Un mismo evento puede ir a varias a la vez.
Instalación en la práctica
En Kubernetes, el chart oficial de Helm instala un DaemonSet con montajes y permisos resueltos:
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. La curva es moderada: el primer día cuesta orientarse, en una semana el formato se vuelve predecible. En máquinas sueltas, el binario estático de GitHub Releases funciona sin sorpresas.
Salidas frecuentes y cuándo elegirlas
Loki es la combinación natural si el stack de visualización es Grafana. Conviene elegir etiquetas con cardinalidad baja: cada valor distinto crea un índice en Loki y la factura de memoria crece rápido. Un UUID como etiqueta puede vaciar la RAM de un Loki en horas.
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.
S3 con compresión gzip y ventanas temporales: perfecto para archivo barato. El patrón que mejor funciona es mandar a Loki solo lo reciente y, en paralelo, empujar todo a un bucket que luego pase a Glacier.
Para la integración con el stack de monitorización de contenedores, ver monitorización de contenedores más allá de cAdvisor.
Comparativa con las 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 |
Promtail es elegante cuando Loki es el único destino. Vector aporta transformación potente y tipado estricto a cambio de más memoria. Filebeat es la mejor opción dentro del universo Elastic. Fluent Bit gana casi siempre que hay varios destinos o varios tipos de nodo en juego.
Filtros y parsers que merece la pena dominar
El filtro de Kubernetes es casi obligatorio: 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 propietarios. Anclarlos bien al principio y al final de la línea: un regex mal escrito pasa desapercibido hasta que la CPU de un nodo sube sin motivo aparente. Cuando la aplicación puede emitir JSON, conviene 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.
Mi lectura
Fluent Bit es la elección por defecto razonable para recolección de logs en Kubernetes y en el borde. Lo que mejor funciona 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.
La cardinalidad de etiquetas y los parsers personalizados son las dos fuentes habituales de problemas en producción. 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.
