VictoriaLogs vs Graylog vs ELK: Qual o Melhor para ISP?

O Desafio de Logs em Provedores de Internet

Provedores de internet geram um volume absurdo de logs. Um ISP médio com 3.000 assinantes pode facilmente produzir:

• 100-500 milhões de registros NAT/CGNAT por dia
• 50.000-200.000 registros RADIUS por dia
• 10-50GB de dados brutos de log por dia

Para armazenar 1 ano desses logs (obrigação legal do Marco Civil), estamos falando de 3-18TB de dados brutos. Gerenciar esse volume — ingerir, indexar, armazenar, consultar e reter por 1+ ano — exige uma engine de logs robusta.

Neste artigo, comparamos as três principais opções open-source disponíveis: VictoriaLogs, Graylog e ELK Stack (Elasticsearch + Logstash + Kibana). A análise é focada no cenário específico de ISPs brasileiros.

Visão Geral de Cada Solução

VictoriaLogs

Desenvolvido pela VictoriaMetrics (empresa conhecida pelo banco de dados de métricas de mesmo nome), o VictoriaLogs é a opção mais nova das três. Lançado em 2023, foi projetado desde o início para ser extremamente eficiente em recursos — a antítese das soluções Java pesadas.

• Linguagem: Go
• Licença: Apache 2.0 (open-source)
• Arquitetura: Binário único, sem dependências externas
• Query language: LogsQL (própria)

Graylog

O Graylog é uma plataforma de gerenciamento de logs estabelecida, com mais de 10 anos de mercado. Utiliza Elasticsearch/OpenSearch como backend de armazenamento e MongoDB para metadados.

• Linguagem: Java
• Licença: SSPL (Server Side Public License) para Open, comercial para Enterprise
• Arquitetura: Graylog + Elasticsearch/OpenSearch + MongoDB
• Query language: Lucene/Elasticsearch queries

ELK Stack

O ELK Stack é a combinação de Elasticsearch (armazenamento e busca), Logstash (ingestão e transformação) e Kibana (visualização). É provavelmente a solução de logs mais conhecida do mundo.

• Linguagem: Java (Elasticsearch, Logstash), Node.js (Kibana)
• Licença: SSPL (Elasticsearch 7.11+) ou OpenSearch (fork Apache 2.0)
• Arquitetura: 3+ componentes separados
• Query language: KQL, Lucene, EQL

Tabela Comparativa

Análise Detalhada

1. Consumo de Recursos: A Diferença é Brutal

Este é o ponto onde o VictoriaLogs se destaca de forma mais dramática. Vamos colocar em perspectiva para um provedor com 3.000 assinantes gerando ~200M de logs NAT/dia:

VictoriaLogs

# Requisitos para 200M logs/dia, retenção 1 ano
RAM: 2-4GB
CPU: 2 vCPUs
Disco: ~800GB SSD (com compressão ~10x)
Servidor: VM simples ou LXC container

O VictoriaLogs é escrito em Go, compilado para um binário nativo, sem JVM, sem garbage collector pesado. Ele usa memory-mapped files e compressão agressiva (baseada em zstd) que atinge taxas de 10x ou mais em dados de log repetitivos (como logs CGNAT, que têm estrutura altamente previsível).

Graylog

# Requisitos para 200M logs/dia, retenção 1 ano
RAM: 12-16GB (4GB Graylog JVM + 8GB Elasticsearch JVM + 1GB MongoDB)
CPU: 4-6 vCPUs
Disco: ~3TB SSD
Servidor: VM dedicada ou bare metal

O Graylog precisa de três processos Java/MongoDB rodando simultaneamente. O Elasticsearch é particularmente faminto por memória — a recomendação oficial é dar metade da RAM do servidor para o heap da JVM.

ELK Stack

# Requisitos para 200M logs/dia, retenção 1 ano
RAM: 16-32GB (8-16GB ES + 4GB Logstash + 2GB Kibana)
CPU: 6-8 vCPUs
Disco: ~3-5TB SSD
Servidor: VM grande ou cluster

O ELK Stack é o mais pesado dos três. Para volumes de ISP, é comum precisar de um cluster de 2-3 nós Elasticsearch para manter a performance aceitável. O Logstash é particularmente guloso — muitos optam por substituí-lo pelo Filebeat ou Vector para reduzir o consumo.

Na prática: O VictoriaLogs roda confortavelmente em uma VM de R$ 50/mês. O Graylog precisa de uma VM de R$ 150-200/mês. O ELK Stack pode exigir R$ 300-500/mês em infraestrutura. Para um provedor que está buscando compliance com custo controlado, essa diferença é significativa.

2. Complexidade de Setup e Manutenção

VictoriaLogs: Simplicidade radical

O setup inteiro consiste em:

# Download do binário
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.x.x/victoria-logs-linux-amd64-v1.x.x.tar.gz
tar xzf victoria-logs-*.tar.gz

# Iniciar (sim, é só isso)
./victoria-logs-prod -storageDataPath=/data/vlogs -retentionPeriod=13months

# Enviar logs via syslog
# Configure seu MikroTik para enviar para IP:514

Um binário único, sem dependências, sem Java, sem MongoDB, sem cluster. O VictoriaLogs aceita syslog nativamente na porta 514 e expõe uma API HTTP para consultas. A configuração inteira cabe em uma flag de linha de comando.

Manutenção: praticamente nenhuma. Não há shards para rebalancear, não há JVM para tunar, não há índices para otimizar. O retenção é automática — dados mais antigos que o período configurado são apagados automaticamente.

Graylog: Complexidade moderada

O setup envolve:

1. Instalar e configurar MongoDB
2. Instalar e configurar Elasticsearch (ou OpenSearch)
3. Instalar e configurar o Graylog Server
4. Configurar inputs (syslog), extractors (parsing), streams (roteamento)
5. Configurar index rotation e retention

Manutenção: regular. O Elasticsearch precisa de atenção com shards (muitos shards pequenos degradam performance), o JVM heap precisa de tuning, e o MongoDB precisa de cleanup periódico. A rotação de índices precisa ser configurada corretamente para não estourar o disco.

ELK Stack: A mais complexa

O setup envolve:

1. Instalar e configurar Elasticsearch (idealmente cluster multi-node)
2. Instalar e configurar Logstash (ou Filebeat + Ingest Pipelines)
3. Configurar pipelines de parsing no Logstash (grok patterns para logs NAT)
4. Instalar e configurar Kibana
5. Configurar ILM (Index Lifecycle Management) para retenção
6. Configurar templates de índice, mappings, etc.

Manutenção: alta. O ELK Stack é poderoso, mas exige um operador que entenda de Elasticsearch internals. Problemas comuns: disco cheio por shards não rotacionados, OOM kills por JVM mal configurada, performance degradada por mappings incorretos, split brain em clusters.

3. Performance de Consulta

Para o caso de uso de ISP (buscar IP + porta + timestamp em bilhões de registros), benchmarks comparativos mostram:

Consulta típica: "Quem usou o IP 200.200.200.5 porta 2500 em 15/01/2026 14:32?"

Benchmarks aproximados em hardware equivalente (4 vCPUs, 8GB RAM). Resultados reais variam conforme configuração e hardware.

O VictoriaLogs é consistentemente mais rápido, especialmente em consultas que envolvem scanning de grandes intervalos de tempo — exatamente o padrão de consultas judiciais, onde você precisa buscar em dias ou semanas de dados.

O segredo está na compressão e no layout de dados em disco. O VictoriaLogs organiza os dados de forma otimizada para leitura sequencial, e a compressão ~10x significa que há muito menos I/O de disco para a mesma quantidade de dados lógicos.

4. Uso de Disco

A compressão faz diferença enorme no custo de armazenamento a longo prazo:

Para um ISP que precisa de 1 ano de retenção, a diferença entre 540GB e 2.5TB é significativa em custo de SSD.

5. Funcionalidades Específicas para ISP

Aqui é onde precisamos ser honestos: nenhuma das três soluções tem funcionalidades específicas para ISP out of the box. Nenhuma delas gera relatórios judiciais, faz correlação com RADIUS, ou entende o formato de logs CGNAT nativamente.

São engines de logs genéricas. Para transformá-las em uma solução de compliance ISP, você precisa:

• Configurar parsers para o formato de log do seu equipamento CGNAT
• Criar integração com o RADIUS para correlação
• Desenvolver interface de consulta amigável para o NOC
• Implementar geração de relatórios judiciais
• Configurar monitoramento de gaps e alertas

Isso é exatamente o que o NATVault faz: pega o VictoriaLogs como engine e adiciona toda a camada ISP-específica por cima.

Por Que o NATVault Escolheu VictoriaLogs

A decisão de usar VictoriaLogs como engine do NATVault foi baseada em três fatores:

1. Eficiência de recursos: Permite que o NATVault rode em VMs modestas, reduzindo o custo para o provedor (especialmente na versão on-premise)
2. Simplicidade operacional: Binário único sem dependências = menos coisas para quebrar em produção. Menos manutenção = menos custo operacional
3. Compressão superior: Logs CGNAT são altamente repetitivos (mesmo formato, mesmos IPs se repetindo). A compressão ~10x reduz drasticamente o custo de armazenamento para retenção de 1+ ano

Graylog e ELK são ferramentas excelentes para uso geral — dashboards complexos, análise de logs de aplicação, SIEM. Mas para o caso de uso específico de compliance CGNAT em ISP, onde o padrão é ingestão massiva + consultas pontuais + retenção longa, o VictoriaLogs é a escolha mais eficiente.

Quando Usar Cada Um

Use VictoriaLogs (ou NATVault) quando:

• O foco é ingestão de alto volume + retenção longa
• Recursos de hardware são limitados
• Você quer simplicidade operacional (equipe técnica enxuta)
• O caso de uso é compliance CGNAT / resposta judicial
• Precisa de custo baixo de infraestrutura

Use Graylog quando:

• Precisa de uma interface web completa para análise de logs diversificados
• Quer pipelines de processamento visuais (extractors, streams)
• Tem equipe para administrar Elasticsearch + MongoDB
• Precisa de funcionalidades como alertas nativos com integração email/Slack
• O volume de logs é moderado (não centenas de milhões por dia)

Use ELK Stack quando:

• Precisa de dashboards avançados e visualizações (Kibana é imbatível nisso)
• Tem múltiplos casos de uso (logs de aplicação + infra + CGNAT + SIEM)
• Tem equipe com experiência em Elasticsearch
• Orçamento de infraestrutura não é limitante
• Precisa de ecossistema de integrações (Beats, Logstash plugins, Machine Learning)

Conclusão

As três soluções são capazes de armazenar logs CGNAT. A diferença está no custo, na complexidade e na eficiência.

Para a realidade da maioria dos ISPs brasileiros — equipe técnica enxuta, budget limitado, foco em compliance — o VictoriaLogs oferece o melhor custo-benefício como engine de logs. E o NATVault adiciona tudo que falta para transformar uma engine genérica em uma solução de compliance completa: parsers CGNAT, correlação RADIUS, relatórios judiciais e monitoramento de gaps.

Se você já tem um Graylog ou ELK rodando e está satisfeito, não precisa migrar. Mas se está começando do zero ou se o Graylog está consumindo 16GB de RAM para algo que poderia usar 2GB, vale avaliar.