Gjallar: monitor self-hosted en un binario Go de 36 MB

Gjallar, un monitor de 36 MB que cabe en un solo binario

Gjallar es un proyecto open source bajo licencia MIT que un desarrollador francés publicó en GitHub con una premisa singular: monitorear decenas de servicios heterogéneos con un único binario estático de Go, un archivo YAML de configuración y una base de datos SQLite. Nada más. El binario pesa aproximadamente 36 MB y se compila con CGO deshabilitado, lo que le permite correr en cualquier sistema sin instalar dependencias compartidas.

El autor —que mantiene el repositorio bajo el usuario brvier en GitHub— lo describe como una herramienta KISS («Keep It Simple, Stupid»): 3.400 líneas de Go diseñadas para vigilar endpoints HTTP, PostgreSQL, instancias de Oracle, Redis, índices de Elasticsearch, máquinas que respondan a ping y métricas de Prometheus, con alertas por Telegram, SMS y Signal.

¿Por qué construir un monitor desde cero en lugar de usar Prometheus o Datadog?

La motivación está en el arranque del post del autor: para unas pocas docenas de chequeos, no quería operar un segundo sistema distribuido solo para saber si el primero estaba arriba. El argumento toca una fibra sensible para los equipos de ingeniería de startups pequeñas y medianas: cada herramienta de monitoreo que adoptas termina pidiendo su propia infraestructura.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Según el análisis de XDA Developers sobre home labs auto-curativos, la pila clásica sigue siendo Prometheus + Grafana + Loki + Alloy + exporters, lo que implica múltiples instancias, configuración distribuida y una curva de aprendizaje considerable. Uptime Kuma aparece recurrentemente como alternativa más ligera, pero el autor señala que ninguna opción liviana podía consultar Oracle sin instalar el cliente de Oracle Instant Client, una pesadilla logística conocida por cualquier DevOps que haya desplegado en una caja minimalista.

¿Qué decisiones técnicas hacen a Gjallar diferente?

Varios elementos del diseño merecen atención porque revelan cómo piensa el autor sobre el problema:

Cero CGO intencional. Cada dependencia que tradicionalmente enlaza con una biblioteca C tiene reemplazo puro en Go: pgx para PostgreSQL, go-ora para Oracle, modernc.org/sqlite para SQLite, pro-bing para ICMP. El resultado es un binario que compila cruzado con GOOS/GOARCH y se despliega con scp.
Pipeline sin locks. Cada monitor corre en su propia goroutine y envía resultados a un canal compartido. Un único goroutine consumidor es dueño del estado y de la base de datos. SQLite, que no tolera bien escritores concurrentes, recibe exactamente uno.
El estado sobrevive a reinicios. Al arrancar, cada monitor se siembra desde cualquier incidente abierto en SQLite, así que un deploy durante una caída no re-dispara alertas ni pierde notificaciones de recuperación.
Notificaciones asíncronas. Un SMTP lento o un Telegram con rate-limit no pueden hacer back-pressure sobre el pipeline: cada envío corre en su propia goroutine con timeout de 15 segundos.
Hot reload con SIGHUP. Un YAML inválido no mata el proceso: se valida primero y, si falla, la configuración anterior sigue corriendo. «Tu monitor debería ser lo último que muera por un typo», resume el autor.
Expansión de variables ${VAR} para secretos en el YAML, con fallo claro de arranque si alguna variable no está definida.

¿Qué hace y qué NO hace a propósito?

Gjallar no tiene clustering, no tiene agentes, no tiene sistema de plugins, no tiene dashboards de series temporales, no tiene cuentas de usuario. La retención de historia se poda a 30 días por defecto para que el archivo SQLite no crezca indefinidamente.

Esta lista de «lo que no hace» es la parte que el autor defiende con más énfasis: cada herramienta de monitoreo que abandonó a lo largo de los años murió de la misma enfermedad —lentamente se convirtió en una plataforma, y un día el monitoreo necesitó monitoreo.

La página de estado es en blanco y rojo, refrescada con HTMX. Las alertas se disparan después de N fallos consecutivos, no en el primer parpadeo, y un realert opcional recuerda mientras el incidente sigue abierto.

¿Qué significa esto para tu startup?

El caso de Gjallar no es «adopta esta herramienta ya». Es un espejo de un problema de arquitectura que cualquier CTO pequeño enfrenta: cada pieza de observabilidad suma una pieza de complejidad operativa. Antes de sumar otra herramienta a tu stack, vale la pena hacerse tres preguntas:

¿Cuántos chequeos reales necesito? Si la respuesta es decenas, no cientos, una pila mínima como esta puede ahorrarte horas operativas semanales.
¿Quién opera el monitoreo cuando tú no estés? El principio del autor —entender la herramienta a las 3 AM dieciocho meses después— aplica incluso si usas SaaS comercial: lee la documentación de tu proveedor y entiende qué corre bajo el capó.
¿Cuánto cuesta tu monitoreo en dólares y en complejidad? Soluciones como Datadog o New Relic escalan bien, pero su pricing por host, métricas custom o logs puede superar al de un ingeniero junior para una startup en etapa temprana.

Acciones concretas que puedes tomar esta semana

Audita tu stack de observabilidad. Lista todas las herramientas que corren en producción para monitorear producción. Si tienes más de tres (APM, logs, uptime, sintéticos, dashboards), pregúntate si dos de ellas podrían consolidarse o si una de código abierto cubre el caso.
Evalúa Gjallar como prueba de concepto. Si tu pain point es monitorear bases heterogéneas (Oracle + Postgres + Redis) sin instalar clientes nativos, el repo de GitHub está bajo licencia MIT y el autor lo mantiene en github.com/brvier/Gjallar. Dedica una tarde a probarlo con 2-3 chequeos antes de comprometerte a una migración mayor.
Copia el patrón, no necesariamente la herramienta. El diseño de Gjallar —un único binario, configuración declarativa en YAML, estado persistente simple, hot reload validado— es replicable en otros problemas. Antes de adoptar el siguiente SaaS, considera si tu caso se resuelve con un script bien escrito y versionado en tu propio repositorio.