Migración
Desde un stack de observabilidad autoalojado
Equipos que operan su propia combinación de TSDB + almacén de logs + backend de tracing + visualizador + capa de alertas.
Tiempo estimado: ~1–2 semanas para un equipo mediano; un fin de semana para uno pequeño
Por qué los equipos migran
- →Cinco servicios que actualizar de forma independiente — un solo binario en su lugar
- →A la guardia la despiertan por el propio stack de monitoreo, no por el producto
- →El rebalanceo de almacenamiento y el cálculo de retención son trabajo de alguien
- →Auth, SSO, multi-tenancy añadidos a mano
Qué se transfiere tal cual
- ✓Expresiones PromQL — pégalas tal cual
- ✓Configs de scrape existentes mediante un agente shim ligero
- ✓Paneles mediante import JSON (los panels mapean 1:1 en los casos comunes)
- ✓Reglas de alerta — el formato YAML es compatible
Qué adaptar
- •Recording rules — Unimoni las guarda en la misma DB, misma sintaxis
- •Los plugins de panel de cola larga pueden no tener un widget 1:1 — abre un issue y lo añadimos
Pasos de migración
- 1.Levanta Unimoni junto al stack existente (un binario, docker-compose)
- 2.Apunta un agente hacia él; verifica que aparecen las mismas series
- 3.Importa los paneles mediante /api/v1/dashboards/import
- 4.Migra a un equipo no crítico durante una semana — mantén el stack antiguo en vivo
- 5.Cuando haya confianza, apunta todos los agentes y desmantela