Cómo configurar el LogServer y la auditoría en MU Online

Un servidor de MU Online sin auditoría es un servidor ciego. Tarde o temprano alguien va a duplicar un Excellent, robar la cuenta de un jugador veterano o abusar de un comando de GM, y necesitarás responder una pregunta simple que, sin datos, se vuelve imposible: ¿qué pasó exactamente, cuándo y por quién? El LogServer es el componente responsable de transformar cada evento relevante del juego en un rastro permanente y cronológico. Este tutorial muestra, desde cero, cómo planificar qué registrar, configurar el LogServer, definir políticas de retención, proteger la integridad de los registros y conducir investigaciones de fraude reales a partir de los logs. El enfoque es conceptual y práctico a la vez: los conceptos de MU son reales y universales, mientras que los nombres de archivos y claves de configuración aparecen solo como ejemplo y varían según el emulador.

Requisitos previos

Antes de tocar cualquier archivo, ten el entorno básico funcionando. Si aún no has montado la estructura completa, empieza por la guía de cómo crear un servidor de MU Online y vuelve aquí cuando el GameServer arranque normalmente.

• GameServer, ConnectServer y base de datos (MSSQL en la mayoría de los emuladores) ya operativos.
• Acceso administrativo al servidor Windows (o al host) donde corren los servicios.
• Un usuario de base de datos dedicado, con permiso de escritura solo en las tablas de log.
• Espacio en disco planificado: los logs crecen rápido en servidores poblados.
• Horario del sistema sincronizado vía NTP en todas las máquinas involucradas.
• Copia de seguridad funcional ya configurada, para que los propios logs entren en la rutina de copia.

Reserva también una decisión de arquitectura antes de empezar: ¿los logs van a archivos de texto, a una base de datos separada, o a ambos? La recomendación para servidores serios es base de datos separada como fuente primaria (consultas rápidas) y archivos rotados como copia bruta de contingencia.

Qué es el LogServer y dónde encaja

En un stack típico de MU Online tienes el ConnectServer enrutando jugadores hacia los GameServers, el DataServer (o JoinServer) intermediando el acceso a la base de datos, y el GameServer ejecutando la lógica del mundo. El LogServer es un servicio aparte que recibe eventos enviados por el GameServer a través de un puerto TCP dedicado y los persiste. No interfiere en la jugabilidad: si cae, el juego continúa, pero dejas de recolectar rastro. Por eso necesita ser resiliente, pero nunca debe ser un punto de bloqueo del GameServer.

El punto crucial de entendimiento es la diferencia entre estado e historial. La base de datos de producción muestra el estado actual: el inventario del personaje ahora, el zen en la cuenta ahora. No cuenta cómo llegó ese ítem allí. El LogServer llena ese vacío registrando la secuencia de eventos que llevó al estado actual. Sin historial, ves el resultado de un fraude, pero nunca el método.

Qué eventos registrar

Registrar todo es tentador y erróneo: genera un volumen impagable y ruido que estorba la investigación. Lo correcto es registrar los eventos de alto valor forense, aquellos que sostienen la mayoría de las disputas y fraudes.

Además del evento en sí, cada registro debe llevar metadatos mínimos: timestamp con precisión de segundo o mejor, ID de cuenta, nombre del personaje, IP de origen, y un identificador de sesión cuando el emulador lo ofrezca. Un metadato pobre es la causa número uno de investigaciones que se atascan.

Configurando el LogServer: paso a paso

Los nombres de abajo son ejemplos y varían según el emulador; la lógica es la misma en todos.

1. Localiza el ejecutable y el archivo de configuración del LogServer. Suele estar en una carpeta propia dentro del directorio del servidor, con un archivo tipo LogServer.ini o equivalente.
2. Define el puerto de escucha. Elige un puerto interno que solo el GameServer alcance, por ejemplo 55906. Nunca expongas ese puerto a internet.
3. Apunta el destino de escritura. Si es base de datos, informa la cadena de conexión de la base de logs separada; si es archivo, define la carpeta de salida y el patrón de nombre con fecha.
4. Activa la escritura asíncrona. Esto garantiza que el GameServer entregue el evento y siga adelante sin esperar al disco.
5. Configura el GameServer para enviar al LogServer. En el archivo de configuración del GameServer, apunta la IP y el puerto del LogServer y activa las categorías de log deseadas.
6. Define el nivel de detalle por categoría. Trade y comandos de GM en detalle máximo; los eventos de altísimo volumen pueden ir en nivel resumido.
7. Levanta el LogServer antes del GameServer. El orden correcto de inicialización evita pérdida de eventos en el arranque.
8. Valida con un evento controlado. Haz un trade de prueba entre dos cuentas tuyas y confirma que aparece en el rastro con todos los metadatos.

Un fragmento ilustrativo de configuración (el formato varía según el emulador):

[LogServer]
BindPort=55906
Mode=Database        ; o File
AsyncWrite=1
QueueMax=100000

[Categories]
Trade=Full
Drop=Full
GmCommand=Full
Login=Full
ItemHighValue=Full
Chat=Off

Y del lado del GameServer, la referencia correspondiente:

[Logging]
LogServerIP=127.0.0.1
LogServerPort=55906
EnableTradeLog=1
EnableGmCommandLog=1
EnableDropLog=1

Estructura de la tabla de logs

Si optas por base de datos, una tabla bien diseñada acelera cualquier investigación. Un esquema de ejemplo:

CREATE TABLE GameLog (
    LogId       BIGINT IDENTITY PRIMARY KEY,
    EventTime   DATETIME2   NOT NULL,
    Category    VARCHAR(32) NOT NULL,
    AccountId   VARCHAR(32) NULL,
    CharName    VARCHAR(32) NULL,
    SourceIp    VARCHAR(45) NULL,
    TargetName  VARCHAR(32) NULL,
    ItemCode    VARCHAR(64) NULL,
    Amount      BIGINT      NULL,
    RawDetail   NVARCHAR(MAX) NULL
);
CREATE INDEX IX_GameLog_Time ON GameLog (EventTime);
CREATE INDEX IX_GameLog_Char ON GameLog (CharName, EventTime);
CREATE INDEX IX_GameLog_Cat  ON GameLog (Category, EventTime);

Los índices por tiempo, por personaje y por categoría cubren casi todas las consultas forenses. El campo RawDetail guarda el payload completo del evento en texto, garantizando que nada se pierda aunque el esquema evolucione.

Retención y rotación

Los logs útiles son los logs que aún tienes cuando el problema aparece. Y los problemas aparecen tarde: un jugador reporta un robo semanas después. Al mismo tiempo, guardar todo para siempre es caro y degrada el rendimiento de las consultas. La respuesta es una política de retención en capas.

Automatiza el paso entre capas. Un job nocturno puede exportar registros con más de 90 días a archivos .csv.gz diarios y eliminarlos de la tabla caliente. La rotación por tamaño también vale para logs en archivo: cierra y comprime el archivo actual al alcanzar, por ejemplo, 200 MB, evitando archivos monstruosos imposibles de abrir.

Integridad: logs en los que se puede confiar

Un log que puede ser adulterado no sirve para banear a nadie. Trata el rastro como prueba y protege su integridad.

• Cuenta de base de datos solo de escritura y lectura, nunca de update/delete para el servicio de log. El LogServer nunca debería necesitar borrar un registro.
• Servidor de logs aislado de la base de datos de producción, de preferencia en otra máquina o instancia, para que una intrusión al juego no comprometa el rastro.
• Horario sincronizado por NTP en todos los nodos. Sin eso, correlacionar eventos entre GameServers se vuelve adivinanza.
• Hash encadenado opcional para casos de alta exigencia: cada registro guarda el hash del anterior, haciendo detectable cualquier eliminación.
• Copias de seguridad del rastro incluidas en la rutina general y probadas por restauración.

Investigando fraudes en la práctica

Aquí los logs dejan de ser un archivo y se vuelven una herramienta. Considera un caso clásico: un jugador reporta que perdió un Excellent raro después de un trade. El guion de investigación:

1. Fija el objetivo y la ventana. Nombre del personaje de la víctima y horario aproximado del trade.
2. Extrae la línea de tiempo del personaje. Consulta todos los eventos de ese personaje en ese intervalo, ordenados por tiempo.
3. Aísla el trade. Encuentra el evento de trade, mira los dos lados, los ítems y la confirmación. Confirma si el ítem salió del inventario de la víctima.
4. Sigue el ítem. Usa el código del ítem para rastrear dónde fue a parar: quién lo recibió, y qué hizo esa cuenta a continuación.
5. Correlaciona cuentas e IPs. Si la cuenta que recibió y una segunda cuenta comparten IP o HWID, probablemente encontraste un esquema de multicuenta.
6. Cierra la cadena. Une login, trade, drop y movimiento posterior en una narrativa única antes de decidir la sanción.

Una consulta de línea de tiempo de ejemplo:

SELECT EventTime, Category, CharName, TargetName, ItemCode, Amount
FROM GameLog
WHERE (CharName = 'VitimaAqui' OR TargetName = 'VitimaAqui')
  AND EventTime BETWEEN '2026-03-10 20:00' AND '2026-03-10 22:00'
ORDER BY EventTime;

Para detectar duplicación de ítems (el mismo ítem único apareciendo en dos lugares), busca el mismo ItemCode de ítem serializado siendo creado o recibido por cuentas diferentes sin un evento de transferencia legítimo entre ellas. Los ítems que surgen sin origen rastreable son la firma de un exploit.

Detección proactiva

Investigar después del daño es bueno; evitar el daño es mejor. El mismo rastro alimenta alertas automáticas. Ejecuta consultas periódicas en busca de patrones anómalos: ganancia de zen por encima de un límite por hora, número de trades por minuto muy por encima de la media, el mismo ítem serializado tocando muchas cuentas en poco tiempo, o un comando de GM ejecutado por una cuenta que no debería tener ese poder. Una alerta simple que dispara un aviso en el Discord de la staff transforma el LogServer de archivo pasivo en sensor activo.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• El LogServer levanta antes del GameServer en la secuencia de arranque
• El puerto del LogServer es interno y no está expuesto a internet
• Escritura asíncrona activada y probada bajo carga
• Base de datos de logs separada de la base de producción
• Índices por tiempo, personaje y categoría creados
• Categorías críticas (trade, drop, comando de GM) en detalle máximo
• Metadatos mínimos presentes: horario, cuenta, personaje, IP
• NTP sincronizado en todos los nodos del servidor
• Política de retención en capas definida y automatizada
• Rotación por tamaño configurada para logs en archivo
• Cuenta de log sin permiso de update o delete
• Logs incluidos en la rutina de copia de seguridad y restauración probada
• Consulta de línea de tiempo validada con un trade de prueba
• Alerta automática de anomalías apuntada al canal de la staff
• Procedimiento de investigación documentado para el equipo de GMs

Con el LogServer bien configurado, dejas de operar a ciegas. Cada disputa se vuelve una consulta, cada fraude deja rastro y cada decisión de baneo pasa a apoyarse en prueba, no en sospecha. Ese es el cimiento de un servidor que los jugadores respetan porque saben que las reglas se aplican con base en hechos.

Preguntas frecuentes