Logtide: 2 Meses Después del Lanzamiento (Los Números Reales)
Este artículo interesante es de @polliog en DEV.to
Aquí está su enlace de github:
hay algunos buenos consejos aquí sobre cómo construir un producto
Hace dos meses, lancé Logtide (antes llamado LogWard), una alternativa de código abierto y privacidad primero a Datadog y Splunk.
Aquí está lo que realmente pasó. Sin tonterías, solo números.
Los Números (Completamente Honestos)
GitHub:
- Estrellas: 0 → 223
- Problemas: 27 recibidos, 6 abiertos (todos mejoras, sin errores críticos)
- Colaboradores: Desarrollador en solitario + 1 colaborador de SDK (Kotlin)
Uso:
- Descargas de Docker Hub: 3,000+
- Implementaciones activas: ~500 usuarios (principalmente autohospedados)
- Implementación más grande: 500,000 registros/día
- Nube vs Autohospedado: 90% autohospedado
Lo Que Realmente Funcionó
1. Los Canales de Marketing Correctos
Ganador: virtualizationhowto.com
Un blogger de tecnología descubrió Logtide y escribió sobre él.
Resultado:
- 120+ estrellas de GitHub de ese único artículo
- Pico de tráfico: 2,500 visitantes en 24 horas
- 80+ nuevas implementaciones autohospedadas
Lección: Un buen artículo de una voz respetada > 10 publicaciones en redes sociales.
Subcampeón: Reddit + Dev.to
Nuestras publicaciones en r/selfhosted y Dev.to trajeron tráfico consistente.
Por qué funcionó:
- Los autohospedadores se preocupan por la privacidad (ángulo GDPR)
- Implementación de Docker Compose (5 minutos desde clonar hasta ejecutar)
- El mensaje de sin bloqueo de proveedor resonó
2. Las Características Que La Gente Realmente Usa
Top 3 (por análisis de uso):
- Registros (obviamente) - 100% de usuarios
- Panel SIEM - 60% de usuarios
- Trazas OpenTelemetry - 40% de usuarios
Sorpresa: El uso de SIEM es mucho más alto de lo esperado.
¿Por qué? La gente no solo quiere VER registros, quiere DETECTAR amenazas.
Las reglas Sigma más populares ni siquiera están enfocadas en seguridad:
- Alertas de “Pago fallido”
- Picos de “Error API 500”
- Patrones de “Tiempo de espera de base de datos”
Lección: Las características de seguridad venden, pero la monitorización empresarial es lo que la gente realmente usa.
3. Decisiones Técnicas Que Dieron Resultado
TimescaleDB fue la opción correcta.
La apuesta:
- Usar TimescaleDB para compresión de series de tiempo
- vs ClickHouse (más rápido pero más complejo)
Resultado después de 2 meses:
- Compresión: 90% de reducción de almacenamiento (100GB → 10GB típico)
- Velocidad de consulta: 50-150ms para 10M+ registros
- Simplicidad operativa: Solo Postgres (familiar)
Estadísticas de implementación más grande:
- 500k registros/día
- Retención de 30 días
- Tamaño de base de datos: 15GB (comprimido)
- Rendimiento de consulta: Aún por debajo de 100ms
Nadie se ha quejado del rendimiento aún.
Lección: Rendimiento “suficientemente bueno” + simplicidad operativa > velocidad máxima.
4. Solicitudes de la Comunidad Que Tuvieron Sentido
Problema #68: Búsqueda de Subcadena
Solicitud: “No puedo encontrar ‘bluez’ en ‘spa.bluez5.native’ usando búsqueda de texto completo”
Mi pensamiento inicial: “La búsqueda de texto completo está bien, usa comodines”
Realidad: 40% de las búsquedas ahora usan modo de subcadena.
¿Por qué?
- UUIDs en registros (búsqueda parcial)
- Rutas de archivo (p. ej.,
/app/services/auth) - Nombres de servicio con puntos
Lección: Los usuarios conocen sus flujos de trabajo mejor que tú. Escucha los problemas de GitHub.
Lo Que No Funcionó
1. El Cambio de Marca (Forzado, No Elegido)
Cronología:
- 7 de enero: Se descubrió conflicto de marca registrada
- 7-12 de enero: Se negoció la resolución
- 12 de enero: LogWard → Logtide completado
Impacto:
- Perdí todo el impulso de SEO (Google indexó “LogWard”)
- Rompí todos los enlaces antiguos/marcadores
- Confundí a los primeros usuarios (“espera, ¿qué es Logtide?”)
Mayor dolor: Perder visibilidad de artículos anteriores de Dev.to, publicaciones de Reddit, menciones.
Tiempo desperdiciado: ~40 horas (renombrar todo, actualizar documentos, SDKs, imágenes de Docker)
Lección aprendida: Verifica las marcas registradas ANTES de nombrar cualquier cosa. Punto.
Lado positivo: El nuevo nombre es mejor (Logtide suena más genial que LogWard).
2. Características Que Nadie Pidió
Métricas de OpenTelemetry (aún no implementadas)
Plan: Soportar métricas OTLP (CPU, memoria, etc.)
Realidad: Solo 2 usuarios lo pidieron.
¿Por qué? La mayoría de la gente ya usa Prometheus para métricas.
Decisión: Pospuesto indefinidamente. Enfocarse en registros + trazas.
Lección: Construye lo que los usuarios SOLICITAN, no lo que crees que necesitan.
3. Arrepentimientos Arquitectónicos
Redis podría ser innecesario.
Stack actual:
- PostgreSQL + TimescaleDB (almacenamiento de registros)
- Redis (cola de trabajos en segundo plano con BullMQ)
Problema: Redis añade complejidad operativa para autohospedadores.
Alternativa siendo explorada:
- PostgreSQL
SKIP LOCKEDpara cola de trabajos - Ya probé que esto funciona en mi artículo “Reemplacé Redis con PostgreSQL”
Próxima versión (0.5.0): Podría eliminar Redis completamente.
Lección: Cada dependencia es un pasivo. Cuestiona todo.
Aprendizajes Inesperados
1. Lo Autohospedado Domina
Esperado: 50/50 nube vs autohospedado
Realidad: 90% autohospedado
¿Por qué?
- Preocupaciones de privacidad (GDPR)
- Requisitos de residencia de datos
- Control sobre la infraestructura
- Desconfianza en plataformas de logging SaaS
Impacto en la hoja de ruta:
- Priorizar mejoras de Docker Compose sobre características de nube
- Mejor documentación para autohospedaje
- Gráfico Helm de Kubernetes
Lección: Conoce a tus usuarios reales, no a tus usuarios imaginados.
2. Las Reglas Sigma Son un Diferenciador
Expectativa: “Característica de seguridad agradable”
Realidad: “Razón principal para elegir Logtide”
Retroalimentación de usuarios:
- “Finalmente, detección de seguridad sin costos de Splunk”
- “Las reglas Sigma funcionan de inmediato”
- “El mapeo de MITRE ATT&CK es increíble”
Más solicitado:
- Más reglas Sigma precompiladas
- Integración de SigmaHQ (importar reglas automáticamente)
- UI de editor de reglas personalizadas
Lección: Encuentra tu ángulo único. Para Logtide, es “registros + seguridad” en un solo lugar.
3. La Experiencia del Desarrollador Importa Más Que Las Características
Lo que obtiene estrellas:
- Docker Compose funciona en 5 minutos
- La documentación es clara
- Los ejemplos están listos para copiar y pegar
Lo que no importa (aún):
- Características avanzadas
- Capacidades empresariales
- Integraciones complejas
Lección: Hazlo FÁCIL de probar antes de hacerlo PODEROSO.
Reflexiones Personales
Qué Me Motiva a Continuar
Verlo ser utilizado.
Cada vez que veo:
- Una nueva estrella de GitHub
- Una implementación en 500k registros/día
- Alguien resolviendo un problema con Logtide
…vale la pena las semanas de 60 horas.
La visión es real: La observabilidad de privacidad primero no debería costar $500/mes.
El Momento Más Difícil
El cambio de marca.
Perder 2 semanas de impulso por un problema de marca registrada se sintió como un golpe en el estómago.
Ver enlaces antiguos romperse, SEO desaparecer, usuarios confundidos, doloroso.
Pero: Lo manejé, me moví rápido y me recuperé.
La resiliencia importa más que evitar problemas.
El Mejor Momento
Alcanzar 200 estrellas.
¿Número arbitrario? Sí.
¿Validación de que a la gente le importa esto? También sí.
Segundo mejor: Ver la contribución del SDK de Kotlin.
Alguien se preocupó lo suficiente como para construir un SDK sin que yo lo pidiera. Eso es comunidad.
Con Qué Necesito Ayuda
Retroalimentación sobre la Hoja de Ruta
Pregunta: ¿Qué debería construir a continuación?
Debates actuales:
- ¿Eliminar la dependencia de Redis?
- ¿Añadir soporte de métricas?
- ¿Enfocarse en optimización de rendimiento?
Vota: GitHub Discussions
Lecciones para Otros Constructores
1. Lanza al 50%, No al 90%
Esperé demasiado para lanzar inicialmente.
Resultado: Perdí retroalimentación temprana, construí características equivocadas.
Mejor: Lanza con características principales, itera basándote en uso real.
2. Marketing > Producto (Inicialmente)
Verificación de realidad:
- Mejor característica que construí: Detección de reglas Sigma
- Característica que obtuvo más estrellas: Simplicidad de Docker Compose
¿Por qué? Lograr que alguien PRUEBE tu producto > tener el mejor producto.
3. Comunidad > Todo
Un colaborador de SDK de Kotlin me ahorró 20+ horas de trabajo.
Un artículo de blog trajo 120 estrellas.
Un usuario implementando 500k registros/día validó la arquitectura.
Construye en público. Participa auténticamente. La gente ayuda.
4. Abraza la Tecnología Aburrida
Opciones que funcionaron:
- PostgreSQL (todos la conocen)
- Docker Compose (implementación simple)
- SvelteKit (rápido, pero no exótico)
Opciones que reconsideraría:
- Redis (podría ser excesivo)Lección: La tecnología aburrida escala mejor que la tecnología brillante.
Prueba Logtide
Cloud (Gratis):
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
Visita http://localhost:3000
Documentación: logtide.dev/docs
Hablemos
Si estás usando Logtide:
¿Qué funciona? ¿Qué está roto? ¡Comenta abajo!
Si estás construyendo código abierto:
¿Cuáles son TUS métricas de 2 meses? Comparemos notas.
Si estás considerando Logtide:
¿Preguntas? Pregunta abajo o en GitHub Discussions
Sigue el viaje:
Construir en público es aterrador pero gratificante. Aquí va por los próximos 2 meses. 