Cómo armar un dashboard de métricas en tiempo real para tu servidor de MU Online

Administrar un servidor de MU Online "a ciegas" — sin visibilidad de cuántos jugadores están en línea ahora, si la base de datos está bajo estrés, o si la economía se está inflando — es como pilotar sin panel de instrumentos. Un dashboard de métricas en tiempo real transforma decisiones de operación (cuándo escalar el hardware, cuándo revisar una tasa de drop, cuándo investigar lag) de "corazonada" a dato concreto. Este tutorial recorre la construcción de un dashboard completo: desde la recolección de métricas de sistema y de juego, pasando por el almacenamiento en series temporales, hasta la visualización en panel web y las alertas automáticas.

Qué vale la pena medir

Antes de elegir la herramienta, define qué debe responder el dashboard. Un conjunto sólido de métricas para servidor de MU cubre tres capas:

Las métricas de infraestructura y de servidor de juego piden alta frecuencia porque cambian rápido; las métricas de economía son agregadas y cambian despacio, así que recolectar cada minuto ya satisface la necesidad.

Prerrequisitos

• Servidor de MU ya funcionando y configurado.
• Acceso a la base de datos del emulador (MSSQL o MySQL, según el emulador).
• Una máquina/VM (o el propio host) para correr el stack de monitoreo.
• Conocimiento básico de scripting (PowerShell, Python o Node.js) para los recolectores.

Paso 1 — Elegir el stack de monitoreo

Dos rutas comunes:

• Stack lista (Prometheus + Grafana): Prometheus recolecta y almacena series temporales; Grafana visualiza. Curva de aprendizaje mayor, pero extremadamente extensible y con alertas nativas.
• Panel propio ligero: un script recolector graba métricas periódicamente en una tabla SQL, y una página web simple (PHP/Node) consulta y muestra vía gráficos (Chart.js). Más rápido de armar, menos flexible a largo plazo.

Para servidores pequeños/medianos, empieza con el panel propio; migra a Prometheus/Grafana cuando el volumen de métricas lo justifique.

Paso 2 — Crear la tabla de series temporales (ruta propia)

CREATE TABLE metrics_snapshot (
    id INT IDENTITY PRIMARY KEY,
    captured_at DATETIME NOT NULL DEFAULT GETDATE(),
    players_online INT NOT NULL,
    cpu_percent DECIMAL(5,2),
    ram_percent DECIMAL(5,2),
    zen_total BIGINT,
    excellent_drops_last_hour INT
);

Esta tabla crece rápido si se recolecta cada pocos segundos — planifica una rutina de limpieza (ej.: mantener granularidad fina por 7 días y agregar en promedios horarios después).

Paso 3 — Escribir el recolector de infraestructura

Un recolector simple en PowerShell (Windows) que graba CPU y RAM cada 15 segundos:

while ($true) {
    $cpu = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue
    $ram = (Get-CimInstance Win32_OperatingSystem)
    $ramPercent = 100 - ($ram.FreePhysicalMemory / $ram.TotalVisibleMemorySize * 100)

    Invoke-Sqlcmd -Query "INSERT INTO metrics_snapshot (cpu_percent, ram_percent) VALUES ($cpu, $ramPercent)"
    Start-Sleep -Seconds 15
}

Ejecútalo como servicio/tarea programada para garantizar que la recolección sobreviva a reinicios.

Paso 4 — Escribir el recolector de métricas de juego

Consulta la tabla de cuentas/personajes conectados de la propia base de datos del emulador (el nombre de la columna/tabla varía según el emulador — generalmente algo como MEMB_STAT o una flag de conexión en Character):

SELECT COUNT(*) AS players_online FROM MEMB_STAT WHERE ConnectStat = 1;

Guarda ese valor junto con la economía agregada (suma de Zen, conteo de Excellent dropeados en la última hora vía log de ítems, si tu emulador registra ese log).

Paso 5 — Montar la visualización (panel web)

Una página simple consultando la tabla metrics_snapshot y renderizando con Chart.js:

fetch('/api/metrics?range=1h')
  .then(r => r.json())
  .then(data => {
    new Chart(document.getElementById('grafico-online'), {
      type: 'line',
      data: {
        labels: data.map(d => d.captured_at),
        datasets: [{ label: 'Players Online', data: data.map(d => d.players_online) }]
      }
    });
  });

Arma paneles separados para: online a lo largo del día, CPU/RAM, y economía (Zen en circulación, drops de Excellent).

Paso 6 — Agregar healthcheck y alertas

Configura un script que pruebe el puerto del ConnectServer/GameServer cada minuto y dispare un webhook a Discord si la verificación falla 3 veces seguidas (evitando alerta falsa por inestabilidad momentánea de red):

$falhas = 0
while ($true) {
    $ok = Test-NetConnection -ComputerName "127.0.0.1" -Port 44405 -InformationLevel Quiet
    if (-not $ok) {
        $falhas++
        if ($falhas -ge 3) {
            Invoke-RestMethod -Uri $webhookDiscord -Method Post -Body (@{content="⚠️ ¡GameServer fuera de línea!"} | ConvertTo-Json) -ContentType 'application/json'
        }
    } else { $falhas = 0 }
    Start-Sleep -Seconds 60
}

Paso 7 — Monitorear queries lentas de la base de datos

Habilita el log de queries lentas de tu SGBD (slow query log en MySQL, Query Store en SQL Server) y suma al dashboard un panel con las queries más lentas de la última hora. Esto suele revelar cuellos de botella antes de que se conviertan en lag perceptible para los jugadores, especialmente en picos de horario pico.

Paso 8 — Definir retención y agregación de datos

Sin una política de retención, la tabla de métricas crece indefinidamente. Un esquema razonable: mantener granularidad de 15 segundos por 48h, agregar en promedios de 5 minutos por 30 días, y agregar en promedios diarios indefinidamente para análisis histórico de largo plazo.

Paso 9 — Restringir acceso a datos sensibles

Separa el dashboard en dos capas: una pública (o semipública, en el sitio) con métricas agregadas (online total, uptime, season actual) para transparencia con la comunidad, y una administrativa autenticada con detalles sensibles (IPs, cuentas específicas, logs individuales).

Errores comunes y soluciones

Lista de verificación de implementación

• Métricas de infraestructura, juego y economía definidas y priorizadas.
• Tabla/stack de series temporales creada con plan de retención.
• Recolectores de sistema y de juego corriendo como servicio persistente.
• Panel de visualización armado con gráficos de las métricas clave.
• Healthcheck con alerta vía webhook configurado y probado.
• Monitoreo de queries lentas habilitado en la base de datos.
• Separación entre panel público (agregado) y administrativo (detallado).

Con el dashboard en línea, pasas a decidir escalamiento de hardware, ajustes de economía y ventanas de mantenimiento con dato real en vez de intuición — el siguiente paso es revisar la configuración base del servidor descrita en el tutorial de creación de servidor a la luz de los números que el dashboard está revelando.

Preguntas frecuentes