Como configurar o LogServer e a auditoria no MU Online

Um servidor de MU Online sem auditoria é um servidor cego. Cedo ou tarde alguém vai duplicar um Excellent, roubar a conta de um jogador veterano ou abusar de um comando de GM, e você precisará responder uma pergunta simples que, sem dados, se torna impossível: o que exatamente aconteceu, quando e por quem? O LogServer é o componente responsável por transformar cada evento relevante do jogo em uma trilha permanente e cronológica. Este tutorial mostra, do zero, como planejar o que registrar, configurar o LogServer, definir políticas de retenção, proteger a integridade dos registros e conduzir investigações de fraude reais a partir dos logs. O foco é conceitual e prático ao mesmo tempo: os conceitos de MU são reais e universais, enquanto os nomes de arquivos e chaves de configuração aparecem apenas como exemplo e variam por emulador.

Pré-requisitos

Antes de tocar em qualquer arquivo, tenha o ambiente básico funcionando. Se você ainda não montou a estrutura completa, comece pelo guia de como criar servidor de MU Online e volte aqui quando o GameServer já subir normalmente.

• GameServer, ConnectServer e banco de dados (MSSQL na maioria dos emuladores) já operacionais.
• Acesso administrativo ao servidor Windows (ou ao host) onde os serviços rodam.
• Um usuário de banco dedicado, com permissão de escrita apenas nas tabelas de log.
• Espaço em disco planejado: logs crescem rápido em servidores populados.
• Horário do sistema sincronizado via NTP em todas as máquinas envolvidas.
• Backup funcional já configurado, para que os próprios logs entrem na rotina de cópia.

Reserve também uma decisão de arquitetura antes de começar: os logs vão para arquivos texto, para um banco separado, ou para ambos? A recomendação para servidores sérios é banco separado como fonte primária (consultas rápidas) e arquivos rotacionados como cópia bruta de contingência.

O que é o LogServer e onde ele se encaixa

Em uma stack típica de MU Online você tem o ConnectServer roteando jogadores para os GameServers, o DataServer (ou JoinServer) intermediando o acesso ao banco, e o GameServer executando a lógica do mundo. O LogServer é um serviço à parte que recebe eventos enviados pelo GameServer por uma porta TCP dedicada e os persiste. Ele não interfere na jogabilidade: se cair, o jogo continua, mas você para de coletar trilha. Por isso ele precisa ser resiliente, mas nunca deve ser um ponto de bloqueio do GameServer.

O ponto crucial de entendimento é a diferença entre estado e histórico. O banco de dados de produção mostra o estado atual: o inventário do personagem agora, o zen na conta agora. Ele não conta como aquele item chegou ali. O LogServer preenche essa lacuna registrando a sequência de eventos que levou ao estado atual. Sem histórico, você vê o resultado de uma fraude, mas nunca o método.

Quais eventos registrar

Registrar tudo é tentador e errado: gera volume impagável e ruído que atrapalha a investigação. O certo é registrar os eventos de alto valor forense, aqueles que sustentam a maioria das disputas e fraudes.

Além do evento em si, cada registro deve carregar metadados mínimos: timestamp com precisão de segundo ou melhor, ID de conta, nome do personagem, IP de origem, e um identificador de sessão quando o emulador oferecer. Metadado pobre é a causa número um de investigações que travam.

Configurando o LogServer: passo a passo

Os nomes abaixo são exemplos e variam por emulador; a lógica é a mesma em todos.

1. Localize o executável e o arquivo de configuração do LogServer. Costuma ficar em uma pasta própria dentro do diretório do servidor, com um arquivo tipo LogServer.ini ou equivalente.
2. Defina a porta de escuta. Escolha uma porta interna que só o GameServer alcance, por exemplo 55906. Nunca exponha essa porta à internet.
3. Aponte o destino de gravação. Se for banco, informe a string de conexão do banco de logs separado; se for arquivo, defina a pasta de saída e o padrão de nome com data.
4. Ative a gravação assíncrona. Isso garante que o GameServer entregue o evento e siga adiante sem esperar o disco.
5. Configure o GameServer para enviar ao LogServer. No arquivo de configuração do GameServer, aponte o IP e a porta do LogServer e ligue as categorias de log desejadas.
6. Defina o nível de detalhe por categoria. Trade e comandos de GM em detalhe máximo; eventos de altíssimo volume podem ir em nível resumido.
7. Suba o LogServer antes do GameServer. A ordem correta de inicialização evita perda de eventos no boot.
8. Valide com um evento controlado. Faça um trade de teste entre duas contas suas e confirme que ele aparece na trilha com todos os metadados.

Um trecho ilustrativo de configuração (formato varia por emulador):

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

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

E no lado do GameServer, o apontamento correspondente:

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

Estrutura da tabela de logs

Se você optar por banco, uma tabela bem desenhada acelera qualquer investigação. Um esquema de exemplo:

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);

Os índices por tempo, por personagem e por categoria cobrem quase todas as consultas forenses. O campo RawDetail guarda o payload completo do evento em texto, garantindo que nada se perca mesmo que o esquema evolua.

Retenção e rotação

Logs úteis são logs que você ainda tem quando o problema aparece. E problemas aparecem tarde: um jogador reporta um roubo semanas depois. Ao mesmo tempo, guardar tudo para sempre é caro e degrada o desempenho das consultas. A resposta é uma política de retenção em camadas.

Automatize a passagem entre camadas. Um job noturno pode exportar registros com mais de 90 dias para arquivos .csv.gz diários e removê-los da tabela quente. A rotação por tamanho também vale para logs em arquivo: feche e comprima o arquivo atual ao atingir, por exemplo, 200 MB, evitando arquivos monstruosos impossíveis de abrir.

Integridade: logs em que se pode confiar

Um log que pode ser adulterado não serve para banir ninguém. Trate a trilha como prova e proteja sua integridade.

• Conta de banco só de escrita e leitura, nunca de update/delete para o serviço de log. O LogServer nunca deveria precisar apagar um registro.
• Servidor de logs isolado do banco de produção, de preferência em outra máquina ou instância, para que uma invasão ao jogo não comprometa a trilha.
• Horário sincronizado por NTP em todos os nós. Sem isso, correlacionar eventos entre GameServers vira adivinhação.
• Hash encadeado opcional para casos de alta exigência: cada registro guarda o hash do anterior, tornando qualquer remoção detectável.
• Backups da trilha incluídos na rotina geral e testados por restauração.

Investigando fraudes na prática

Aqui os logs deixam de ser um arquivo e viram uma ferramenta. Considere um caso clássico: um jogador reporta que perdeu um Excellent raro após um trade. O roteiro de investigação:

1. Fixe o alvo e a janela. Nome do personagem da vítima e horário aproximado do trade.
2. Puxe a linha do tempo do personagem. Consulte todos os eventos daquele personagem naquele intervalo, ordenados por tempo.
3. Isole o trade. Encontre o evento de trade, veja os dois lados, os itens e a confirmação. Confirme se o item saiu do inventário da vítima.
4. Siga o item. Use o código do item para rastrear onde ele foi parar: quem recebeu, e o que essa conta fez em seguida.
5. Correlacione contas e IPs. Se a conta que recebeu e uma segunda conta compartilham IP ou HWID, você provavelmente encontrou um esquema de multi-conta.
6. Feche a cadeia. Junte login, trade, drop e movimentação posterior em uma narrativa única antes de decidir a sanção.

Uma consulta de linha do tempo de exemplo:

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 duplicação de itens (o mesmo item único aparecendo em dois lugares), procure o mesmo ItemCode de item serializado sendo criado ou recebido por contas diferentes sem um evento de transferência legítimo entre elas. Itens que surgem sem origem rastreável são a assinatura de um exploit.

Detecção proativa

Investigar depois do dano é bom; evitar o dano é melhor. A mesma trilha alimenta alertas automáticos. Rode consultas periódicas em busca de padrões anômalos: ganho de zen acima de um limite por hora, número de trades por minuto muito acima da média, o mesmo item serializado tocando muitas contas em pouco tempo, ou um comando de GM executado por uma conta que não deveria ter esse poder. Um alerta simples que dispara um aviso no Discord da staff transforma o LogServer de arquivo passivo em sensor ativo.

Erros comuns e soluções

Checklist de lançamento

• LogServer sobe antes do GameServer na sequência de boot
• Porta do LogServer é interna e não exposta à internet
• Gravação assíncrona ativada e testada sob carga
• Banco de logs separado do banco de produção
• Índices por tempo, personagem e categoria criados
• Categorias críticas (trade, drop, comando de GM) em detalhe máximo
• Metadados mínimos presentes: horário, conta, personagem, IP
• NTP sincronizado em todos os nós do servidor
• Política de retenção em camadas definida e automatizada
• Rotação por tamanho configurada para logs em arquivo
• Conta de log sem permissão de update ou delete
• Logs incluídos na rotina de backup e restauração testada
• Consulta de linha do tempo validada com um trade de teste
• Alerta automático de anomalias apontado para o canal da staff
• Procedimento de investigação documentado para a equipe de GMs

Com o LogServer bem configurado, você deixa de operar no escuro. Cada disputa vira uma consulta, cada fraude deixa rastro e cada decisão de banimento passa a se apoiar em prova, não em suspeita. Esse é o alicerce de um servidor que os jogadores respeitam porque sabem que as regras são aplicadas com base em fatos.

Perguntas frequentes