Cómo crear una status page pública para tu servidor de MU Online

Los servidores de MU Online se caen: por mantenimiento, actualización, pico de conexiones o simplemente un bug. Lo que diferencia a un servidor profesional de uno amateur no es nunca caerse, es cómo lo comunica. Una status page pública, alojada de forma independiente del servidor principal, muestra en tiempo real si el ConnectServer y el GameServer están en línea, cuántos jugadores están conectados, y mantiene un historial de incidentes transparente. Esto reduce drásticamente los tickets de soporte preguntando "¿se cayó?" y construye confianza con la comunidad. Este tutorial muestra cómo armar esa página, desde el monitoreo de puertos hasta las notificaciones automáticas de incidentes.

Por qué una status page cambia la percepción del jugador

Cuando el servidor se cae sin aviso, el jugador no sabe si es un problema de su conexión, si es una caída temporal o si el servidor "murió para siempre" (un miedo común en la comunidad de MU privado, dado el historial de servidores abandonados). Una status page pública elimina esa incertidumbre: el jugador lo verifica en segundos, sin necesidad de preguntarle a nadie.

Qué monitorear, como mínimo

Paso 1 — Elegir la arquitectura de monitoreo

Dos enfoques complementarios:

• Servicio de terceros (UptimeRobot, Better Uptime, StatusCake): monitorea la disponibilidad HTTP/puerto de afuera hacia adentro, con página de estado lista y alertas nativas. Rápido de configurar, independiente de tu infraestructura.
• Monitoreo propio: un script que corre en otro servidor/VPS, verificando los puertos y la base de datos, alimentando una página personalizada con datos específicos de MU (jugadores online, mapa más poblado).

La recomendación práctica es combinar ambos: servicio de terceros para la capa de disponibilidad "¿está en línea?", y página propia para los datos de juego.

Paso 2 — Script de verificación de puertos (ConnectServer/GameServer)

<?php
// monitor/checar_portas.php — corre en un servidor DIFERENTE del MuServer
function portaAberta(string $host, int $porta, float $timeout = 3.0): bool {
    $conexao = @fsockopen($host, $porta, $errno, $errstr, $timeout);
    if ($conexao) {
        fclose($conexao);
        return true;
    }
    return false;
}

$status = [
    'connect_server' => portaAberta('tuservidor.com', 44405),
    'game_server' => portaAberta('tuservidor.com', 55901),
    'checado_em' => date('c'),
];

file_put_contents('/var/status/ultimo_status.json', json_encode($status));

# crontab en el servidor de monitoreo
* * * * * php /opt/monitor/checar_portas.php

Paso 3 — Exponer el número de jugadores online

Consulta la base del MuServer (desde una API propia, con usuario solo lectura) para contar las conexiones activas:

<?php
// api/jogadores_online.php
$total = consultarQuery("SELECT COUNT(*) as total FROM MEMB_STAT WHERE ConnectStat = 1");
echo json_encode(['jogadores_online' => $total]);

Cuidado con el costo de esta query en bases grandes: cachea el resultado por 30-60 segundos en lugar de consultar en cada solicitud de la página pública.

Paso 4 — Armar la página pública

<div class="status-page">
  <h1>Estado del Servidor</h1>
  <div class="status-item">
    <span class="dot" data-status="connect-server"></span> ConnectServer
  </div>
  <div class="status-item">
    <span class="dot" data-status="game-server"></span> GameServer
  </div>
  <p id="jogadores-online">Cargando...</p>
  <h2>Historial de incidentes</h2>
  <ul id="lista-incidentes"></ul>
</div>

async function atualizarStatus() {
  const status = await fetch('/api/status.json').then(r => r.json());
  document.querySelector('[data-status="connect-server"]').classList.toggle('online', status.connect_server);
  document.querySelector('[data-status="game-server"]').classList.toggle('online', status.game_server);
  const jogadores = await fetch('/api/jogadores_online.php').then(r => r.json());
  document.getElementById('jogadores-online').textContent = `${jogadores.jogadores_online} jugadores online`;
}
setInterval(atualizarStatus, 30000);
atualizarStatus();

Paso 5 — Historial de incidentes

Registra toda caída detectada (inicio y fin) en una tabla propia, y muestra los últimos 30 días en la página; esto es lo que diferencia una status page profesional de un simple "punto verde/rojo":

CREATE TABLE incidentes (
    id INT AUTO_INCREMENT PRIMARY KEY,
    componente VARCHAR(50),
    inicio DATETIME,
    fim DATETIME NULL,
    descricao TEXT
);

function registrarQueda(string $componente) {
    if (!existeIncidenteAberto($componente)) {
        inserirIncidente($componente, date('Y-m-d H:i:s'));
    }
}

function registrarRecuperacao(string $componente) {
    fecharIncidenteAberto($componente, date('Y-m-d H:i:s'));
}

Paso 6 — Notificaciones automáticas de incidente

Dispara un webhook a Discord apenas se detecte una caída, y otro cuando el servicio se normalice:

async function notificarDiscord(mensagem, cor) {
  await fetch(process.env.DISCORD_WEBHOOK_STATUS, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      embeds: [{ title: 'Estado del Servidor', description: mensagem, color: cor }],
    }),
  });
}
// uso: notificarDiscord('🔴 GameServer está fuera de servicio desde las 21:04', 0xff0000);

Paso 7 — Alojar la status page fuera del servidor principal

Este es el punto más frecuentemente ignorado: si la status page vive en la misma VPS del juego, una caída total de la VPS derriba la página también, y el jugador se queda sin ninguna información justo en el peor momento. Aloja la página en otro proveedor (aunque sea un plan gratuito de hospedaje estático) o usa la propia página del servicio de uptime monitoring como página oficial de estado.

Paso 8 — SLA y mantenimientos programados

Anuncia los mantenimientos programados con anticipación directamente en la status page, marcando el período como "mantenimiento programado" en lugar de dejar que aparezca como incidente; esto evita alarmas innecesarias en la comunidad y demuestra organización.

Errores comunes y soluciones

Lista de verificación de la status page

• Monitoreo de ConnectServer, GameServer, base de datos y sitio configurado.
• Status page alojada fuera del servidor/VPS principal del juego.
• Conteo de jugadores online expuesto con cache adecuado.
• Historial de incidentes registrándose automáticamente (inicio y fin).
• Notificaciones automáticas configuradas (Discord/correo) para caída y recuperación.
• Mantenimientos programados anunciados con anticipación en la página.
• Pruebas de falso positivo (flapping) realizadas y ajustadas.
• Enlace de la status page visible en el sitio principal y en Discord.

Con la transparencia de disponibilidad resuelta, vale la pena revisar el resto de la infraestructura del servidor para reducir la frecuencia real de las caídas, no solo comunicarlas mejor; comienza por la guía de creación de servidor de MU Online para revisar la arquitectura de punta a punta.

Preguntas frecuentes