As 6 Melhores Ferramentas de Código Aberto para Análise de Logs: Wazuh, Graylog e Mais

Como CISO num setor altamente regulamentado com cerca de 2 décadas de experiência em cibersegurança, trabalhei com várias plataformas de análise de logs do tipo SIEM. Dessas, selecionei as 6 melhores ferramentas de análise de logs de código aberto. Ao avaliar estas ferramentas, concentrei-me em fatores-chave como a flexibilidade de recolha de logs, deteção de eventos em tempo real, escalabilidade e suporte para vários formatos de log.

Funcionalidades de gestão e deteção de logs

Funcionalidades de integridade e não repúdio

Preços das ferramentas de análise de logs

Wazuh

Wazuh é um SIEM de código aberto que vai além da maioria das ferramentas nesta categoria. Combina monitoramento de logs, segurança de endpoints, monitoramento de integridade de arquivos, deteção de vulnerabilidades e deteção de eventos de segurança em tempo real numa única plataforma baseada em agentes.

Como funciona a gestão de logs no Wazuh

Um agente de endpoint implementado em cada sistema monitorizado recolhe logs localmente e encaminha-os para o servidor de gestão Wazuh para processamento e análise. O agente trata da recolha de logs, monitoramento de integridade e resposta ativa localmente; não é apenas um transportador. O Wazuh integra-se nativamente com o Elastic Stack, utilizando o Elasticsearch para armazenamento e pesquisa de logs, e o Kibana (via o plugin Wazuh) para dashboards e investigação.

O motor de regras é executado no gestor e avalia os eventos de log recebidos em relação a um conjunto de regras que inclui regras padrão, benchmarks CIS, mapeamentos MITRE ATT&CK e quaisquer regras personalizadas que escreva. Quando uma regra é acionada, o Wazuh gera um alerta e, se tiver uma resposta ativa configurada, pode tomar medidas automatizadas no endpoint: bloquear um IP, terminar um processo ou colocar um arquivo em quarentena.

Opções de hospedagem:

• Auto-hospedado: A plataforma é gratuito para download e utilização. O suporte anual opcional tem um preço baseado no número de endpoints monitorizados (servidores, estações de trabalho e dispositivos de rede). A organização é responsável pela manutenção do hardware e dos recursos neste modelo.
• Hospedado na cloud: O fornecedor de hospedagem gere o Servidor Wazuh e o Elastic Stack; só precisa de implementar os agentes. O preço depende dos dados indexados (anteriormente chamados armazenamento quente) e do período de retenção escolhido.

Funcionalidades de destaque:

• Recolha flexível de logs: O Wazuh ingere logs do Windows Event Viewer, mensagens de sistema Linux, logs de aplicações formatados em JSON e uma vasta gama de tipos de origem sem plugins adicionais. A cobertura pronta a usar é mais ampla do que a do Graylog ou Logstash, que requerem mais configuração para alcançar a mesma amplitude.
• Mapeamento MITRE ATT&CK: As regras mapeiam para técnicas MITRE ATT&CK por padrão, para que os alertas digam não só o que aconteceu, mas onde se enquadra numa cadeia de ataque. Isto é importante para a triagem; pode distinguir entre uma falha de autenticação ruidosa e uma tentativa de credential stuffing sem escrever correlações personalizadas.
• Integrações de terceiros: Integrações nativas com Office 365, AWS, GCP, Azure e Rapid7. Uma biblioteca Python incorporada suporta integrações personalizadas sem a configuração de plugins que o Syslog-ng ou Fluentd exigem.
• API e resposta ativa: Uma API RESTful abrange consultas de logs, gestão de regras e decodificadores, consultas de alertas e interações com agentes. A funcionalidade de resposta ativa executa scripts no endpoint monitorizado para bloquear endereços IP, terminar processos ou isolar hosts. Isto não está disponível no Elastic Stack sem ferramentas adicionais.

Graylog

Graylog é uma plataforma de gestão de logs com um núcleo de código disponível (Graylog Open) e edições pagas que se estendem às operações de segurança. Essa distinção é mais importante do que a maioria das descrições dos fornecedores deixa transparecer: o Graylog Open oferece recolha de logs, pesquisa, pipelines de processamento, dashboards e alertas baseados em streams, o que é suficiente para casos de uso operacionais. As regras Sigma, o alinhamento MITRE ATT&CK, UEBA, deteção de anomalias e gestão de casos são funcionalidades pagas das edições Graylog Security e Enterprise. Se o seu caso de uso principal são operações de segurança em vez de monitoramento de infraestrutura, considere isso no cálculo de custos.

Como funciona o Graylog

O Graylog recebe dados de log através de GELF (Graylog Extended Log Format), syslog, Beats ou entradas HTTP, armazena-os no Elasticsearch ou OpenSearch (via o Graylog Data Node) e torna-os pesquisáveis através de uma interface web. O sistema de streams é central para o funcionamento do Graylog: as mensagens recebidas são encaminhadas para streams com base em regras, e os alertas, pipelines e controlos de acesso são todos associados aos streams e não à camada de armazenamento. Isto significa que pode ter um stream para erros de aplicação encaminhado para uma equipa e um stream separado para eventos de autenticação encaminhado para segurança, com políticas de retenção e permissões diferentes em cada um.

Os pipelines de processamento permitem analisar, enriquecer, descartar ou reescrever mensagens antes do armazenamento. Se os logs da sua aplicação chegarem como texto não estruturado, escreve uma regra de pipeline para extrair campos em dados estruturados. O Graylog Illuminate (incluído nas edições pagas, disponível para Open com limitações) fornece analisadores e dashboards pré-construídos para origens comuns: Windows Event Logs, Cisco, Palo Alto, AWS CloudTrail e outros.

• O broker Kafka mínimo é 2.1. Qualquer entrada Kafka ligada a um broker mais antigo falhará após a atualização.
• Os tokens de API agora expiram após 30 dias por padrão. Qualquer automação, integração de monitoramento ou script que utilize um token de API de longa duração deixará de funcionar a menos que tenha uma política de rotação de tokens em vigor. Isto tende a manifestar-se como um incidente noturno quando algo deixa de reportar, em vez de durante a própria atualização.

Funcionalidades de destaque:

• Encaminhamento e processamento baseados em streams: O modelo de streams permite segmentar dados de log por origem, aplicação ou nível de sensibilidade no momento da ingestão e, em seguida, aplicar diferentes pipelines, políticas de retenção e controlos de acesso por stream. Isto é operacionalmente mais flexível do que os padrões de índice por origem do Elasticsearch.
• Extração e análise de logs: Os extratores extraem campos específicos das mensagens de log na ingestão. Os pipelines de processamento tratam de transformações mais complexas, lógica condicional, pesquisas, renomeação de campos e descarte de mensagens. Together oferecem um controlo refinado sobre o que acaba no armazenamento. O Graylog Illuminate também incluiu correções de analisadores na versão 7.0.3, incluindo uma correção na análise de timestamps do Apache HTTPD que estava a produzir valores de tempo incorretos.
• Pesquisa e investigação: A sintaxe de pesquisa do Graylog é mais simples do que Lucene/KQL para consultas básicas, o que é importante quando precisa que um engenheiro de prevenção pesquise logs à meia-noite sem documentação de referência. Pesquisas guardadas, intervalos de tempo relativos e sobreposições de histogramas estão todos disponíveis sem complementos pagos.
• Gestão de utilizadores com integração AD/LDAP: A autenticação Active Directory e LDAP é suportada no Graylog Open. Os controlos de acesso baseados em funções permitem restringir quais os streams e dashboards que cada equipa pode ver.

Onde o Graylog enfrenta dificuldades

O escalão gratuito do Graylog tem lacunas significativas se o seu caso de uso for operações de segurança: o suporte a regras Sigma, a deteção de anomalias e a gestão de casos são todos pagos. A dependência do Elasticsearch/OpenSearch acrescenta complexidade operacional semelhante à do ELK Stack. Em grande escala, o processamento de pipelines pode criar gargalos de desempenho que exigem uma afinação cuidadosa da ordenação das etapas do pipeline e da alocação de threads de trabalho.

Elastic Stack (ELK Stack) – Logstash

O Elastic Stack é um conjunto de produtos de código aberto; os seus componentes principais são o Elasticsearch, o Kibana e o Logstash.

Como funciona a análise de logs do ELK

O Logstash é um pipeline de processamento de dados do lado do servidor. Recebe dados de log de entradas (arquivos, Beats, syslog, Kafka, HTTP e dezenas de outros), aplica plugins de filtro para analisar e enriquecer os dados e encaminha a saída para um ou mais destinos. A maioria das implementações envia a saída para o Elasticsearch, mas o Logstash pode escrever simultaneamente para S3, um SIEM, uma fila de mensagens ou outro cluster Elasticsearch.

O Elasticsearch armazena os dados de log processados e torna-os pesquisáveis utilizando um índice invertido. É a razão pela qual o ELK escala para petabytes e ainda devolve resultados de pesquisa em menos de um segundo em consultas direcionadas, mas esse desempenho vem da estrutura de índices, o que significa que cargas de trabalho com muita escrita exigem uma gestão cuidadosa do ciclo de vida dos índices. O Kibana funciona sobre o Elasticsearch e fornece a camada visual: dashboards, a vista Discover para pesquisa de logs ad-hoc, Canvas para relatórios personalizados e Lens para visualizações drag-and-drop.

• Pesquisa de texto completo em escala: A arquitetura de índice invertido do Elasticsearch suporta pesquisas em menos de um segundo em milhares de milhões de entradas de log. KQL (Kibana Query Language) e ES|QL (a nova linguagem de consulta baseada em pipes no 9.x) dão aos analistas duas interfaces de consulta diferentes dependendo de como preferem trabalhar. Para investigações de logs complexas em grandes conjuntos de dados, nada no espaço de código aberto iguala a profundidade de pesquisa do ELK.
• Ingestão e filtragem de múltiplas origens: O Logstash tem cerca de 200 plugins de entrada e 200 plugins de filtro. O filtro grok trata de texto não estruturado usando padrões de captura nomeados; o filtro json trata de logs JSON estruturados; o filtro csv trata de dados tabulares. Várias etapas de filtro são executadas em sequência, para que possa analisar uma linha syslog bruta, extrair campos, pesquisar um IP numa base de dados GeoIP e descartar mensagens de nível debug antes que o evento chegue ao Elasticsearch, tudo num único pipeline.
• Deteção de anomalias com machine learning: As funcionalidades de ML do Kibana (pagas) identificam padrões incomuns nos dados de log sem exigir a definição de limites. Útil para detetar ataques lentos ou degradação gradual do desempenho que os alertas de limite fixo não detetam.
• Dashboards do Kibana: As opções de visualização do Kibana são extensas: séries temporais, mapas, mapas de calor, tabelas de dados, medidores e muito mais. Pesquisas guardadas e padrões de índice significam que os analistas podem partilhar contextos de investigação entre equipas.
• Encaminhamento de saída extensível: Um único pipeline do Logstash pode escrever para Elasticsearch, um bucket S3, um segundo cluster Elasticsearch para recuperação de desastres e um tópico Kafka para processamento a jusante, simultaneamente.

Onde o ELK enfrenta dificuldades

A sobrecarga operacional é real. Os clusters Elasticsearch exigem planeamento de memória (a heap da JVM precisa de dimensionamento cuidadoso), gestão de shards (demasiados shards pequenos ou poucos shards grandes prejudicam o desempenho) e configuração de políticas de ciclo de vida de índices para controlar os custos de retenção.

A maioria das equipas que executam ELK em escala acaba por ter um engenheiro de plataforma dedicado cuja principal responsabilidade é o Elasticsearch. A situação da licença também vale a pena compreender: os componentes do Elastic Stack estão sob a Elastic License 2.0, não sendo de código aberto aprovado pela OSI. O uso auto-hospedado é gratuito, mas oferecer o Elasticsearch como um serviço gerido a terceiros não é permitido no escalão gratuito.

Fluentd

O Fluentd é um coletor de dados de código aberto sob a Apache License 2.0, concebido para unificar a ingestão e o encaminhamento de logs em infraestruturas heterogéneas. A função principal é simples: aceitar eventos de log de origens, aplicar processamento opcional e encaminhá-los para destinos. O Fluentd não armazena nem analisa logs por si só; é um coletor e encaminhador, não uma plataforma de análise de logs¹

Essa distinção é importante ao avaliá-lo em comparação com o Wazuh ou Graylog. O Fluentd é tipicamente a primeira camada num pipeline maior. Uma arquitetura comum: os agentes Fluentd em cada servidor recolhem logs de aplicações, logs de sistema e logs de contentores, armazenam-nos em buffer localmente (para que nada seja perdido se o destino a jusante estiver temporariamente indisponível), aplicam análise e filtragem e encaminham o resultado para Elasticsearch, Splunk, um SIEM na cloud ou outro backend de armazenamento. A análise acontece no que recebe os dados.

Fluentd vs. Fluent Bit

As equipas que avaliam o Fluentd para ambientes Kubernetes muitas vezes acabam por escolher o Fluent Bit, e vale a pena perceber porquê. O Fluent Bit é um encaminhador leve no mesmo ecossistema CNCF, aproximadamente um binário de 4 MB em comparação com o processo baseado em Ruby do Fluentd que é notavelmente mais pesado. Para implementações Kubernetes onde se pretende um coletor de logs a correr como um DaemonSet em cada nó, a diferença de consumo de recursos é significativa em escala. O Fluent Bit também suporta análise de logs multilinha, injeção dinâmica de metadados a partir de labels e anotações de pods Kubernetes e tratamento de contrapressão incorporado para evitar perda de dados quando os destinos a jusante ficam mais lentos.

O Fluentd é a melhor opção quando precisa de todo o ecossistema de 500+ plugins ou de lógica de encaminhamento complexa que a biblioteca de plugins mais pequena do Fluent Bit não consegue cobrir. Para a maioria das implementações nativas de Kubernetes que fazem envio simples de logs, o Fluent Bit é a escolha prática. Os projetos partilham conceitos de configuração, pelo que alternar entre eles não é uma reescrita completa.

Como o Fluentd trata os dados de log

O Fluentd modela os dados de log como um fluxo de eventos com tags. Cada evento tem uma tag (uma string separada por pontos como app.web ou system.syslog), um timestamp e um registo. As tags orientam o encaminhamento: as diretivas match na configuração especificam quais as tags que são enviadas para onde, quais os filtros que se aplicam e em que ordem. Várias saídas podem corresponder à mesma tag, para que possa enviar os mesmos eventos tanto para o Elasticsearch como para um arquivo S3 simultaneamente.

O sistema de buffer é o que torna o Fluentd fiável em produção. Em vez de escrever diretamente no destino, os eventos acumulam-se num buffer e são descarregados em blocos em intervalos configuráveis ou quando o buffer atinge um limite de tamanho. Se o destino estiver inacessível, os eventos permanecem no buffer e são reintroduzidos com backoff exponencial.

Funcionalidades de destaque:

• 500+ plugins da comunidade: Abrange integrações com a maioria dos principais destinos de log e origens de dados sem desenvolvimento personalizado.
• Encaminhamento flexível de dados: Os eventos podem ser encaminhados para vários destinos simultâneos, como arquivos, RDBMS, NoSQL, IaaS, SaaS e Hadoop, com base em regras de encaminhamento por tags.
• Foco no processamento de logs: O Fluentd é otimizado para processamento e encaminhamento de logs em escala, sendo adequado como camada de recolha e encaminhamento à frente do Elasticsearch ou de outros backends de armazenamento, em vez de como plataforma de análise independente.

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

Syslog-ng

O Syslog-ng é um programa de gestão de logs de código aberto que recolhe, classifica, transforma e encaminha dados de log de várias origens para armazenamento ou plataformas a jusante. A sua capacidade distintiva é o processamento estruturado: os logs podem ser normalizados para um formato consistente antes de serem encaminhados para sistemas como Apache Kafka ou Elasticsearch.

Capacidades:

• Classificar e estruturar logs usando analisadores incorporados como o csv-parser
• Armazenar logs em arquivos, filas de mensagens (AMQP) ou bases de dados (PostgreSQL, MongoDB)
• Encaminhar para plataformas de big data, incluindo Elasticsearch, Apache Kafka ou Hadoop

Funcionalidades distintivas:

• Arquivo automatizado de logs: O Syslog-ng trata da rotação e arquivo de logs nativamente, incluindo compressão e nomes de arquivos com timestamp. Para ambientes com requisitos de conformidade de retenção, isto reduz a necessidade de ferramentas externas como o logrotate sobrepostas.
• Suporte a múltiplos formatos de mensagem: RFC3164 (syslog tradicional), RFC5424 (syslog estruturado), JSON e formatos chave-valor são todos analisados nativamente. O Syslog-ng pode receber uma mensagem RFC3164 e transmiti-la como RFC5424 com campos de dados estruturados adicionados, o que é útil ao alimentar sistemas que esperam o formato syslog moderno.
• Transporte encriptado: O transporte syslog encriptado com TLS é suportado nativamente tanto para receção como para encaminhamento. Isto é importante em ambientes onde os dados de log transitam por segmentos de rede não confiáveis.
• Encaminhamento condicional: As expressões de filtro permitem encaminhar com base em qualquer campo analisado: gravidade, instalação, host ou campos personalizados extraídos pelos analisadores. Uma única instância do syslog-ng pode encaminhar falhas de autenticação para o stream da equipa de segurança, erros de aplicação para o stream da equipa de desenvolvimento e mensagens de debug para /dev/null.

Onde o syslog-ng se encaixa (e onde não se encaixa)

O Syslog-ng é a escolha certa quando as suas origens de log são principalmente dispositivos de rede e servidores que comunicam via syslog, e quando precisa de recolha fiável e de alto débito com extração de campos estruturados antes de encaminhar para um backend de armazenamento. Não é uma plataforma de análise de logs; não há interface de consulta, nem dashboards, nem alertas incorporados. Funciona como a camada de recolha e encaminhamento à frente do Elasticsearch ou Graylog, não como uma ferramenta independente.

Nagios

Um esclarecimento necessário antes de prosseguir: o Nagios Core é o projeto de monitoramento de código aberto licenciado sob GPL, e foca-se no monitoramento de hosts, serviços e redes, em vez de análise de logs.[15] O produto aqui descrito é o Nagios Log Server, um produto comercial separado da Nagios Enterprises. Se procura especificamente uma ferramenta de análise de logs de código aberto e sem custos, o Nagios Log Server não é essa ferramenta. O que oferece é uma plataforma de gestão de logs com suporte comercial de um fornecedor com um longo histórico em monitoramento de infraestrutura.

O Nagios Log Server recolhe dados de log em tempo real e alimenta uma interface de pesquisa. É compatível com servidores Windows, Linux e Unix e inclui um assistente de configuração para integrar novos endpoints ou aplicações.²

Funcionalidades de destaque:

• Monitoramento de serviços de rede: Abrange SMTP, POP3, HTTP, PING e outros serviços de rede com foco na saúde da infraestrutura.
• Monitoramento de recursos de host: Acompanha a carga do processador, utilização do disco e saúde do sistema em todos os hosts monitorizados.
• Rotação e arquivo de arquivos de log: Rotação automatizada e arquivo de longo prazo sem intervenção manual.
• Filtragem geográfica de logs: Filtra dados de log por origem geográfica e gera mapas de fluxo de tráfego.
• Interface web: Interface opcional para visualizar o estado atual da rede e arquivos de log.

Para orientação sobre como escolher a ferramenta ou serviço certo, consulte as nossas fontes baseadas em dados: software de análise de logs.

Perguntas frequentes

Cite esta pesquisa

Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.

@misc{hafa2026,
  author = {Hafa, Adil and Sezer, Sena},
  title  = {{As 6 Melhores Ferramentas de Código Aberto para Análise de Logs: Wazuh, Graylog e Mais}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/open-source-log-analysis-tools}},
  note   = {AIMultiple. Acessado em 23 Junho 2026}
}

Links de referência

1.

Fluentd | Open Source Data Collector | Unified Logging Layer

2.

Nagios Log Server | Nagios Enterprises

Nagios Enterprises

Adil Hafa

Consultor Técnico

Siga-nos

Adil é um especialista em segurança com mais de 16 anos de experiência em defesa, varejo, finanças, câmbio, pedidos de comida e governo.

Ver perfil completo

Pesquisado por

Sena Sezer

Analista do setor

Siga-nos

Sena é analista do setor na AIMultiple. Ela concluiu sua graduação na Universidade Bogazici.

Ver perfil completo

Seja o primeiro a comentar

Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.

Nome

Endereço de email

Comentário

0/450

Postar comentário