Alternativa ao Graylog para Provedores: Mais Leve e Mais Barato

Graylog: Bom Software, Caso de Uso Errado

Vamos deixar claro desde o início: Graylog é uma excelente ferramenta de gerenciamento de logs. É open source, tem uma comunidade ativa, interface web decente e capacidade de processar grandes volumes de dados. Muitos provedores brasileiros adotaram o Graylog nos últimos anos como solução para guardar logs de CGNAT.

O problema não é o Graylog em si. O problema é que o Graylog foi projetado para DevOps e SRE, não para provedores de internet. E essa diferença de propósito cobra seu preço diariamente na operação de um ISP.

Os Problemas Reais do Graylog em ISPs

1. Consumo de Recursos: A Conta Chega Todo Mês

O Graylog roda sobre Elasticsearch (ou OpenSearch), que é famosamente voraz em recursos:

• RAM mínima recomendada: 8 GB só para o Elasticsearch + 4 GB para o Graylog + 2 GB para o MongoDB = 14 GB mínimos
• RAM realista para ISP médio: 32 a 64 GB para lidar com o volume de logs de CGNAT
• CPU: Elasticsearch adora CPU para indexação e buscas
• Disco: índices Elasticsearch ocupam 2 a 5x mais espaço que os dados brutos

Para um provedor de 5.000 assinantes, manter 1 ano de logs de CGNAT no Graylog pode exigir um servidor dedicado com 64 GB de RAM e 10+ TB de disco SSD. Isso é um custo significativo — especialmente para quem opera com margens apertadas.

2. Complexidade Operacional

O stack Graylog envolve três componentes distintos:

1. Graylog Server (Java) — a aplicação principal
2. Elasticsearch/OpenSearch (Java) — indexação e busca
3. MongoDB — configurações e metadados

Cada um tem suas peculiaridades, configurações, atualizações e potenciais pontos de falha. Quando algo quebra — e com Elasticsearch, quebra — o troubleshooting exige conhecimento especializado que muitos NOCs de ISP não possuem.

Problemas comuns que todo admin Graylog de ISP conhece:

• Elasticsearch ficou sem disco e parou de indexar (logs perdidos silenciosamente)
• Shards ficaram em estado RED e a busca parou de funcionar
• Índice corrompeu após queda de energia
• Heap do Java estourou e o Graylog travou
• Upgrade de versão quebrou pipelines e extractors

3. Sem Funcionalidades Específicas para ISP

O Graylog é genérico. Ele sabe receber logs, indexar e buscar. Mas ele não sabe:

• Correlacionar RADIUS com CGNAT: você precisa construir isso manualmente com pipelines e extractors
• Gerar relatórios judiciais: não existe um "responder ofício" no Graylog
• Entender a lógica de NAT determinístico: você precisa fazer toda a lógica por fora
• Gerenciar retenção por tipo de log: RADIUS 2 anos, CGNAT 1 ano? Configure índices separados manualmente
• Alertar sobre falha de coleta: se o syslog do BRAS parou de chegar, o Graylog não avisa (sem configuração custom)

As Alternativas no Mercado

ELK Stack (Elasticsearch + Logstash + Kibana)

Essencialmente o mesmo stack do Graylog, mas sem o Graylog Server no meio. Mesmos problemas de consumo de recursos (Elasticsearch é o vilão), maior complexidade de configuração, e igualmente genérico para ISPs.

• Prós: extremamente flexível, ecossistema enorme, Kibana tem visualizações poderosas
• Contras: mais pesado que o Graylog, curva de aprendizado íngreme, licenciamento confuso (Elastic vs OpenSearch), sem nada específico para ISP

LogFull

Solução brasileira focada em provedores, conhecida no mercado ISP.

• Prós: feito para provedores, suporte em português, entende o contexto ISP
• Contras: custo mensal significativo por assinante, modelo SaaS que pode ficar caro em escala, dependência de fornecedor

Syslog em Arquivos (a solução "gambiarra")

Muitos provedores pequenos simplesmente recebem syslog em arquivos texto no servidor e fazem grep quando precisam.

• Prós: custo zero, simples de implementar
• Contras: busca lenta (grep em 50 GB de texto), sem indexação, sem correlação, sem interface, sem alertas, difícil de manter organizado, não atende os requisitos de segurança do Decreto 8.771/2016

VictoriaLogs

Projeto open source da equipe da VictoriaMetrics, otimizado para armazenamento e busca de logs com consumo mínimo de recursos.

• Prós: até 90% menos RAM que Elasticsearch, compressão agressiva (até 30x), busca rápida, single binary (sem dependências), open source
• Contras: ecossistema menor, menos integrações prontas, não é específico para ISP (precisa de camada de aplicação por cima)

O Que um ISP Realmente Precisa

Vamos ser práticos. Para cumprir o Marco Civil e operar com eficiência, um provedor precisa de:

1. Coleta confiável de logs: syslog do BRAS/CGNAT + RADIUS accounting, com alertas se a coleta falhar
2. Armazenamento eficiente: compressão agressiva para caber 1+ ano de dados sem gastar uma fortuna em disco
3. Busca rápida: consultar por IP + porta + data/hora em segundos, não minutos
4. Correlação automática: RADIUS + CGNAT = identificação do assinante com um clique
5. Relatório judicial: gerar a resposta ao ofício em formato adequado, pronta para assinar e enviar
6. Retenção automatizada: expirar dados antigos automaticamente conforme a política definida
7. Controle de acesso e auditoria: quem consultou, quando, log de acesso (exigência do Decreto 8.771/2016)
8. Consumo aceitável de recursos: não precisar de um servidor de R$ 15.000 só para logs

Comparativo: Graylog vs Alternativas para ISP

Caso Real: A Dor do Graylog no ISP

Cenário comum que vemos em provedores:

1. Provedor instala Graylog em VM com 16 GB de RAM
2. Funciona bem por 2-3 meses com poucos logs
3. Configura syslog do CGNAT — volume dispara
4. Elasticsearch começa a ficar lento, shards ficam grandes
5. Admin aumenta a RAM para 32 GB — melhora temporariamente
6. Com 6 meses de dados, busca por IP leva 30+ segundos
7. Chega um ofício judicial — técnico leva 2 horas para achar os dados
8. Disco enche — Elasticsearch entra em modo read-only
9. Admin precisa deletar índices antigos ANTES de completar 1 ano
10. Resultado: não conformidade com o Marco Civil

Essa história se repete em centenas de provedores pelo Brasil. Não é culpa do Graylog — é que a ferramenta não foi pensada para esse caso de uso.

Por Que VictoriaLogs é a Base Certa

O NATVault é construído sobre o VictoriaLogs, e isso não é acidental. Veja os números:

• RAM: VictoriaLogs usa até 90% menos RAM que Elasticsearch para o mesmo volume de dados
• Disco: compressão nativa reduz o armazenamento em 10 a 30x comparado com texto bruto
• Single binary: um único executável, sem Java, sem MongoDB, sem dependências pesadas
• Performance: busca otimizada para logs, não para full-text search genérico

Na prática, o mesmo provedor que precisaria de 64 GB de RAM e 10 TB de disco SSD com Graylog pode rodar com 4 GB de RAM e 2 TB de disco usando VictoriaLogs como backend. A economia é brutal.

A Camada ISP Que Faz a Diferença

VictoriaLogs é o motor de armazenamento. O NATVault adiciona tudo que um ISP precisa por cima:

• Parser de syslog CGNAT: entende os formatos dos principais equipamentos (Huawei NE, Cisco ASR, MikroTik, Juniper MX)
• Integração RADIUS: recebe accounting e correlaciona automaticamente com logs de NAT
• Interface de busca judicial: campo para IP, porta, data/hora → resultado com dados do assinante
• Gerador de relatório: PDF pronto para protocolar como resposta ao ofício
• Dashboard operacional: volume de logs por hora, status da coleta, alertas
• Retenção automática: configura uma vez, os dados expiram sozinhos

Migrando do Graylog

Se você já usa Graylog, a migração não precisa ser traumática:

1. Instale o NATVault em paralelo — aponte o syslog para os dois destinos
2. Valide por 30 dias: compare resultados de busca entre os dois sistemas
3. Desligue o Graylog: quando estiver confiante, redirecione todo o syslog para o NATVault
4. Mantenha o Graylog read-only: até que os dados antigos completem o prazo de retenção

Você não precisa importar os dados do Graylog — basta manter os dois rodando até que os dados antigos expirem naturalmente.