Logtide: 2 Meses Após o Lançamento (Os Números Reais)
Este artigo interessante é de @polliog no DEV.to
Aqui está o link do github dela:
há alguns bons conselhos aqui sobre como construir um produto
Dois meses atrás, lancei o Logtide (anteriormente chamado LogWard), uma alternativa de código aberto e focada em privacidade para Datadog e Splunk.
Aqui está o que realmente aconteceu. Sem enrolação, apenas números.
Os Números (Completamente Honestos)
GitHub:
- Estrelas: 0 → 223
- Issues: 27 recebidas, 6 abertas (todas melhorias, sem bugs críticos)
- Contribuidores: Desenvolvedor solo + 1 contribuidor de SDK (Kotlin)
Uso:
- Downloads no Docker Hub: 3.000+
- Implantações ativas: ~500 usuários (principalmente auto-hospedado)
- Maior implantação: 500.000 logs/dia
- Cloud vs Auto-hospedado: 90% auto-hospedado
O Que Realmente Funcionou
1. Os Canais de Marketing Certos
Vencedor: virtualizationhowto.com
Um blogueiro de tecnologia descobriu o Logtide e escreveu sobre ele.
Resultado:
- 120+ estrelas no GitHub a partir desse único post
- Pico de tráfego: 2.500 visitantes em 24 horas
- 80+ novas implantações auto-hospedadas
Lição: Um bom artigo de uma voz respeitada > 10 posts em redes sociais.
Segundo lugar: Reddit + Dev.to
Nossos posts em r/selfhosted e Dev.to trouxeram tráfego consistente.
Por que funcionou:
- Auto-hospedadores se importam com privacidade (ângulo GDPR)
- Implantação com Docker Compose (5 minutos do clone até rodar)
- Mensagem de sem bloqueio de fornecedor ressoou
2. Os Recursos Que as Pessoas Realmente Usam
Top 3 (por análise de uso):
- Logs (obviamente) - 100% dos usuários
- Dashboard SIEM - 60% dos usuários
- Rastreamentos OpenTelemetry - 40% dos usuários
Surpresa: O uso de SIEM é muito maior do que esperado.
Por quê? As pessoas não apenas querem VER logs, querem DETECTAR ameaças.
As regras Sigma mais populares nem são focadas em segurança:
- Alertas de “Pagamento falhou”
- Picos de “erro API 500”
- Padrões de “timeout de banco de dados”
Lição: Recursos de segurança vendem, mas monitoramento de negócios é o que as pessoas realmente usam.
3. Decisões Técnicas Que Compensaram
TimescaleDB foi a escolha certa.
A aposta:
- Usar TimescaleDB para compressão de séries temporais
- vs ClickHouse (mais rápido mas mais complexo)
Resultado após 2 meses:
- Compressão: redução de 90% de armazenamento (100GB → 10GB típico)
- Velocidade de consulta: 50-150ms para 10M+ logs
- Simplicidade operacional: Apenas Postgres (familiar)
Estatísticas da maior implantação:
- 500k logs/dia
- Retenção de 30 dias
- Tamanho do banco de dados: 15GB (comprimido)
- Desempenho de consulta: Ainda sub-100ms
Ninguém reclamou sobre desempenho ainda.
Lição: Desempenho “bom o suficiente” + simplicidade operacional > velocidade máxima.
4. Solicitações da Comunidade Que Fizeram Sentido
Issue #68: Busca de Substring
Solicitação: “Não consigo encontrar ‘bluez’ em ‘spa.bluez5.native’ usando busca de texto completo”
Meu pensamento inicial: “Busca de texto completo é boa, use wildcards”
Realidade: 40% das buscas agora usam modo substring.
Por quê?
- UUIDs em logs (busca parcial)
- Caminhos de arquivo (ex:
/app/services/auth) - Nomes de serviço com pontos
Lição: Usuários conhecem seus fluxos de trabalho melhor do que você. Ouça as issues do GitHub.
O Que Não Funcionou
1. A Mudança de Marca (Forçada, Não Escolhida)
Cronograma:
- 7 de janeiro: Conflito de marca descoberto
- 7-12 de janeiro: Resolução negociada
- 12 de janeiro: LogWard → Logtide completo
Impacto:
- Perdi todo o momentum de SEO (Google indexou “LogWard”)
- Quebrei todos os links antigos/favoritos
- Confundi usuários iniciais (“espera, o que é Logtide?”)
Maior dor: Perder visibilidade de artigos anteriores do Dev.to, posts do Reddit, menções.
Tempo desperdiçado: ~40 horas (renomear tudo, atualizar docs, SDKs, imagens Docker)
Lição aprendida: Verifique marcas registradas ANTES de nomear qualquer coisa. Ponto final.
Lado positivo: Novo nome é melhor (Logtide soa mais legal que LogWard).
2. Recursos Que Ninguém Pediu
Métricas OpenTelemetry (ainda não implementadas)
Plano: Suportar métricas OTLP (CPU, memória, etc.)
Realidade: Apenas 2 usuários pediram.
Por quê? A maioria das pessoas já usa Prometheus para métricas.
Decisão: Adiado indefinidamente. Focar em logs + rastreamentos.
Lição: Construa o que os usuários PEDEM, não o que você acha que eles precisam.
3. Arrependimentos Arquiteturais
Redis pode ser desnecessário.
Stack atual:
- PostgreSQL + TimescaleDB (armazenamento de logs)
- Redis (fila de trabalhos em background com BullMQ)
Problema: Redis adiciona complexidade operacional para auto-hospedadores.
Alternativa sendo explorada:
- PostgreSQL
SKIP LOCKEDpara fila de trabalhos - Já provei que isso funciona no meu artigo “I Replaced Redis with PostgreSQL”
Próxima versão (0.5.0): Pode remover Redis completamente.
Lição: Toda dependência é uma responsabilidade. Questione tudo.
Aprendizados Inesperados
1. Auto-Hospedado Domina
Esperado: 50/50 cloud vs auto-hospedado
Realidade: 90% auto-hospedado
Por quê?
- Preocupações com privacidade (GDPR)
- Requisitos de residência de dados
- Controle sobre infraestrutura
- Desconfiança de plataformas SaaS de logging
Impacto no roadmap:
- Priorizar melhorias do Docker Compose sobre recursos de cloud
- Melhor documentação para auto-hospedagem
- Gráfico Helm do Kubernetes
Lição: Conheça seus usuários reais, não seus usuários imaginados.
2. Regras Sigma São um Diferencial
Expectativa: “Recurso de segurança legal”
Realidade: “Razão principal para escolher Logtide”
Feedback dos usuários:
- “Finalmente, detecção de segurança sem custos do Splunk”
- “Regras Sigma funcionam fora da caixa”
- “Mapeamento MITRE ATT&CK é incrível”
Mais solicitado:
- Mais regras Sigma pré-construídas
- Integração SigmaHQ (importar regras automaticamente)
- UI do editor de regras customizadas
Lição: Encontre seu ângulo único. Para Logtide, é “logs + segurança” em um só lugar.
3. Experiência do Desenvolvedor Importa Mais Que Recursos
O que recebe estrelas:
- Docker Compose funciona em 5 minutos
- Documentação é clara
- Exemplos estão prontos para copiar e colar
O que não importa (ainda):
- Recursos avançados
- Capacidades empresariais
- Integrações complexas
Lição: Torne FÁCIL tentar antes de tornar PODEROSO.
Reflexões Pessoais
O Que Me Motiva a Continuar
Ver sendo usado.
Toda vez que vejo:
- Uma nova estrela no GitHub
- Uma implantação em 500k logs/dia
- Alguém resolvendo um problema com Logtide
…vale a pena as semanas de 60 horas.
A visão é real: Observabilidade focada em privacidade não deveria custar $500/mês.
O Momento Mais Difícil
A mudança de marca.
Perder 2 semanas de momentum para um problema de marca registrada foi um golpe no peito.
Ver links antigos quebrados, SEO desaparecer, usuários confusos, doloroso.
Mas: Eu lidei com isso, me movi rápido e me recuperei.
Resiliência importa mais que evitar problemas.
O Melhor Momento
Atingir 200 estrelas.
Número arbitrário? Sim.
Validação de que as pessoas se importam com isso? Também sim.
Segundo melhor: Ver a contribuição do SDK Kotlin.
Alguém se importou o suficiente para construir um SDK sem eu pedir. Isso é comunidade.
Com O Que Preciso de Ajuda
Feedback sobre o Roadmap
Pergunta: O que devo construir a seguir?
Debates atuais:
- Remover dependência de Redis?
- Adicionar suporte a métricas?
- Focar em otimização de desempenho?
Vote: GitHub Discussions
Lições para Outros Construtores
1. Lance em 50%, Não em 90%
Esperei muito tempo para lançar inicialmente.
Resultado: Perdi feedback inicial, construí recursos errados.
Melhor: Lance com recursos principais, itere com base no uso real.
2. Marketing > Produto (Inicialmente)
Verificação de realidade:
- Melhor recurso que construí: detecção de regras Sigma
- Recurso que recebeu mais estrelas: simplicidade do Docker Compose
Por quê? Fazer alguém TENTAR seu produto > ter o melhor produto.
3. Comunidade > Tudo
Um contribuidor de SDK Kotlin me economizou 20+ horas de trabalho.
Um post de blog trouxe 120 estrelas.
Um usuário implantando 500k logs/dia validou a arquitetura.
Construa em público. Engaje autenticamente. As pessoas ajudam.
4. Abrace Tecnologia Chata
Escolhas que funcionaram:
- PostgreSQL (todos conhecem)
- Docker Compose (implantação simples)
- SvelteKit (rápido, mas não exótico)
Escolhas que eu reconsideraria:
- Redis (pode ser excessivo)Lição: Tecnologia chata escala melhor que tecnologia brilhante.
Experimente Logtide
Cloud (Gratuito):
Auto-hospedado:
mkdir logtide && cd logtide
curl -O https://raw.githubusercontent.com/logtide-dev/logtide/main/docker/docker-compose.yml
curl -O https://raw.githubusercontent.com/logtide-dev/logtide/main/docker/.env.example
mv .env.example .env
Visite http://localhost:3000
Documentação: logtide.dev/docs
Vamos Conversar
Se você está usando Logtide:
O que está funcionando? O que está quebrado? Comente abaixo!
Se você está construindo código aberto:
Quais são SUAS métricas de 2 meses? Vamos comparar notas.
Se você está considerando Logtide:
Dúvidas? Pergunte abaixo ou em GitHub Discussions
Acompanhe a jornada:
Construir em público é assustador, mas gratificante. Aqui está para os próximos 2 meses. 