Como Configurar Alertas de Queda (Uptime Monitor) no MU Online

O pior cenário para um administrador de MU Online não é o servidor cair — é o servidor cair e você só descobrir horas depois, pelo print raivoso de um jogador no Discord. Cada minuto offline sem você saber é reputação e retenção evaporando. Um monitor de uptime resolve exatamente isso: um vigia automático que testa, de fora, se o seu servidor está aceitando conexões e, no instante em que algo falha, avisa você por Discord, Telegram ou e-mail. Este tutorial mostra como montar esse sistema testando as portas certas do MU (não apenas se a máquina está ligada), evitando alarmes falsos e criando uma página de status para a comunidade. As ferramentas, planos e valores citados são exemplo e variam por provedor/versão; o conceito é o que você vai levar.

Pré-requisitos

• Servidor de MU já publicado e acessível pela internet (se ainda está montando, veja como criar servidor de MU Online).
• IP público ou domínio do servidor e as portas que os jogadores usam.
• Um segundo ponto para hospedar o monitor: um VPS barato separado, um serviço de monitoramento externo ou até um Raspberry/PC ligado 24h — o importante é ser independente da máquina monitorada.
• Um canal de alerta pronto: um webhook de Discord, um bot de Telegram ou uma conta de e-mail SMTP.
• Lista dos serviços críticos a vigiar: ConnectServer, GameServer(s), banco de dados e site.

Passo 1 — Saiba exatamente o que monitorar

Monitorar "o servidor" é vago. O jogador não se conecta a uma máquina, ele se conecta a portas de serviços. E cada serviço caído tem um efeito diferente. Mapear isso é o primeiro passo.

As portas exatas variam por versão e configuração. Como exemplo comum em servidores S6, o ConnectServer costuma responder em uma porta TCP conhecida e cada GameServer em outra faixa. O que importa é: descubra as suas portas reais nos arquivos de configuração e monitore cada uma. Um monitor que só checa se o IP responde a ping não detecta um GameServer travado com a máquina ligada — e é justamente esse o caso mais frustrante.

Passo 2 — Escolha onde o monitor vai rodar

A regra de ouro: monitore de fora. Se o monitor roda dentro do próprio VPS do jogo e a máquina inteira cai ou perde rede, o monitor cai junto e nunca dispara o alerta. Você tem três abordagens, do mais simples ao mais completo:

1. Serviço externo de monitoramento: cadastra o IP e a porta em uma plataforma na nuvem que checa de vários pontos do mundo. Rápido de montar; planos gratuitos costumam bastar para começar (varia por provedor).
2. Monitor open-source no seu próprio VPS barato: você hospeda a ferramenta em uma segunda máquina, mantendo controle total e sem custo de licença.
3. Script próprio: um script leve que testa a porta e dispara um webhook — máxima flexibilidade, útil para checagens específicas do MU.

O ideal maduro combina o item 1 ou 2 (alerta principal, externo) com o item 3 (checagens internas de processo). Comece simples e evolua.

Passo 3 — Testar a porta certa (não só o ping)

O coração do monitor é o teste de porta TCP. Ele confirma que o serviço aceita conexão, que é o que o cliente do jogo precisa. Um script em PowerShell ilustra o conceito e já serve como monitor caseiro no Windows:

# monitor-porta.ps1 — testa a porta do ConnectServer e alerta no Discord
$alvo    = "SEU.IP.DO.SERVIDOR"
$porta   = 44405      # EXEMPLO: use a porta real do seu ConnectServer
$webhook = "https://discord.com/api/webhooks/SEU/WEBHOOK"

$ok = Test-NetConnection -ComputerName $alvo -Port $porta -InformationLevel Quiet

if (-not $ok) {
    $corpo = @{ content = "🔴 ALERTA: $alvo:$porta NAO responde em $(Get-Date -Format 'HH:mm:ss')" } | ConvertTo-Json
    Invoke-RestMethod -Uri $webhook -Method Post -Body $corpo -ContentType 'application/json'
}

Em Linux, o mesmo teste de porta é trivial com nc (netcat):

# retorna sucesso se a porta aceitar conexao
nc -z -w 3 SEU.IP.DO.SERVIDOR 44405 && echo "UP" || echo "DOWN"

Para o site, o teste é HTTP: além da porta abrir, o servidor deve responder um código de sucesso (200). Um curl -sf https://seudominio.com/ que falha é sinal de site fora do ar mesmo com a porta 80/443 aberta.

Passo 4 — Evitar alarmes falsos

Um monitor que grita a cada oscilação de rede vira ruído, e ruído a gente aprende a ignorar — aí, quando a queda é real, ninguém liga. Três técnicas domam os falsos positivos:

• Confirmação por repetição: só alerte após 2 ou 3 checagens seguidas com falha. Uma perda isolada de um pacote não derruba o servidor de verdade.
• Intervalo sensato: checar a cada 30-60 segundos detecta rápido sem exagerar no tráfego. Intervalos curtíssimos aumentam o ruído.
• Janela de manutenção: ao reiniciar o servidor de propósito, silencie os alertas naquele intervalo para não se assustar com a própria manutenção.

Um exemplo de confirmação por repetição, incrementando um contador antes de alertar:

# so alerta na 3a falha consecutiva
$falhas = 0
foreach ($tentativa in 1..3) {
    if (Test-NetConnection $alvo -Port $porta -InformationLevel Quiet) { $falhas = 0; break }
    $falhas++
    Start-Sleep -Seconds 5
}
if ($falhas -ge 3) { <# dispara o alerta aqui #> }

Passo 5 — Configurar os canais de alerta

O alerta só serve se chegar até você onde você olha. Os três canais mais usados por servidores de MU:

Discord (webhook): o mais popular, pois a comunidade já vive no Discord. Crie um webhook em um canal privado da staff (Configurações do canal → Integrações → Webhooks) e use a URL como no script acima. Simples e instantâneo.

Telegram (bot): ótimo para alerta no celular. Crie um bot com o BotFather, pegue o token e o chat id, e dispare a mensagem:

curl -s "https://api.telegram.org/botSEU_TOKEN/sendMessage" \
  -d chat_id=SEU_CHAT_ID \
  -d text="🔴 GameServer fora do ar as $(date +%H:%M)"

E-mail (SMTP): bom como canal secundário/redundante. Use uma senha de aplicativo do provedor de e-mail, nunca a senha principal da conta.

O recomendado é ter pelo menos dois canais: se o Discord estiver com problema justo na hora da queda, o Telegram ou o e-mail garante que a notificação chega.

Passo 6 — Agendar a checagem contínua

O monitor precisa rodar sozinho, para sempre. No Windows, agende o script no Agendador de Tarefas com um disparador repetido:

1. Abra taskschd.msc e crie uma tarefa.
2. Disparador: ao iniciar o sistema, repetindo a cada 1 minuto indefinidamente.
3. Ação: powershell.exe -NonInteractive -ExecutionPolicy Bypass -File "C:\Monitor\monitor-porta.ps1".
4. Marque "Executar mesmo se o usuário não estiver conectado".

Em Linux, o cron cobre até o intervalo de minuto; para checagens mais frequentes, um serviço systemd em loop com sleep é o padrão. Se estiver usando uma ferramenta open-source de uptime, ela já gerencia o agendamento internamente — você só cadastra o alvo, a porta e o intervalo pela interface.

Passo 7 — Página de status para a comunidade

Além de alertar você, um bom sistema comunica os jogadores. Uma página de status pública que mostra "Online / Offline" de cada serviço reduz drasticamente o volume de perguntas no chat durante uma queda e passa profissionalismo. Ferramentas open-source de monitoramento já geram essa página automaticamente; você escolhe o que expor:

• Status de cada GameServer e do ConnectServer.
• Uptime dos últimos 30/90 dias em percentual.
• Histórico de incidentes com horário de início e resolução.

Uma comunidade que vê "estamos cientes, serviço em manutenção" no status espera; uma comunidade sem informação assume abandono e migra. A página de status é tão parte do monitoramento quanto o alerta.

Erros comuns e soluções

Checklist de lançamento

• Portas reais de ConnectServer e GameServer identificadas nos arquivos de config
• Monitor testando porta TCP, não apenas ping
• Monitor rodando de um ponto externo e independente do VPS do jogo
• Site testado por HTTP (código 200), não só porta aberta
• Confirmação por repetição (2-3 falhas) ativa contra falso positivo
• Intervalo de checagem entre 30 e 60 segundos
• Pelo menos dois canais de alerta configurados (ex: Discord + Telegram)
• Janela de manutenção para silenciar alertas em reinícios planejados
• Checagem agendada rodando 24h automaticamente
• Página de status pública para a comunidade

Com um monitor de uptime bem montado, a queda deixa de ser uma surpresa vergonhosa e vira um incidente que você já está resolvendo antes do primeiro jogador reclamar. Testando a porta certa, de fora, com alertas redundantes e sem alarme falso, você transforma tempo offline em minutos de reação — e é essa velocidade que separa um servidor amador de um projeto que a comunidade confia.

Perguntas frequentes