Cómo Configurar Alertas de Caída (Uptime Monitor) en MU Online

El peor escenario para un administrador de MU Online no es que el servidor caiga — es que el servidor caiga y que tú te enteres horas después, por la captura rabiosa de un jugador en Discord. Cada minuto offline sin que lo sepas es reputación y retención evaporándose. Un monitor de uptime resuelve exactamente eso: un vigía automático que prueba, desde afuera, si tu servidor está aceptando conexiones y, en el instante en que algo falla, te avisa por Discord, Telegram o correo. Este tutorial muestra cómo montar ese sistema probando los puertos correctos de MU (no solo si la máquina está encendida), evitando alarmas falsas y creando una página de estado para la comunidad. Las herramientas, planes y valores citados son ejemplo y varían según el proveedor/versión; el concepto es lo que te vas a llevar.

Requisitos previos

• Servidor de MU ya publicado y accesible por internet (si aún lo estás montando, mira cómo crear un servidor de MU Online).
• IP público o dominio del servidor y los puertos que usan los jugadores.
• Un segundo punto para alojar el monitor: un VPS barato separado, un servicio de monitoreo externo o incluso un Raspberry/PC encendido 24h — lo importante es que sea independiente de la máquina monitoreada.
• Un canal de alerta listo: un webhook de Discord, un bot de Telegram o una cuenta de correo SMTP.
• Lista de los servicios críticos a vigilar: ConnectServer, GameServer(s), base de datos y sitio.

Paso 1 — Sabe exactamente qué monitorear

Monitorear "el servidor" es vago. El jugador no se conecta a una máquina, se conecta a puertos de servicios. Y cada servicio caído tiene un efecto diferente. Mapear esto es el primer paso.

Los puertos exactos varían según la versión y la configuración. Como ejemplo común en servidores S6, el ConnectServer suele responder en un puerto TCP conocido y cada GameServer en otro rango. Lo que importa es: descubre tus puertos reales en los archivos de configuración y monitorea cada uno. Un monitor que solo chequea si el IP responde al ping no detecta un GameServer trabado con la máquina encendida — y ese es justamente el caso más frustrante.

Paso 2 — Elige dónde va a correr el monitor

La regla de oro: monitorea desde afuera. Si el monitor corre dentro del propio VPS del juego y la máquina entera cae o pierde red, el monitor cae junto y nunca dispara la alerta. Tienes tres enfoques, del más simple al más completo:

1. Servicio externo de monitoreo: registras el IP y el puerto en una plataforma en la nube que chequea desde varios puntos del mundo. Rápido de montar; los planes gratuitos suelen bastar para empezar (varía según el proveedor).
2. Monitor open-source en tu propio VPS barato: alojas la herramienta en una segunda máquina, manteniendo control total y sin costo de licencia.
3. Script propio: un script liviano que prueba el puerto y dispara un webhook — máxima flexibilidad, útil para chequeos específicos de MU.

Lo ideal maduro combina el punto 1 o 2 (alerta principal, externa) con el punto 3 (chequeos internos de proceso). Empieza simple y evoluciona.

Paso 3 — Probar el puerto correcto (no solo el ping)

El corazón del monitor es la prueba de puerto TCP. Confirma que el servicio acepta conexión, que es lo que el cliente del juego necesita. Un script en PowerShell ilustra el concepto y ya sirve como monitor casero en Windows:

# monitor-porta.ps1 — prueba el puerto del ConnectServer y alerta en Discord
$alvo    = "SEU.IP.DO.SERVIDOR"
$porta   = 44405      # EJEMPLO: usa el puerto real de tu ConnectServer
$webhook = "https://discord.com/api/webhooks/SEU/WEBHOOK"

$ok = Test-NetConnection -ComputerName $alvo -Port $porta -InformationLevel Quiet

if (-not $ok) {
    $corpo = @{ content = "🔴 ALERTA: $alvo:$porta NO responde a las $(Get-Date -Format 'HH:mm:ss')" } | ConvertTo-Json
    Invoke-RestMethod -Uri $webhook -Method Post -Body $corpo -ContentType 'application/json'
}

En Linux, la misma prueba de puerto es trivial con nc (netcat):

# retorna exito si el puerto acepta conexion
nc -z -w 3 SEU.IP.DO.SERVIDOR 44405 && echo "UP" || echo "DOWN"

Para el sitio, la prueba es HTTP: además de que el puerto abra, el servidor debe responder un código de éxito (200). Un curl -sf https://tudominio.com/ que falla es señal de sitio caído incluso con el puerto 80/443 abierto.

Paso 4 — Evitar alarmas falsas

Un monitor que grita a cada oscilación de red se vuelve ruido, y el ruido uno aprende a ignorarlo — y ahí, cuando la caída es real, nadie le presta atención. Tres técnicas domesticán los falsos positivos:

• Confirmación por repetición: alerta solo tras 2 o 3 chequeos seguidos con falla. Una pérdida aislada de un paquete no derriba el servidor de verdad.
• Intervalo sensato: chequear cada 30-60 segundos detecta rápido sin exagerar el tráfico. Los intervalos cortísimos aumentan el ruido.
• Ventana de mantenimiento: al reiniciar el servidor a propósito, silencia las alertas en ese intervalo para no asustarte con tu propio mantenimiento.

Un ejemplo de confirmación por repetición, incrementando un contador antes de alertar:

# solo alerta en la 3a falla consecutiva
$falhas = 0
foreach ($tentativa in 1..3) {
    if (Test-NetConnection $alvo -Port $porta -InformationLevel Quiet) { $falhas = 0; break }
    $falhas++
    Start-Sleep -Seconds 5
}
if ($falhas -ge 3) { <# dispara la alerta aqui #> }

Paso 5 — Configurar los canales de alerta

La alerta solo sirve si llega hasta ti donde tú miras. Los tres canales más usados por los servidores de MU:

Discord (webhook): el más popular, porque la comunidad ya vive en Discord. Crea un webhook en un canal privado del staff (Configuración del canal → Integraciones → Webhooks) y usa la URL como en el script anterior. Simple e instantáneo.

Telegram (bot): excelente para alerta en el celular. Crea un bot con el BotFather, obtén el token y el chat id, y dispara el mensaje:

curl -s "https://api.telegram.org/botSEU_TOKEN/sendMessage" \
  -d chat_id=SEU_CHAT_ID \
  -d text="🔴 GameServer caído a las $(date +%H:%M)"

Correo (SMTP): bueno como canal secundario/redundante. Usa una contraseña de aplicación del proveedor de correo, nunca la contraseña principal de la cuenta.

Lo recomendado es tener al menos dos canales: si Discord tiene problemas justo en el momento de la caída, Telegram o el correo garantizan que la notificación llega.

Paso 6 — Programar el chequeo continuo

El monitor necesita correr solo, para siempre. En Windows, programa el script en el Programador de Tareas con un disparador repetido:

1. Abre taskschd.msc y crea una tarea.
2. Disparador: al iniciar el sistema, repitiendo cada 1 minuto indefinidamente.
3. Acción: powershell.exe -NonInteractive -ExecutionPolicy Bypass -File "C:\Monitor\monitor-porta.ps1".
4. Marca "Ejecutar aunque el usuario no haya iniciado sesión".

En Linux, cron cubre hasta el intervalo de minuto; para chequeos más frecuentes, un servicio systemd en bucle con sleep es el estándar. Si estás usando una herramienta open-source de uptime, ella ya gestiona la programación internamente — solo registras el objetivo, el puerto y el intervalo por la interfaz.

Paso 7 — Página de estado para la comunidad

Además de alertarte, un buen sistema comunica a los jugadores. Una página de estado pública que muestra "Online / Offline" de cada servicio reduce drásticamente el volumen de preguntas en el chat durante una caída y transmite profesionalismo. Las herramientas open-source de monitoreo ya generan esa página automáticamente; tú eliges qué exponer:

• Estado de cada GameServer y del ConnectServer.
• Uptime de los últimos 30/90 días en porcentaje.
• Historial de incidentes con horario de inicio y resolución.

Una comunidad que ve "estamos al tanto, servicio en mantenimiento" en el estado espera; una comunidad sin información asume abandono y migra. La página de estado es tan parte del monitoreo como la alerta.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Puertos reales de ConnectServer y GameServer identificados en los archivos de config
• Monitor probando el puerto TCP, no solo el ping
• Monitor corriendo desde un punto externo e independiente del VPS del juego
• Sitio probado por HTTP (código 200), no solo puerto abierto
• Confirmación por repetición (2-3 fallas) activa contra falso positivo
• Intervalo de chequeo entre 30 y 60 segundos
• Al menos dos canales de alerta configurados (ej: Discord + Telegram)
• Ventana de mantenimiento para silenciar alertas en reinicios planificados
• Chequeo programado corriendo 24h automáticamente
• Página de estado pública para la comunidad

Con un monitor de uptime bien montado, la caída deja de ser una sorpresa vergonzosa y se convierte en un incidente que ya estás resolviendo antes del primer reclamo de un jugador. Probando el puerto correcto, desde afuera, con alertas redundantes y sin alarma falsa, transformas el tiempo offline en minutos de reacción — y es esa velocidad la que separa a un servidor amateur de un proyecto en el que la comunidad confía.

Preguntas frecuentes