Como Economizar em Logs sem Enlouquecer com as Contas do Splunk

Recentemente encontrei um projeto interessante chamado SigLens. A galera decidiu enfrentar algo sagrado — derrubar o Splunk e o ElasticSearch, prometendo economia de recursos dez vezes maior em troca. Parece hype de marketing típico, se não fosse por um "porém": o projeto foi recentemente arquivado, mudou para a licença Apache 2.0, e agora está disponível abertamente como uma base pronta para quem quiser construir seu próprio sistema de observabilidade sem ser roubado.

A propósito, os desenvolvedores do SigLens afirmam que sua solução é 100 vezes mais eficiente que o Splunk. Sempre sou cético com esses números, mas o histórico técnico da equipe (atendendo mais de 10.000 engenheiros) faz você querer dar uma olhada mais de perto nos detalhes.

Qual é o Principal Problema das Soluções Atuais

Se você já trabalhou com logs em projetos grandes, conhece esse cenário. Primeiro você configura o ElasticSearch, a vida é maravilhosa, e depois de seis meses percebe que o cluster cresceu até tamanhos obscenos, exige atenção constante do admin, e devora memória como se não houvesse amanhã. O Grafana Loki parece uma salvação até surgirem queries complexas — a performance às vezes lembra uma tartaruga.

O SigLens foi concebido como uma resposta a essas dificuldades. É um binário em Go que combina logs, métricas e traces em um único pacote. Sem dependências externas. Você pode rodar em um laptop comum e, segundo os autores, processar até 8 TB de dados por dia.

O Que Essa Ferramenta Pode Fazer

O projeto é interessante principalmente por sua arquitetura "all-in-one". Em vez de pular entre diferentes ferramentas, você tem um único ponto de entrada.

Suporte a Linguagens de Query Familiares

Esse provavelmente é seu ponto mais forte. Se sua equipe escreve em Splunk SPL há anos, não há necessidade de reciclar. O SigLens entende tanto SPL quanto SQL comum. Isso reduz significativamente a barreira de entrada para migração.

Flexibilidade na Ingestão de Dados

A ferramenta não exige que você reescreva seus pipelines de entrega de logs. Ela pode aceitar dados em formatos OpenTelemetry, Elastic, Splunk HEC e até Loki. Basicamente, você pode trocá-la pelo seu backend existente, e a maioria dos seus agentes (como Fluentbit ou Vector) nem perceberá a troca.

Performance em Números Reais

O blog dos autores tem um case onde processaram 1 PB de dados em um único dia. Para isso, precisaram de apenas 32 instâncias EC2. Para comparação: o Splunk ou Elastic precisaria de cerca de 3.000 máquinas para a mesma tarefa. A diferença nos custos de infraestrutura é colossal.

O Lado Técnico

O SigLens é escrito em Go, o que explica sua leveza. O destaque principal aqui é o motor de armazenamento, otimizado para as especificidades de séries temporais e logs não estruturados. Diferente do Elastic, que constrói índices invertidos pesados em cada campo, o SigLens usa abordagens mais eficientes de compressão e busca.

Curiosamente, o projeto oferece dashboards integrados e um sistema de alertas pronto para uso. Você não necessariamente precisa adicionar o Grafana, embora essa capacidade provavelmente exista via API.

Quem Pode se Beneficiar Agora

Como o projeto entrou em modo arquivo, é uma faca de dois gumes. Por um lado, você não deve esperar desenvolvimento ativo da equipe original. Por outro, a licença Apache 2.0 te dá liberdade completa.

Vejo vários cenários onde o SigLens pode "decolar":

1. Ferramentas de monitoramento interno em startups, onde o orçamento de infraestrutura é limitado mas já existe muito dado.
2. Debug local. Graças a ser um binário único, é fácil subir em um container Docker na máquina do desenvolvedor para analisar traces e logs em tempo real.
3. Uma base para criar sua própria solução proprietária de análise de dados.

Vale a Pena Experimentar

Se você está cansado de pagar milhares de dólares pelo Splunk ou lutando para manter clusters massivos de Elasticsearch, o SigLens é um ótimo candidato para explorar. Sim, o projeto está arquivado, mas o código Go lá é bem maduro e funcional.

Para começar rapidamente, eles têm Helm charts e imagens Docker prontas. Você pode fazer deploy do sistema em cinco minutos e ver como ele lida com seu fluxo de logs. Talvez seja exatamente o caso onde open source "abandonado" pode economizar um ano de orçamento de cloud para uma empresa.

Na minha prática, frequentemente acontece que esses motores especializados performam melhor que soluções universais all-in-one. O principal é entender que agora você terá que prover suporte por conta própria ou através da comunidade que decidir fazer um fork do projeto.