Cómo crear un panel de métricas del servidor de MU

No puedes administrar lo que no logras medir. Muchos servidores de MU Online se gestionan a ciegas: el admin solo descubre que la máquina está sobrecargada cuando los jugadores empiezan a quejarse del lag, o solo percibe una duplicación de ítems cuando la economía ya colapsó. Un panel de métricas resuelve esto transformando el estado del servidor en números visibles e históricos, permitiendo actuar antes de que el problema se vuelva crisis.

En este tutorial vas a montar un panel de métricas práctico combinando datos de tres fuentes: la máquina (sistema operativo), el proceso del servidor de juego y la base de datos de MU. Vamos a usar un stack abierto y común — un colector de series temporales, un almacenamiento y una capa de visualización — pero los conceptos se aplican a cualquier herramienta. Los nombres de tablas y columnas varían por season/emulador (Season 6, IGCN, MuEMU, X-Files, etc.), así que trata las consultas SQL como EJEMPLO y adáptalas a tu estructura.

Requisitos previos

Antes de empezar, ten a mano:

1. Acceso administrativo a la máquina del servidor de juego.
2. Una segunda máquina o VPS pequeño para alojar el colector y el panel (recomendado, para no competir por recursos con el juego).
3. Acceso de lectura a la base de datos de MU (crea un usuario metrics_ro solo con SELECT).
4. Familiaridad básica con SQL y con la edición de archivos de configuración.
5. Puertos liberados entre el colector y la máquina del juego (solo en la red interna o vía VPN, nunca expuestos a internet).

Nunca uses la cuenta sa ni el usuario de la aplicación para recolectar métricas. Un usuario de solo lectura dedicado limita el daño en caso de que las credenciales del panel se filtren.

Paso 1 — Definir qué medir

Antes de instalar cualquier herramienta, decide qué preguntas necesita responder el panel. Un error común es recolectar todo y no mirar nada. Divide las métricas en cuatro categorías:

• Salud de la máquina: CPU, memoria, disco, red, uptime.
• Salud del servicio de juego: procesos del GameServer/ConnectServer vivos, latencia de login, colas.
• Actividad de los jugadores: cuentas online, personajes creados, distribución por mapa.
• Economía y seguridad: zen en circulación, ítems excellent creados por hora, resets por hora, fallas de login.

La categoría de economía y seguridad es la que más diferencia a un panel amateur de uno profesional, porque es allí donde detectas duplicación, bots e invasiones.

Paso 2 — Arquitectura del panel

La arquitectura recomendada tiene tres componentes:

1. Colector/exportador: lee métricas de la máquina y de la base y las expone en un formato estandarizado.
2. Base de series temporales: almacena los puntos recolectados a lo largo del tiempo.
3. Capa de visualización: arma los gráficos y dispara alertas.

Un conjunto popular y gratuito es Prometheus (recolección + almacenamiento) con Grafana (visualización), más un node_exporter para las métricas de máquina y un pequeño script que consulta la base de MU y expone las métricas de juego. La elección exacta es secundaria; lo importante es separar recolección, almacenamiento y visualización.

Paso 3 — Recolectar métricas de máquina

Instala un exportador de métricas de sistema en la máquina del juego. Expone CPU, memoria, disco y red en un endpoint que el colector lee periódicamente. Del lado del colector, configura un objetivo apuntando a ese endpoint, accesible solo por la red interna:

scrape_configs:
  - job_name: 'mu-maquina'
    scrape_interval: 15s
    static_configs:
      - targets: ['10.0.0.5:9100']  # IP interno de la máquina del juego

Con esto ya consigues gráficos de uso de CPU y memoria. Define alertas para un uso sostenido por encima del 85% de CPU o del 90% de disco, que son los cuellos de botella más comunes en servidores de MU bajo evento.

Paso 4 — Recolectar métricas de la base de juego

Aquí está el corazón del panel. Escribe un pequeño exportador que corra consultas SQL periódicas con el usuario metrics_ro y publique los resultados como métricas. Ejemplos de consultas (adapta los nombres de las tablas):

-- Cuentas actualmente online
SELECT COUNT(*) AS online FROM MEMB_STAT WHERE ConnectStat = 1;

-- Zen total en circulación (suma de los personajes)
SELECT SUM(CAST(Money AS BIGINT)) AS zen_total FROM Character;

-- Resets realizados en las últimas 24h (si hay columna de log)
SELECT COUNT(*) AS resets_24h
FROM ResetLog
WHERE ResetDate >= DATEADD(HOUR, -24, GETDATE());

Publica cada resultado como una métrica nombrada (por ejemplo, mu_online_accounts, mu_zen_total, mu_resets_24h). Corre las consultas de juego cada 1-5 minutos; consultas pesadas corriendo cada segundo perjudican el rendimiento del juego. Usa siempre índices y evita SELECT * en tablas grandes.

Paso 5 — Montar los paneles visuales

En la capa de visualización, crea dashboards temáticos. Un buen conjunto inicial:

1. Visión general: jugadores online, uptime, CPU y memoria en una sola pantalla.
2. Economía: zen total, zen creado por hora, ítems excellent generados por hora.
3. Seguridad: fallas de login por minuto, cuentas creadas por IP, comandos de GM usados.
4. Infraestructura: disco, red, latencia de la base.

Usa gráficos de línea para las tendencias y valores instantáneos (single stat) para el estado actual. Marca los umbrales con colores: verde en lo normal, amarillo en atención, rojo en crítico.

Paso 6 — Configurar alertas

Un panel que nadie mira no previene nada. Configura alertas que empujen la información hacia ti (email, webhook de Discord, Telegram). Ejemplos de reglas útiles:

• CPU por encima del 90% por más de 5 minutos.
• Proceso del GameServer ausente (el online cayó a cero abruptamente).
• Zen total creciendo más de X% en una hora (posible duplicación).
• Más de N fallas de login por minuto viniendo del mismo IP (fuerza bruta).
• Disco con menos del 10% libre.

Tabla de métricas esenciales

Tabla de umbrales de alerta (ejemplo)

Los números de arriba son un EJEMPLO de punto de partida y varían por season/emulador, tamaño de la comunidad y horario. Ajusta los umbrales después de observar el comportamiento normal de tu servidor durante algunos días.

Errores comunes y soluciones

Buenas prácticas de operación

Documenta el significado de cada panel para que cualquier miembro del equipo entienda una alerta a las 3 de la mañana. Haz backup de las definiciones de los dashboards junto con el resto del servidor. Revisa los umbrales mensualmente, porque la base de jugadores y los eventos cambian lo que es normal. Y trata el panel de seguridad con la misma seriedad que el panel técnico: muchas invasiones y duplicaciones son detectables por anomalías en las métricas de economía antes de cualquier denuncia de jugador.

Lista de verificación de lanzamiento

• Categorías de métricas definidas (máquina, servicio, jugadores, economía)
• Usuario metrics_ro de solo lectura creado
• Colector y panel corriendo en una máquina separada
• Exportador de máquina instalado y recolectando
• Consultas SQL de juego validadas e indexadas
• Dashboards de visión general, economía, seguridad e infraestructura montados
• Alertas de CPU, disco, online, zen y fallas de login configuradas
• Alertas enviadas por un canal de push (Discord/Telegram/email)
• Umbrales calibrados con el comportamiento normal observado
• Retención de historial adecuada y con backup
• Endpoints de métricas cerrados a internet
• Documentación de los paneles compartida con el equipo

Con el panel en línea, dejas de administrar a ciegas y pasas a anticipar problemas de rendimiento, economía y seguridad. Si todavía estás estructurando el servidor, la guía de cómo crear un servidor de MU Online ayuda a montar la base sobre la cual correrá el monitoreo. Un buen panel no es un lujo: es la diferencia entre reaccionar a incendios y prevenirlos.

Preguntas frecuentes