Como montar um dashboard de métricas em tempo real para seu servidor de MU Online

Administrar um servidor de MU Online "no escuro" — sem visibilidade de quantos jogadores estão online agora, se o banco está sob estresse, ou se a economia está inflacionando — é like pilotar sem painel de instrumentos. Um dashboard de métricas em tempo real transforma decisões de operação (quando escalar hardware, quando revisar uma taxa de drop, quando investigar lag) de "achismo" em dado concreto. Este tutorial percorre a construção de um dashboard completo: da coleta de métricas de sistema e de jogo, passando pelo armazenamento em série temporal, até a visualização em painel web e os alertas automáticos.

O que vale a pena medir

Antes de escolher ferramenta, defina o que o dashboard precisa responder. Um conjunto sólido de métricas para servidor de MU cobre três camadas:

Métricas de infraestrutura e de servidor de jogo pedem alta frequência porque mudam rápido; métricas de economia são agregadas e mudam devagar, então coletar a cada minuto já satura a necessidade.

Pré-requisitos

• Servidor de MU já rodando e configurado.
• Acesso ao banco de dados do emulador (MSSQL ou MySQL, conforme o emulador).
• Uma máquina/VM (ou o próprio host) para rodar o stack de monitoramento.
• Conhecimento básico de scripting (PowerShell, Python ou Node.js) para os coletores.

Passo 1 — Escolher o stack de monitoramento

Duas rotas comuns:

• Stack pronta (Prometheus + Grafana): Prometheus coleta e armazena séries temporais; Grafana visualiza. Curva de aprendizado maior, mas extremamente extensível e com alertas nativos.
• Painel próprio leve: um script coletor grava métricas periodicamente em uma tabela SQL, e uma página web simples (PHP/Node) consulta e exibe via gráficos (Chart.js). Mais rápido de montar, menos flexível a longo prazo.

Para servidores pequenos/médios, comece com o painel próprio; migre para Prometheus/Grafana quando o volume de métricas justificar.

Passo 2 — Criar a tabela de séries temporais (rota própria)

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

Essa tabela cresce rápido se coletada a cada poucos segundos — planeje uma rotina de limpeza (ex.: manter granularidade fina por 7 dias e agregar em médias horárias depois).

Passo 3 — Escrever o coletor de infraestrutura

Um coletor simples em PowerShell (Windows) que grava CPU e RAM a 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
}

Rode como serviço/tarefa agendada para garantir que a coleta sobreviva a reinicializações.

Passo 4 — Escrever o coletor de métricas de jogo

Consulte a tabela de contas/personagens conectados do próprio banco do emulador (o nome da coluna/tabela varia por emulador — geralmente algo como MEMB_STAT ou uma flag de conexão em Character):

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

Grave esse valor junto com a economia agregada (soma de Zen, contagem de Excellent dropados na última hora via log de itens, se seu emulador registra esse log).

Passo 5 — Montar a visualização (painel web)

Uma página simples consultando a tabela metrics_snapshot e renderizando com 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) }]
      }
    });
  });

Monte painéis separados para: online ao longo do dia, CPU/RAM, e economia (Zen em circulação, drops de Excellent).

Passo 6 — Adicionar healthcheck e alertas

Configure um script que testa a porta do ConnectServer/GameServer a cada minuto e dispara um webhook para Discord se a checagem falhar 3 vezes seguidas (evitando alerta falso por instabilidade momentânea de rede):

$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 fora do ar!"} | ConvertTo-Json) -ContentType 'application/json'
        }
    } else { $falhas = 0 }
    Start-Sleep -Seconds 60
}

Passo 7 — Monitorar queries lentas do banco

Habilite o log de queries lentas do seu SGBD (slow query log no MySQL, Query Store no SQL Server) e some ao dashboard um painel com as queries mais lentas da última hora. Isso costuma revelar gargalos antes que virem lag perceptível pelos jogadores, especialmente em picos de horário nobre.

Passo 8 — Definir retenção e agregação de dados

Sem uma política de retenção, a tabela de métricas cresce indefinidamente. Um esquema razoável: manter granularidade de 15 segundos por 48h, agregar em médias de 5 minutos por 30 dias, e agregar em médias diárias indefinidamente para análise histórica de longo prazo.

Passo 9 — Restringir acesso a dados sensíveis

Separe o dashboard em duas camadas: uma pública (ou semipública, no site) com métricas agregadas (online total, uptime, season atual) para transparência com a comunidade, e uma administrativa autenticada com detalhes sensíveis (IPs, contas específicas, logs individuais).

Erros comuns e soluções

Checklist de implantação

• Métricas de infraestrutura, jogo e economia definidas e priorizadas.
• Tabela/stack de séries temporais criada com plano de retenção.
• Coletores de sistema e de jogo rodando como serviço persistente.
• Painel de visualização montado com gráficos das métricas-chave.
• Healthcheck com alerta via webhook configurado e testado.
• Monitoramento de queries lentas habilitado no banco.
• Separação entre painel público (agregado) e administrativo (detalhado).

Com o dashboard no ar, você passa a decidir escalonamento de hardware, ajustes de economia e janelas de manutenção com dado real em vez de intuição — o próximo passo é revisar a configuração base do servidor descrita no tutorial de criação de servidor à luz dos números que o dashboard está revelando.

Perguntas frequentes