Fluentd ou Logstash: qual coletor de logs utilizar? 

Quando temos sistemas distribuídos em grande escala, o registro de logs se torna essencial para a observabilidade, o monitoramento e a segurança.

Independentemente da arquitetura de nossos sistemas, seja monolito ou microsserviços, há uma complexidade devido ao número de partes móveis que possuem e aos desafios que enfrentam em relação ao gerenciamento, à implantação e ao dimensionamento. 

Nesse cenário, as ferramentas de gerenciamento de logs auxiliam as equipes de DevOps e SRE a monitorar e melhorar o desempenho, evitar e corrigir erros e visualizar eventos. 

Escolher o coletor de logs adequado é essencial, e neste artigo, exploramos as distinções fundamentais entre Fluentd e Logstash. Analisaremos desempenho, ecossistema de plugins e abordagens de roteamento para ajudá-lo a tomar uma decisão informada.

Resumo em 1 minuto Escolha Fluentd se você está em Kubernetes/Docker e quer um coletor leve, com buffering configurável para lidar com picos/backpressure e encaminhar logs com flexibilidade para diferentes destinos. Escolha Logstash se você já opera Elastic Stack (Elasticsearch/Kibana) e precisa de pipelines ricos de parsing/transformações, com integração direta ao ecossistema Elastic e uma abordagem forte para ETL de eventos. Para agente leve (rodando “na borda”/nos nós): é comum comparar Fluent Bit (ecossistema Fluentd) e Beats/Filebeat (ecossistema Elastic), deixando Fluentd/Logstash para a camada de agregação/processamento. Regra prática: primeiro defina seu backend e sua estratégia de observabilidade; depois escolha o coletor e o agente que melhor equilibram custo, confiabilidade e complexidade operacional.

Componentes de Log Analytics: agente, coletor, storage e dashboards

Em uma linguagem simples, uma ferramenta de análise de logs tem os seguintes componentes principais: 

• Exportador de logs (Configurar logs por host) (agentes);
• Coletor de logs (concentradores/processadores);
• Armazenamento de logs (backend de logs);
• Visualização de logs (dashboards).

Neste artigo, discutiremos dois coletores de logs de código aberto muito famosos, que são o Logstash e o Fluentd.

O segredo de qualquer ferramenta de análise de logs são os coletores de logs. Ambos operam em servidores, obtêm métricas do servidor, analisam todos os logs e os transferem para backends como Elasticsearch ou Grafana Loki. É o mecanismo de roteamento deles que possibilita a análise de logs. 

Sob a licença Apache 2, tanto o Logstash quanto o Fluentd operam como coletores de dados de código aberto. O Logstash é conhecido popularmente como a parte “L” da pilha ELK gerenciada pela própria Elastic. Já o Fluentd é desenvolvido e gerenciado pela Treasure Data, sendo também adotado como projeto da Cloud Native Computing Foundation (CNCF). 

Fluentd vs Logstash: por onde começar a comparar?

Preparamos uma tabela para lhe dar uma breve visão geral das principais diferenças. Mais adiante, discutiremos cada ponto em detalhes. 

Para usar o comparativo como critério de decisão, foque em pontos operacionais: deploy/arquitetura (Kubernetes/containers vs stack Elastic), parsing e transformações, roteamento (tags vs condicionais), buffering/filas e confiabilidade (retries, backpressure, persistência) e operação do pipeline (monitorar filas/buffers e reprocessar falhas).

Em geral, a melhor opção sempre é a que você consegue operar com previsibilidade no dia a dia.

O que muda na prática entre Fluentd e Logstash?

Ecossistema de plugins 

Os plugins ajudam qualquer ferramenta a aprimorar sua funcionalidade. O Fluentd e o Logstash têm um ecossistema rico para plugins, incluindo vários sistemas de entrada (arquivos e TCP/UDP), filtros e destinos de saída (InfluxDb, Grafana Loki, Elasticsearch, AWS, GCP etc.). 

A diferença principal é o modelo de organização: no repositório Logstash, o ecossistema é fortemente associado ao Elastic Stack e tende a seguir uma experiência mais centralizada (integrações e plugins evoluem no ritmo do stack). Quanto aos plugins no Fluentd, é comum encontrar um ecossistema muito amplo e mais distribuído, com recursos mantidos por diferentes times e comunidades, o que dá flexibilidade, mas exige mais cuidado na seleção (maturidade, manutenção e compatibilidade).

Uso de memória/ desempenho 

Embora o desempenho seja subjetivo, dependendo do caso de uso do usuário, o Logstash consome 120 MB a mais de memória do que o Fluentd, que utiliza 40 MB. Ademais, ao considerarmos os equipamentos modernos, essa discrepância pode parecer insignificante. No entanto, quando implementado em milhares de dispositivos de infraestrutura, essa diferença de 80*1000 representa um notável acréscimo de 80 GB de uso adicional de memória.

Portanto, no Logstash, você pode evitar esse problema executando o ElasticBeats em vez de executá-lo em um único leaf node.

O Elastic Beats é um coletor de logs eficiente em termos de recursos criado para fins específicos, em que cada Beat se concentra em apenas uma fonte de dados e faz isso bem. O Fluentd usa o Fluent Bit, uma versão incorporável de baixo impacto do Fluentd escrita em C. 

Se você estiver executando aplicativos pequenos, é recomendável usar o Fluent Bit, projeto este também da Cloud Native Computing Foundation (CNCF). Por outro lado, o Elastic Beats é uma versão leve do Logstash. Para cargas de trabalho menores, é preferível usar o Elastic Beats. Mas se o seu caso de uso envolver mais processamento de dados além do transporte de dados, você precisará usar ambos. 

Transferência de dados 

O Logstash não possuía um sistema de buffer embutido para transferência de dados. Nas versões mais recentes, o sistema foi aprimorado com a adição de filas persistentes (PQ) e Dead Letter Queue (DLQ), que são por padrão encontram-se desabilitadas.

Recomendamos incorporar brokers de filas externas, como Redis ou Kafka, ao pipeline para garantir persistência entre reinicializações. O Redis atua como um "corretor", enfileirando eventos provenientes de remetentes remotos do Logstash.

O Fluentd tem um sistema de buffer configurável embutido e não depende de filas externas para persistência. No entanto, a configuração é bastante complexa. Por causa disso, ele é mais seguro usar do que o Logstash em relação ao transporte de dados. Recomenda-se também incluir brokers de fila como Apache Kafka, RabbitMQ ou ZeroMQ com filas persistentes para garantir confiabilidade (reliability). 

Roteamento de eventos 

O roteamento de eventos significa o envio de dados e mensagens entre aplicativos e sistemas. Sua função é crucial ao avaliar um sistema de registro e gerenciar o roteamento de eventos. 

O Fluentd usa uma abordagem de marcação, enquanto o Logstash usa instruções if-then-else para roteamento de eventos.

Dessa forma, podemos definir determinados critérios com instruções If/Then/Else - para executar ações em nossos dados. A abordagem de marcação (tags) parece um pouco mais fácil de usar do que as instruções condicionais. Com o Fluentd você terá de marcar cada uma de suas fontes de dados (entradas). Ele usa tags para comparar entradas com diferentes saídas e, em seguida, encaminha os eventos para a saída correspondente. 

Interpretação de logs 

Os componentes para análise de logs diferem de ferramenta para ferramenta. O Fluentd usa analisadores padrão incorporados (JSON, regex, CSV etc.), e o Logstash usa plugins para isso. Isso torna o Fluentd mais favorável em relação, pois não precisamos lidar com nenhum plugin externo para esse recurso.

Existe a possibilidade também de criar seus próprios plugins, tanto em Logstash quanto em Fluentd, ambos em Ruby. A Vericode criou um plugin parsear log do protocolo FIX para Logstash e outro para Fluentd. 

Suporte do Docker 

O Docker fornece um driver de registro fluentd embutido. O driver de registro envia os registros do container para o coletor fluentd como dados de registro estruturados.

No caso do Logstash, é necessário um agente extra (filebeat) no container para enviar os logs. Portanto, se você estiver executando seus aplicativos com o Docker, o Fluentd é uma opção mais natural. Os registros podem ser enviados diretamente para o serviço a partir do STDOUT. Assim, o Fluentd torna a arquitetura geral de logging do Docker menos complexa e menos arriscada. 

Quando preferir o Fluentd ao Logstash ou vice-versa? 

Para os ambientes Kubernetes ou equipes que trabalham com o Docker, o Fluentd é o candidato ideal para um coletor de logs. Possui um driver e um analisador de logs do Docker integrados.

Sendo assim, você não precisa de um agente extra no container para enviar os logs para o Fluentd. Devido a esse recurso, a arquitetura é menos complexa e arriscada para erros de registro. Além disso, se a memória for seu ponto fraco, opte pelo Fluentd, pois ele é mais eficiente em termos de memória devido à falta de dependências de JVM e de tempo de execução do Java. 

A capacidade de processamento do Fluentd é maior do que do Logstash, ou seja, se você pretende economizar dólares do seu orçamento de cloud: opte por Fluentd. 

Se você possui múltiplas fontes de dados e pretende utilizar uma visualizar em um "Single Pane of Glass”, com visualizador Grafana ou outro, o Fluentd também é a melhor opção. 

Por outro lado, o Logstash funciona bem com o Elasticsearch e o Kibana. Portanto, se você já tiver o Elasticsearch e o Kibana em sua infraestrutura, ele será sua melhor aposta para um coletor de logs.  

Quer se aprofundar em outro comparativo feito pela nossa equipe? Leia mais sobre: Kibana vs Grafana

A escolha para Log Analytics da Vericode

Na comparação das duas ferramentas o Fluentd se mostrou mais eficiente e consumiu menos recursos que o Logstash uma vez que não precisa da JVM (java). Além disso, a quantidade de plugins é bem maior e eles não ficam centralizados, ao contrário do Logstash onde todos os plugins se encontram em um único repositório git.  

Outra característica do Fluentd é sua abordagem de roteamento melhor, pr marcar eventos através de tags, o que é mais fácil do que usar condições if-else. 

Diante disso, caso haja a necessidade de realizar a coleta de um alto volume de logs, o Fluentd se apresenta como uma solução muito mais eficiente, reduzindo a necessidade de recursos computacionais para alcançar os mesmos objetivos em comparação ao Logstash e fornecendo um output para qualquer Plataforma de Log com seus Plugins.   

E seu orçamento ainda sai ganhando, pois com você necessita de menos recursos computacionais, portanto, menor gastos com nuvem você terá. 

No dia a dia, a decisão entre Fluentd e Logstash é só uma parte do problema. O que realmente sustenta escala é ter um pipeline de logs que feche o ciclo detectar → investigar → corrigir → prevenir com governança, observabilidade e integração com o fluxo de engenharia.

É nessa visão integrada que a Vericode atua, ajudando times a desenhar e operar pipelines confiáveis, conectando logs a diagnóstico, RCA e redução de downtime.

Se você quer revisar sua arquitetura de Log Analytics (coleta, parsing, roteamento, buffers/filas e operação), fale conosco para um diagnóstico rápido do seu cenário.