Fluentd vs Fluent Bit: como escolher o coletor de logs da sua arquitetura

Toda arquitetura de logs começa com uma decisão que parece técnica demais para importar: quem coleta o log na origem. Essa escolha, no entanto, define o custo de infraestrutura, a confiabilidade do pipeline e o trabalho que sua equipe vai carregar pelos próximos anos.

Fluentd e Fluent Bit nasceram no mesmo projeto, carregam o mesmo sobrenome e resolvem problemas diferentes. Por isso, tratá-los como produtos rivais leva à pergunta errada. A pergunta certa é outra: qual dos dois ocupa cada camada da sua arquitetura?

Neste guia você encontra o comparativo técnico com números da documentação oficial e a matriz de cenários que indica quando usar cada ferramenta. Além disso, verá o padrão de duas camadas mais adotado em produção e um roteiro de verificação para quem pensa em migrar.

O que é o Fluentd

O Fluentd é um coletor de dados open source, escrito em C e Ruby. Ele unifica a coleta, o processamento e o roteamento de logs em ambientes de observabilidade numa camada central. Além disso, aplica transformações com um ecossistema enorme de plugins e mantém buffer configurável em memória ou em disco.

Criado em 2011 na Treasure Data, o projeto entrou na CNCF em novembro de 2016 e graduou em abril de 2019. Essa maturidade explica o tamanho do ecossistema: praticamente qualquer fonte ou destino exótico já tem plugin pronto.

Na prática, o Fluentd brilha como agregador. Ele fica no centro do fluxo de gerenciamento de logs e recebe dados de dezenas ou centenas de agentes. Em seguida, normaliza formatos, enriquece com metadados e decide para onde cada evento vai.

O que é o Fluent Bit

O Fluent Bit é um agente de telemetria escrito inteiramente em C, criado pelo mesmo projeto para rodar onde recursos são escassos. Ele coleta logs, métricas e traces na borda da infraestrutura, com footprint mínimo e sem dependências externas. Em seguida, encaminha esses dados para um agregador central ou direto para o backend de destino.

A origem explica o desenho. O Fluent Bit nasceu para sistemas embarcados e dispositivos IoT, cenários em que 40 MB de RAM por agente simplesmente não cabem. Depois disso, o Kubernetes transformou essa restrição em vantagem competitiva. Um DaemonSet roda em cada nó do cluster, então cada megabyte economizado se multiplica pelo número de nós.

Vale destacar um ponto que muita gente ignora: o Fluent Bit deixou de ser apenas um encaminhador de logs. A versão atual processa métricas e traces com ingestão OTLP nativa, o que o coloca como concorrente direto do coletor do padrão OpenTelemetry.

Fluentd vs Fluent Bit: comparativo direto

O Fluent Bit não substitui o Fluentd: os dois ocupam camadas diferentes do mesmo pipeline. O Fluent Bit vence em consumo de recursos e performance, enquanto o Fluentd vence em amplitude de integrações e profundidade de transformação. A tabela abaixo resume as diferenças com os valores publicados na documentação oficial do projeto.

Um alerta importante sobre esses números: os valores de plugins que circulam pela internet variam de 45 a 1.000. Blogs copiaram esses dados uns dos outros ao longo de quase uma década. Use sempre a tabela publicada na documentação oficial como referência.

Consumo de recursos: o que muda na conta de infraestrutura

A diferença de memória parece abstrata até você multiplicá-la pelo número de nós. Um agente que consome 40 MB em vez de 2 MB custa quase nada em um servidor. Em um cluster de 300 nós, porém, essa mesma diferença consome mais de 11 GB de RAM que poderiam estar rodando aplicação.

O impacto aparece também em CPU. Um benchmark publicado pela AWS em 2021 mediu os dois caminhos numa instância c5.9xlarge, com saída para o CloudWatch.

O resultado foi expressivo: o plugin baseado em Fluentd consumiu mais de quatro vezes a CPU e seis vezes a memória do equivalente em C.

Existe ainda a leitura inversa, que interessa a quem tem volume alto. Segundo o guia de migração publicado pela CNCF, o volume de logs processado com os mesmos recursos pode ficar de 10 a 40 vezes maior. O ganho exato depende do plugin utilizado.

Cuidado com o número de vitrine

Os 450 KB da documentação representam o consumo em repouso, não sob carga. Com tail em centenas de arquivos, parsing multiline e buffer em disco, um agente real trabalha na casa das dezenas de megabytes. A vantagem continua grande, mas dimensione seus limites de recurso com medição, nunca com o valor de folheto.

Plugins e extensibilidade: onde o Fluentd ainda ganha

Se o Fluent Bit vence em eficiência, o Fluentd mantém a liderança em cobertura. São mais de 1.000 plugins externos contra pouco mais de 100 nativos. Essa distância importa muito quando sua origem de dados foge do trivial.

Pense em um ERP legado que só exporta arquivo posicional. Considere também um appliance que fala apenas o protocolo Syslog ou um destino corporativo antigo sem conector moderno. Nesses casos, a chance de já existir um plugin Ruby pronto para o Fluentd é bem maior.

Há também a questão da transformação. Roteamento condicional complexo, lógica customizada em Ruby e enriquecimento com consulta a fontes externas ficam mais confortáveis no Fluentd. O Fluent Bit responde com processadores e filtros em Lua ou WASM, mas o caminho exige mais engenharia própria.

Buffering, backpressure e garantia de entrega

Essa é a parte que quebra em produção e que raramente aparece nas comparações. Quando o backend fica lento ou indisponível, o coletor precisa decidir o que fazer com os eventos que continuam chegando. Sem uma resposta boa, você perde log justamente durante o incidente.

Ambos oferecem buffer em memória e em disco. O Fluentd trabalha com um modelo de chunks e filas mais elaborado, com controle fino de retentativa, tempo de flush e limites por destino. Já o Fluent Bit usa storage.type filesystem com limites por tag, um modelo mais simples de operar e de entender.

Antes de fechar a arquitetura, teste o cenário ruim. Derrube o destino por dez minutos, observe se o agente segura os dados em disco e confira se ele reenvia tudo na volta. Esse teste vale mais que qualquer tabela comparativa.

Quando usar cada um: matriz de cenários

A decisão fica simples quando você para de perguntar qual ferramenta é melhor e passa a perguntar qual camada precisa ser resolvida. O cenário mais comum hoje é o cluster, tema que aprofundamos no guia de monitoramento de clusters Kubernetes.

Use a lista abaixo como atalho de decisão:

• Kubernetes e containers: Fluent Bit como DaemonSet por nó, o padrão adotado hoje.
• Borda, IoT e embarcados: Fluent Bit, sem discussão. Nenhum outro coletor maduro roda com esse footprint.
• Volume muito alto por nó: Fluent Bit, pela vantagem de throughput por unidade de recurso.

• Agregação central com roteamento complexo: Fluentd em hardware dedicado, onde a memória extra não pesa.
• Fontes legadas e formatos exóticos: Fluentd, pela chance maior de existir plugin pronto.
• Ambiente misto (VMs antigas mais cluster novo): os dois, na arquitetura de duas camadas.

A arquitetura de duas camadas: Fluent Bit na borda, Fluentd no centro

Esse é o desenho mais adotado em produção e a resposta real para a maioria das operações. O Fluent Bit roda em cada host ou nó, coleta com custo mínimo e encaminha via protocolo forward. O Fluentd concentra tudo, aplica as transformações pesadas e distribui para os destinos finais.

A vantagem é dupla. Você paga o custo alto de memória uma única vez, na camada central, em vez de pagá-lo em cada nó. Ao mesmo tempo, mantém acesso ao ecossistema completo de plugins no ponto onde ele realmente faz falta.

Configuração do agente na borda

No lado do Fluent Bit, a configuração se resume a ler os arquivos de log do nó e apontar a saída para o agregador:

# Agente por no: coleta e encaminha
pipeline:
  inputs:
    - name: tail
      path: /var/log/containers/*.log
      parser: cri
      storage.type: filesystem
  outputs:
    - name: forward
      match: '*'
      host: fluentd-agregador
      port: 24224

Configuração do agregador central

Do outro lado, o Fluentd escuta a porta 24224, aplica o buffer em disco e entrega ao backend escolhido:

# Camada central: recebe, trata e roteia
<source>
  @type forward
  port 24224
</source>

<match **>
  @type opensearch
  host backend-de-logs
  port 9200
  <buffer>
    @type file
    path /var/log/fluentd/buffer
    retry_max_interval 30
  </buffer>
</match>

Migrando do Fluentd para o Fluent Bit: o que verificar antes

Muita equipe começa a migração pelo lado errado, traduzindo arquivos de configuração linha a linha. Antes disso, faça um inventário honesto do que o seu Fluentd realmente executa hoje.

Verifique estes cinco pontos antes de mover qualquer nó para produção:

• Plugins em uso: confirme se cada input, filter e output ativo tem equivalente nativo.
• Lógica em Ruby: filtros customizados precisam virar Lua, WASM ou sair da camada de coleta.
• Parsing multiline: teste stack traces de Java com log real, nunca com exemplo sintético.

• Buffer e retentativa: traduza os limites atuais para o modelo por tag do Fluent Bit.
• Métricas do coletor: exponha o endpoint antes de migrar, assim você compara o antes e o depois.

O primeiro item costuma ser o bloqueador número um. Valide ainda o comportamento com o destino fora do ar antes de tocar em produção.

Em seguida, migre por ondas. Comece por um ambiente de homologação, siga por um grupo pequeno de nós de produção e só depois amplie.

Onde o coletor entra na sua estratégia de observabilidade

Escolher o coletor resolve apenas o primeiro trecho do caminho. O log ainda precisa de um destino que consulte bem e de um custo de retenção que caiba no orçamento. Tratamos essa decisão na comparação entre os principais backends de armazenamento.

Existe ainda um ponto cego clássico: quase ninguém monitora o próprio coletor. Um agente que morre silenciosamente em três nós não gera alarme, ele gera ausência de dados, que é bem mais difícil de perceber.

Monitore o próprio coletor

Tanto o Fluentd quanto o Fluent Bit expõem um endpoint HTTP de métricas próprias. Ative esse endpoint desde o primeiro dia e trate os números como métricas de primeira classe, no mesmo nível de CPU e disco dos servidores.

Quatro sinais merecem alerta configurado:

• Registros descartados: qualquer valor acima de zero indica perda de log em andamento.
• Ocupação do buffer em disco: crescimento contínuo denuncia backend lento ou fora do ar.

• Taxa de erro nas saídas: falhas de entrega repetidas antecipam a fila estourando.
• Ausência de eventos por origem: um nó que parou de enviar log é sintoma, nunca silêncio saudável.

Nesse ponto, a camada de coleta deixa de ser detalhe de infraestrutura e vira parte da estratégia de observabilidade da empresa. Sem log confiável chegando ao destino, métricas e traces contam apenas metade da história de cada incidente.

Conclusão

A comparação entre Fluentd e Fluent Bit termina em um lugar diferente do que a pergunta sugere. Não existe vencedor absoluto, existe camada certa para cada ferramenta. O Fluent Bit domina a borda pelo custo baixíssimo de recursos e pela performance. Já o Fluentd segue insubstituível quando a operação exige fontes incomuns ou transformação pesada.

Para a maioria das empresas, a resposta prática é combinar os dois: agente leve em cada nó e agregador robusto no centro. Mantenha ainda o coletor sob monitoramento, como qualquer outro componente crítico. Se você opera greenfield em Kubernetes, comece direto pelo Fluent Bit. Se carrega um parque legado, mantenha o Fluentd no centro e migre a borda por ondas.

Acima de tudo, valide a escolha com o seu volume real de logs e com o teste de destino indisponível. Quer ajuda para desenhar esse pipeline ponta a ponta e garantir que nenhum evento crítico se perca no caminho? Fale com um especialista da OpServices.