Cómo configurar alertas de incidentes vía Telegram para tu servidor de MU Online

Cuando el GameServer se cae a las 3 de la madrugada y nadie se entera hasta que los jugadores empiezan a quejarse en Discord, el costo no es solo técnico — es reputacional, y en servidores monetizados, también financiero (donaciones y eventos pagos interrumpidos sin aviso). Un sistema de alertas vía Telegram resuelve este punto ciego, avisando al equipo de administración en segundos, directo al celular, sin depender de que alguien esté mirando un panel. Este tutorial muestra cómo crear el bot, escribir los scripts de verificación de los servicios críticos de tu servidor de MU Online, configurar el escalamiento y probar fallas de forma controlada antes de confiar en el sistema en producción.

Por qué Telegram y no correo o SMS

El correo tiene un retraso de entrega variable y con frecuencia cae en spam cuando se envía desde un script automatizado sin infraestructura de SMTP con buena reputación. El SMS tiene costo por mensaje y no escala bien para alertas frecuentes. Telegram, en cambio, ofrece una API de bot gratuita, entrega casi instantánea vía push notification en el celular, y soporta grupos con múltiples administradores recibiendo la misma alerta simultáneamente — es el canal más usado hoy por administradores de servidores privados justamente por esta combinación de costo cero y velocidad.

Creando el bot en Telegram

1. Abre una conversación con @BotFather dentro de Telegram.
2. Envía /newbot y sigue las instrucciones, definiendo un nombre (por ejemplo, "ViciadosMU Monitor") y un username terminado en "bot" (por ejemplo, viciadosmu_monitor_bot).
3. BotFather devuelve un token con el formato 123456789:ABCdefGhIJKlmNoPQRsTUvwxYZ — guárdalo con el mismo cuidado que una contraseña de base de datos.
4. Crea un grupo de Telegram con los administradores y añade el bot a ese grupo.
5. Descubre el chat_id del grupo accediendo a https://api.telegram.org/bot<TOKEN>/getUpdates después de enviar cualquier mensaje en el grupo — el chat_id del grupo aparece en el JSON devuelto (generalmente un número negativo).

Estructura de monitoreo: qué revisar en el servidor de MU

Script de verificación en Bash (Linux)

Un script simple, ejecutado por cron cada minuto, cubre la mayoría de los casos:

#!/bin/bash
# monitor_mu.sh
TOKEN="123456789:ABCdefGhIJKlmNoPQRsTUvwxYZ"
CHAT_ID="-1001234567890"
STATE_FILE="/tmp/mu_monitor_state"

send_alert() {
    local message="$1"
    curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
        -d chat_id="${CHAT_ID}" \
        -d text="${message}" \
        -d parse_mode="Markdown" > /dev/null
}

check_process() {
    local name="$1"
    local proc="$2"
    if ! pgrep -f "${proc}" > /dev/null; then
        if ! grep -q "${name}_DOWN" "${STATE_FILE}" 2>/dev/null; then
            send_alert "🔴 *ALERTA*: ¡${name} se cayó en el servidor!"
            echo "${name}_DOWN" >> "${STATE_FILE}"
        fi
    else
        if grep -q "${name}_DOWN" "${STATE_FILE}" 2>/dev/null; then
            send_alert "🟢 *RECUPERADO*: ${name} volvió a la normalidad."
            sed -i "/${name}_DOWN/d" "${STATE_FILE}"
        fi
    fi
}

check_process "GameServer" "GameServer"
check_process "ConnectServer" "ConnectServer"
check_process "MySQL" "mysqld"

Guárdalo como /opt/scripts/monitor_mu.sh, dale permiso de ejecución (chmod +x) y agéndalo en el cron:

* * * * * /opt/scripts/monitor_mu.sh

Monitoreando el sitio y el panel

Para verificar disponibilidad HTTP, agrega una función equivalente usando curl con verificación del código de estado:

check_http() {
    local name="$1"
    local url="$2"
    local status
    status=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "${url}")
    if [ "${status}" != "200" ]; then
        send_alert "🔴 *ALERTA*: ${name} respondió con estado ${status} (se esperaba 200)."
    fi
}

check_http "Sitio principal" "https://www.viciadosmu.com.br"
check_http "Panel de login" "https://www.viciadosmu.com.br/login"

Evitando la fatiga de alertas con cooldown

Enviar una alerta cada minuto mientras el servicio está caído vuelve el canal inútil rápidamente — el equipo termina silenciando las notificaciones. El patrón usado en el script anterior (archivo de estado STATE_FILE) resuelve esto: la alerta solo se reenvía cuando el estado cambia (de "arriba" a "abajo" o viceversa), no en cada ejecución del cron. Para casos que requieren recordatorios periódicos durante incidentes largos, agrega un segundo timestamp que dispare un "recordatorio" cada 30 minutos mientras el servicio permanezca caído.

Escalamiento por severidad

No toda alerta tiene la misma urgencia. Sepáralas por nivel de severidad para no mezclar una alerta de "disco 85% lleno" con "GameServer se cayó":

Crea grupos o temas separados en Telegram por nivel, para que las alertas críticas no se pierdan entre mensajes informativos de rutina.

Probando el sistema antes de confiar en él

Nunca confíes en un sistema de alertas que nunca se ha disparado a propósito. Haz una prueba controlada: detén manualmente el GameServer en un horario de bajo movimiento (systemctl stop gameserver o kill en el proceso), confirma que la alerta llega a Telegram en menos de 1 minuto, vuelve a levantar el servicio y confirma que la alerta de "recuperado" también se dispara. Repite la prueba para MySQL y para el sitio, simulando la caída de cada uno de forma aislada.

Integrando con logs específicos del emulador

Además de procesos y puertos, muchos emuladores generan archivos de log con errores específicos (falla de autenticación masiva, error de conexión con la base de cuentas, excepciones no controladas). Un tail -F combinado con grep en un bucle puede disparar alertas cuando aparezcan patrones de error conocidos:

tail -F /home/mu/GameServer/Log/error.log | while read -r line; do
    if echo "${line}" | grep -qi "database connection failed"; then
        send_alert "⚠️ El log del GameServer reportó una falla de conexión con la base de datos."
    fi
done

Corre este bucle como un servicio systemd separado, no dentro del cron principal, ya que se mantiene en ejecución continua.

Buenas prácticas de seguridad del bot

Nunca dejes el token del bot en un repositorio público ni en un script accesible vía URL del sitio. Trátalo como una credencial: guárdalo en una variable de entorno o en un archivo con permisos restringidos (chmod 600). Si el token se filtra, revócalo de inmediato desde BotFather (/revoke) y genera uno nuevo, actualizando todos los scripts que lo utilicen.

Errores comunes y soluciones

Lista de verificación de implementación de las alertas

• Bot creado en BotFather y token almacenado de forma segura.
• Grupo de Telegram creado con los administradores y chat_id identificado.
• Script de verificación de procesos (GameServer, ConnectServer, MySQL) agendado en el cron.
• Verificación HTTP del sitio y panel configurada.
• Cooldown/estado implementado para evitar la fatiga de alertas.
• Niveles de severidad definidos y separados por canal/tema.
• Prueba controlada de caída y recuperación realizada para cada servicio.
• Monitoreo del propio monitor (watchdog) configurado.

Con las alertas corriendo de forma confiable, el siguiente paso es conectar este monitoreo con la rutina general de operación del servidor descrita en el tutorial de cómo crear un servidor de MU Online, garantizando que infraestructura, juego y comunidad estén todos cubiertos por el mismo proceso de respuesta a incidentes.

Preguntas frecuentes