Como criar um painel de métricas do servidor de MU

Você não pode administrar o que não consegue medir. Muitos servidores de MU Online são gerenciados no escuro: o admin só descobre que a máquina está sobrecarregada quando os jogadores começam a reclamar de lag, ou só percebe uma duplicação de itens quando a economia já colapsou. Um painel de métricas resolve isso transformando o estado do servidor em números visíveis e históricos, permitindo agir antes que o problema vire crise.

Neste tutorial você vai montar um painel de métricas prático combinando dados de três fontes: a máquina (sistema operacional), o processo do servidor de jogo e o banco de dados do MU. Vamos usar uma stack aberta e comum — um coletor de séries temporais, um armazenamento e uma camada de visualização — mas os conceitos se aplicam a qualquer ferramenta. Os nomes de tabelas e colunas variam por season/emulador (Season 6, IGCN, MuEMU, X-Files etc.), então trate as consultas SQL como EXEMPLO e adapte à sua estrutura.

Pré-requisitos

Antes de começar, tenha em mãos:

1. Acesso administrativo à máquina do servidor de jogo.
2. Uma segunda máquina ou VPS pequena para hospedar o coletor e o painel (recomendado, para não competir por recursos com o jogo).
3. Acesso de leitura ao banco de dados do MU (crie um usuário metrics_ro só com SELECT).
4. Familiaridade básica com SQL e com edição de arquivos de configuração.
5. Portas liberadas entre o coletor e a máquina do jogo (apenas na rede interna ou via VPN, nunca expostas à internet).

Nunca use a conta sa ou o usuário da aplicação para coletar métricas. Um usuário somente leitura dedicado limita o dano caso as credenciais do painel vazem.

Passo 1 — Definir o que medir

Antes de instalar qualquer ferramenta, decida quais perguntas o painel precisa responder. Um erro comum é coletar tudo e não olhar nada. Divida as métricas em quatro categorias:

• Saúde da máquina: CPU, memória, disco, rede, uptime.
• Saúde do serviço de jogo: processos do GameServer/ConnectServer vivos, latência de login, filas.
• Atividade dos jogadores: contas online, personagens criados, distribuição por mapa.
• Economia e segurança: zen em circulação, itens excellent criados por hora, resets por hora, falhas de login.

A categoria de economia e segurança é a que mais diferencia um painel amador de um profissional, porque é ali que você detecta duplicação, bots e invasões.

Passo 2 — Arquitetura do painel

A arquitetura recomendada tem três componentes:

1. Coletor/exportador: lê métricas da máquina e do banco e as expõe em um formato padronizado.
2. Banco de séries temporais: armazena os pontos coletados ao longo do tempo.
3. Camada de visualização: monta os gráficos e dispara alertas.

Um conjunto popular e gratuito é Prometheus (coleta + armazenamento) com Grafana (visualização), mais um node_exporter para métricas de máquina e um pequeno script que consulta o banco do MU e expõe métricas de jogo. A escolha exata é secundária; o importante é separar coleta, armazenamento e visualização.

Passo 3 — Coletar métricas de máquina

Instale um exportador de métricas de sistema na máquina do jogo. Ele expõe CPU, memória, disco e rede em um endpoint que o coletor lê periodicamente. No lado do coletor, configure um alvo apontando para esse endpoint, acessível apenas pela rede interna:

scrape_configs:
  - job_name: 'mu-maquina'
    scrape_interval: 15s
    static_configs:
      - targets: ['10.0.0.5:9100']  # IP interno da máquina do jogo

Com isso você já consegue gráficos de uso de CPU e memória. Defina alertas para uso sustentado acima de 85% de CPU ou de 90% de disco, que são os gargalos mais comuns em servidores de MU sob evento.

Passo 4 — Coletar métricas do banco de jogo

Aqui está o coração do painel. Escreva um pequeno exportador que roda consultas SQL periódicas com o usuário metrics_ro e publica os resultados como métricas. Exemplos de consultas (adapte nomes de tabelas):

-- Contas atualmente online
SELECT COUNT(*) AS online FROM MEMB_STAT WHERE ConnectStat = 1;

-- Zen total em circulação (soma dos personagens)
SELECT SUM(CAST(Money AS BIGINT)) AS zen_total FROM Character;

-- Resets realizados nas últimas 24h (se houver coluna de log)
SELECT COUNT(*) AS resets_24h
FROM ResetLog
WHERE ResetDate >= DATEADD(HOUR, -24, GETDATE());

Publique cada resultado como uma métrica nomeada (por exemplo, mu_online_accounts, mu_zen_total, mu_resets_24h). Rode as consultas de jogo a cada 1-5 minutos; consultas pesadas rodando a cada segundo prejudicam o desempenho do jogo. Sempre use índices e evite SELECT * em tabelas grandes.

Passo 5 — Montar os painéis visuais

Na camada de visualização, crie dashboards temáticos. Um bom conjunto inicial:

1. Visão geral: jogadores online, uptime, CPU e memória em uma tela única.
2. Economia: zen total, zen criado por hora, itens excellent gerados por hora.
3. Segurança: falhas de login por minuto, contas criadas por IP, comandos de GM usados.
4. Infraestrutura: disco, rede, latência de banco.

Use gráficos de linha para tendências e valores instantâneos (single stat) para o estado atual. Marque limiares com cores: verde no normal, amarelo no atenção, vermelho no crítico.

Passo 6 — Configurar alertas

Um painel que ninguém olha não previne nada. Configure alertas que empurram a informação para você (e-mail, Discord webhook, Telegram). Exemplos de regras úteis:

• CPU acima de 90% por mais de 5 minutos.
• Processo do GameServer ausente (online caiu para zero abruptamente).
• Zen total crescendo mais de X% em uma hora (possível duplicação).
• Mais de N falhas de login por minuto vindas do mesmo IP (força bruta).
• Disco com menos de 10% livre.

Tabela de métricas essenciais

Tabela de limiares de alerta (exemplo)

Os números acima são um EXEMPLO de ponto de partida e variam por season/emulador, tamanho da comunidade e horário. Ajuste os limiares depois de observar o comportamento normal do seu servidor por alguns dias.

Erros comuns e soluções

Boas práticas de operação

Documente o significado de cada painel para que qualquer membro da equipe entenda um alerta às 3h da manhã. Faça backup das definições dos dashboards junto com o resto do servidor. Revise os limiares mensalmente, porque a base de jogadores e os eventos mudam o que é normal. E trate o painel de segurança com a mesma seriedade do painel técnico: muitas invasões e duplicações são detectáveis por anomalias nas métricas de economia antes de qualquer denúncia de jogador.

Checklist de lançamento

• Categorias de métricas definidas (máquina, serviço, jogadores, economia)
• Usuário metrics_ro somente leitura criado
• Coletor e painel rodando em máquina separada
• Exportador de máquina instalado e coletando
• Consultas SQL de jogo validadas e indexadas
• Dashboards de visão geral, economia, segurança e infraestrutura montados
• Alertas de CPU, disco, online, zen e falhas de login configurados
• Alertas enviados por canal de push (Discord/Telegram/e-mail)
• Limiares calibrados com o comportamento normal observado
• Retenção de histórico adequada e com backup
• Endpoints de métricas fechados para a internet
• Documentação dos painéis compartilhada com a equipe

Com o painel no ar, você deixa de administrar no escuro e passa a antecipar problemas de desempenho, economia e segurança. Se você ainda está estruturando o servidor, o guia de como criar servidor de MU Online ajuda a montar a base sobre a qual o monitoramento vai rodar. Um bom painel não é luxo: é a diferença entre reagir a incêndios e preveni-los.

Perguntas frequentes