Monitoreo sintético: cuando los servidores dicen que está todo bien, pero está todo mal
Existe una frase peligrosa en infraestructura:
“El servidor está arriba, no hay problemas”.
Esa frase ha causado más incendios que un commit a la DB sin un WHERE.
Porque claro:
- El ping responde.
- El puerto está abierto.
- La CPU está tranquila.
- La memoria está disponible.
- El servicio aparece como “running”.
Entonces todos felices.
Hasta que llega un usuario y dice:
“La página no funciona”.
Y ahí empezamos a correr en circulos con las manos en alto, a buscar donde está el error, a hacer arqueolgía de logs, procesos, conexiones y buscar más café.
El problema muy es simple:
Estamos monitoreando componentes de un servicio.
Pero no estamos monitoreando la experiencia real.
###Ahí aparece el monitoreo sintético al rescate!.
¿Qué es el monitoreo sintético?
Super simploe, el monitoreo sintético consiste en ejecutar pruebas automáticas que simulan acciones reales de un usuario o sistema.
En lugar de preguntar solamente:
“¿El servicio está encendido?”
preguntamos:
“¿El servicio realmente funciona?”
La diferencia parece pequeña, pero en ambientes productivos es enorme.
Un componente puede estar corriendo, pero el servicio que consume un usuario puede emuerto. Por ejemplo, el servicio apache está arriba, pero al usuario no le funciona la pagina web.
El problema del monitoreo tradicional
Un monitoreo tradicional normalmente revisa métricas como:
CPU: 20%
RAM: 45%
Disco: OK
Servicio: activo
Puerto: abierto
Y todo parece perfecto.
Pero eso no responde preguntas importantes:
- ¿La página carga correctamente?
- ¿El usuario puede iniciar sesión?
- ¿La API responde con datos válidos?
- ¿La base de datos acepta consultas?
- ¿El DNS entrega respuestas correctas?
- ¿El sistema externo está funcionando?
Porque una cosa es que un componente exista.
Otra muy diferente es que entregue un servicio útil.
Ejemplos de monitoreo sintético
El monitoreo sintético puede aplicarse prácticamente a cualquier servicio.
Aplicaciones web
Un robot puede:
- Abrir una página.
- Revisar que entregue código HTTP correcto.
- Buscar un texto esperado.
- Medir tiempo de respuesta.
- Validar un flujo de login.
Porque muchas aplicaciones tienen la maravillosa capacidad de responder:
HTTP 200 OK
mientras muestran:
Error interno de aplicación
Para un monitor básico:
“Todo funciona”.
Para un usuario:
“La aplicación está caída”.
DNS
Un servidor DNS puede estar respondiendo consultas, pero entregar información incorrecta.
Una prueba sintética puede validar:
- Resolución de dominios.
- Tiempo de respuesta.
- Servidores DNS disponibles.
- Registros esperados.
Porque un DNS roto puede dejar una infraestructura completa en el suelo.
Bases de datos
Una base de datos puede aceptar conexiones y tener todos sus procesos activos.
Pero:
- Las consultas pueden estar lentas.
- Las tablas pueden estar bloqueadas.
- La aplicación puede no obtener respuestas.
Una prueba sintética puede ejecutar consultas reales y validar que el servicio funciona como corresponde.
APIs y servicios externos
Muchas plataformas dependen de APIs.
No basta con saber que el endpoint responde.
Hay que validar:
- Código HTTP correcto.
- Tiempo de respuesta.
- Formato esperado.
- Datos necesarios.
Un endpoint que responde rápido pero entrega errores también es un problema.
Zabbix y el monitoreo sintético
Una de las herramientas más conocidas para implementar este tipo de pruebas es Zabbix.
Con los Web Scenarios, Zabbix puede simular navegación contra aplicaciones web y validar diferentes condiciones.
Por ejemplo:
Paso 1:
Abrir https://portal.empresa.cl
Paso 2:
Validar código HTTP 200
Paso 3:
Buscar texto:
"Bienvenido al portal"
Paso 4:
Alertar si demora más de 5 segundos
Esto convierte a Zabbix en un usuario automático que revisa el servicio constantemente.
Un usuario que no duerme, no reclama y trabaja 24/7. (bueno, eso de que no reclama… esperen a que comiencen a llegar las alertas cuando está recién instalado en una maquina que nunca se le ha hecho un ajuste para performance!)
Es el empleado perfecto, bueno casi, manda más mensajes que ex tóxica.
¿Por qué usar monitoreo sintético?
Porque con esto comprobamos que todas las capas involucradas en un servicio estén funcionando correctamente. por ejemplo en un servidor web, al ejecutar un monitoreo sintético pasamos por:
- DNS
- Firewall
- WAF
- Blanceador de carga
- Proxy reverso
- Servidor Web / Aplicaciones
- Base de datos
Pasando por dependencias y conectores entre todas las etapas de la conexión, y no solo un “Apache is running”
El monitoreo sintético permite detectar problemas desde la perspectiva del servicio:
- Antes que los usuarios.
- Antes que los clientes.
- Antes que alguien abra un ticket.
Monitorear infraestructura no es suficiente
Un servidor saludable no garantiza un servicio saludable.
Puedes tener:
Linux funcionando
Nginx funcionando
MySQL funcionando
Red funcionando
Y aun así tener una aplicación caída.
La pregunta correcta no es:
“¿Está vivo el servidor?”
La pregunta correcta es:
“¿El servicio funciona para quien lo necesita?”
Conclusión
El monitoreo sintético cambia la forma de pensar la disponibilidad.
Pasamos de revisar piezas individuales a comprobar el funcionamiento real del servicio.
Porque al final del día:
- Al usuario no le importa que el proceso exista.
- Al cliente no le importa que la CPU esté al 30%.
- A nadie le importa que el servidor esté feliz si la aplicación está caída.
El objetivo del monitoreo no es saber si una máquina respira.
Es saber si el negocio sigue funcionando.
Tu monitoreo puede estar mintiéndote
Si tu única alerta es que alguien abra un ticket diciendo:
“La página está caída”
entonces no tienes monitoreo. Tienes un usuario haciendo de sensor.
En Orangebox implementamos monitoreo preventivo para servidores, aplicaciones y servicios críticos, utilizando herramientas como Zabbix y otras plataformas de observabilidad.
La idea es simple:
detectar el problema antes de que alguien te avise.
Si quieres revisar el estado real de tu infraestructura, conversemos.