Hay un mensaje que se repite en muchos proyectos: “metamos más monitores, recojamos más métricas, instalemos la última IA del mercado y así tendremos todo bajo control”. Y luego llega el día malo: la plataforma de monitorización on-premise se degrada, tarda en arrancar, la base de datos va justa, y acabamos varias personas durante horas reiniciando nodos, pidiendo ayuda al fabricante y cruzando dedos. Mientras tanto, el negocio se queda sin visibilidad de lo importante.
No es una excepción. Pasa porque confundimos tener muchos datos con tener control. Y porque la promesa de la IA no sustituye dos cosas que siguen siendo humanas: decidir qué importa y organizar a los equipos para hacerlo realidad.
Quiero ordenar aquí algunas ideas que veo a menudo, con un objetivo simple: menos ruido y más propósito.
El problema de fondo: monitorizar casi todo “por si acaso”
En compañías grandes, la inercia empuja a monitorizar todo. Cualquier cosa que se pueda medir, se mide. Cada equipo añade sus alertas. Y, sin darnos cuenta, creamos una nube de notificaciones donde lo urgente y lo importante se diluyen.
El resultado:
- Alertas que suenan y nadie sabe qué hacer con ellas.
- Gente ocupada “apagando fuegos” que no llevan a decisiones.
- Cansancio y la sensación de que “esto no sirve”.
La salida es menos heroica y más aburrida: empezar por los objetivos. ¿Qué líneas de negocio no pueden caerse? ¿Qué experiencia mínima queremos proteger (tiempos de respuesta, tasa de errores, disponibilidad)? Si eso no está claro, da igual cuántos gráficos montemos. Lo demás—métricas, logs, trazas—son medios, no fines.
Para visualizarlo, me gusta este esquema:
Si una alerta no lleva a una acción clara, no es alerta: es ruido.
On-premise vs SaaS: cambias de dolor, no lo eliminas
He visto los dos mundos. En on-premise, además de configurar monitores, eres responsable de que la plataforma funcione: alta disponibilidad, parches, almacenamiento, bases de datos, reinicios ordenados, etc. Cuando algo se degrada, la mitad del esfuerzo se va a recuperar la propia plataforma, no a entender el problema de los sistemas que vigila. Ahí es cuando te preguntas: “¿por qué estoy peleando con mi herramienta en lugar de usarla para alertar de lo importante?”.
En SaaS, el proveedor se encarga de su infraestructura. Ganas tiempo y te centras en modelar bien el entorno: etiquetas que de verdad diferencien servicios y entornos, alertas con sentido, objetivos claros y menos ruido. Pero—importante—sigues necesitando criterio. Si etiquetas mal o configuras alertas al tuntún, tendrás el mismo ruido, solo que en la nube. Además, aceptas una dependencia tecnológica y hay casos (cumplimiento, datos sensibles, latencias internas) en los que on-premise sigue siendo razonable.
Resumiendo en corto:
Ni uno es la salvación ni el otro el demonio. Elige sabiendo dónde quieres gastar el tiempo y cuáles son tus riesgos.
La IA ayuda, pero no decide por ti
Las herramientas con “IA” (llámalo AIOps o como quieras) sí ayudan: agrupan eventos repetidos, detectan patrones raros, sugieren relaciones entre síntomas. Bien usadas, ahorran tiempo y evitan que nos perdamos en el detalle.
Lo que no hacen es decidir qué importa para tu negocio. La herramienta no sabe qué servicio paga nóminas o qué API da de comer a tu canal de ventas. Tampoco rediseña tu flujo de datos cuando se atasca ni arregla una base de datos que se ha quedado sin aire. Si la entrada es caótica, la salida será… mejor organizada, pero seguirá siendo caos.
Moraleja: pon la IA encima de una base sensata (objetivos, señales, alertas con dueño) y verás valor. Sin esa base, solo amplifica la confusión.
Open source tampoco es gratis (en esfuerzo)
Prometheus, OpenTelemetry, Elasticsearch, Kibana… herramientas fantásticas. Te dan flexibilidad y evitan ataduras. Pero hay una trampa: requieren disciplina. Si dejas que cualquiera envíe métricas “a saco” y no pones límites, reventarás por exceso de datos. Si cada cambio de la web rompe los monitores sintéticos porque los hiciste frágiles, volverás al punto de partida: tiempo perdido y frustración.
Reglas prácticas que funcionan sin tecnicismos:
- Menos variables exóticas: si cada métrica lleva etiquetas con valores infinitos (por ejemplo, un identificador único por petición), todo se hace enorme y lento.
- Frecuencias con cabeza: no midas cada segundo lo que vale con medir cada minuto.
- Monitores sintéticos robustos: en webs, pídeles a desarrollo “puntos de anclaje” estables (atributos visibles, rutas fijas), y valida estados, no detalles visuales que cambian cada semana.
- Comprobación antes de publicar: cuando se despliegue una versión, aseguraos de que los monitores que dependen de esa app siguen en pie. Es acordarlo y cumplirlo.
Herencias y migraciones: copiarlo todo no es migrar
Otra escena común: se decide “dar el salto a observabilidad”, pero se intenta copiar uno a uno todos los monitores heredados. Resultado: el mismo ruido, con una interfaz más moderna.
Una migración con sentido se hace por capas y prioridades:
- Empieza por lo crítico: el servicio que no puede fallar. Define ahí qué significa “salud” y qué señales lo demuestran.
- Tira monitores sin acción: si cuando suena no sabes qué hacer, fuera. O conviértelo en dato de consulta, pero quítalo del canal de alertas.
- Nombra responsables: cada alerta tiene un equipo o persona dueña, y un “qué hacer” escrito. Si no, no es alerta.
- Convive lo mínimo: sí, habrá un tiempo con dos sistemas a la vez. Pero con fecha de caducidad y con un plan claro de retirada.
¿Empezar de cero o evolucionar? Depende de cuánto lastre tengas. A veces es mejor cortar por lo sano por dominios, y rehacer con cabeza. Duele menos que arrastrar ruido años.
Organización: hace falta alguien que coordine de verdad
Cuando hay muchos equipos (desarrollo, base de datos, sistemas, monitorización, operaciones…), es fácil que cada uno haga lo suyo y nadie mire el conjunto. Propongo algo sencillo: un pequeño grupo (llámalo “torre de control”, “capítulo”, lo que quieras) que se ocupe de estas cuatro cosas:
- Lenguaje común: cómo nombramos servicios, entornos, criticidad. Si no nos entendemos, no hay forma de priorizar.
- Catálogo de alertas: lista corta de alertas que sí importan, con dueño y acción. Lo demás, a segundo plano.
- Objetivos claros: qué nivel de servicio queremos, y cuándo saltan las alarmas porque de verdad hay impacto en usuarios.
- Higiene periódica: cada cierto tiempo, eliminar lo que ya no aporta y ajustar lo que se queda corto.
No hace falta burocracia infinita. Hace falta responsabilidad compartida y un calendario.
Un apunte sobre “el día que todo se degrada”
Sin entrar en marcas, el patrón se repite: muchos agentes enviando datos, la plataforma on-premise se reinicia, y al volver intenta “ponerse al día” de golpe. Las colas de datos se acumulan, la base de datos sufre, y los servicios tardan en estar operativos. Todos al teléfono durante horas.
Lecciones que evitan drama:
- Reinicio por fases: no enciendas todo a la vez. Deja que el sistema respire.
- No todo a máxima velocidad: limita lo que envían los agentes hasta estabilizar.
- Mantenimiento de la base de datos: índices, limpieza, espacio. No es glamuroso, pero salva la noche.
- Plan escrito: qué pasos seguir y en qué orden. Cuando hay nervios, agradeces tenerlo delante.
Ventajas e inconvenientes (sin azúcar)
On-premise
- A favor: control total, ajuste fino, datos “en casa”.
- En contra: tiempo consumido en operar la herramienta, parches, hardware, bases de datos. Cuando falla, la responsabilidad es tuya.
SaaS
- A favor: te olvidas de la infraestructura del proveedor y te centras en lo que mides y alertas.
- En contra: dependencia, límites del servicio, y necesidad de confiar en un tercero. Si etiquetas mal y alertas peor, el ruido será el mismo.
Open source
- A favor: flexibilidad, comunidad, evitar ataduras.
- En contra: requiere mano firme. Sin normas de “qué enviamos, cuánto y para qué”, se descontrola.
Qué me gustaría que quedara
- No necesitamos más monitores, necesitamos mejores decisiones sobre qué vigilar y por qué.
- La IA es una ayuda, no un sustituto del criterio. Úsala para agrupar ruido y encontrar patrones, no para decidir prioridades de negocio.
- On-premise vs SaaS es una elección de dónde pones la energía: operar la herramienta o modelar bien tu entorno.
- Menos herencias a ciegas: migrar no es copiar, es repensar con foco.
- Coordinar no es burocracia: es acordar un lenguaje, limpiar alertas inútiles y revisar objetivos.
Si algo merece inversión no es otro panel de colorines, sino tiempo de conversación entre equipos para decidir qué es importante, normas simples para no ahogarnos en datos, y una lista corta de alertas que, cuando suenen, signifiquen algo y lleven a una acción. Con eso, cualquier plataforma—on-premise, SaaS u open source—empieza a jugar a tu favor. Sin eso, todo lo demás es humo.
Un último esquema para llevarse