How to Monitor Your MU Online Server: Alerts and Diagnostics

Why Monitoring Matters for MU Online Servers

Running a MU Online private server is more than launching executables and hoping for the best. The moment real players connect, the system becomes a live environment where crashes, lag spikes, and database errors translate directly into lost trust and player churn. A structured monitoring setup gives you visibility into what the server is doing before problems escalate into outages.

This guide covers the core areas of server health: process state, resource usage, network metrics, database performance, and log analysis. By the end you will have a monitoring strategy that surfaces issues early and delivers alerts through channels you actually check.

Understanding the Core Processes to Watch

A standard MU Online server stack consists of several interdependent processes. Each one can fail independently, so your monitoring must cover all of them:

• ConnectServer — handles initial client connections and routes players to the correct GameServer instance
• GameServer — the main simulation process, one instance per game world
• DataServer — manages character data reads and writes, bridging GameServer and the SQL database
• JoinServer (some builds) — manages account authentication before the GameServer handshake
• SQL Server / MySQL — the relational database storing all persistent player and world data

The failure mode of each process is different. ConnectServer tends to crash silently under malformed packet floods. GameServer leaks memory over time. DataServer becomes a bottleneck when query latency rises. Treating them as a single monolithic "server" is the most common mistake new administrators make.

Setting Up Process and Resource Monitoring

Automated Process Health Checks

A simple PowerShell script run on a Windows Task Scheduler interval of 60 seconds can detect and restart a crashed process:

# MU Server Process Watchdog
# → Runs every 60 seconds via Task Scheduler
# → Restarts dead processes and logs the event

$processes = @{
    "ConnectServer" → "C:\MUServer\ConnectServer\ConnectServer.exe"
    "GameServer"    → "C:\MUServer\GameServer\GameServer.exe"
    "DataServer"    → "C:\MUServer\DataServer\DataServer.exe"
}

$logFile = "C:\MUServer\Logs\watchdog.log"
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

foreach ($name in $processes.Keys) {
    $running = Get-Process -Name $name -ErrorAction SilentlyContinue
    if (-not $running) {
        $entry = "$timestamp → ALERT: $name not found, restarting"
        Add-Content -Path $logFile -Value $entry
        Start-Process -FilePath $processes[$name] -WorkingDirectory (Split-Path $processes[$name])
        # → Optional: send alert via webhook here
    }
}

# → Resource thresholds
$cpuLoad    = (Get-WmiObject Win32_Processor | Measure-Object -Property LoadPercentage -Average).Average
$ramUsedPct = (Get-WmiObject Win32_OperatingSystem | ForEach-Object {
    [math]::Round((($_.TotalVisibleMemorySize - $_.FreePhysicalMemory) / $_.TotalVisibleMemorySize) * 100, 1)
})

if ($cpuLoad -gt 85) {
    Add-Content -Path $logFile -Value "$timestamp → WARNING: CPU at $cpuLoad%"
}
if ($ramUsedPct -gt 80) {
    Add-Content -Path $logFile -Value "$timestamp → WARNING: RAM at $ramUsedPct%"
}

> [!TIP] > Keep a separate log file for each monitored concern: one for process restarts, one for resource thresholds, and one for database health. Mixing everything into a single file makes pattern analysis much harder when you are debugging an incident at 3 AM.

Disk I/O and Storage Alerts

Database servers are especially sensitive to disk saturation. Monitor disk usage on the volume containing your SQL data files and set a hard alert at 85% capacity. At 90%, the SQL engine may begin refusing writes, which causes DataServer to log errors and GameServer to stop saving character data — meaning players lose progress silently.

Check remaining disk space with a scheduled task that appends to a log:

# → Disk space check, run every 15 minutes
$drive = "C:"
$disk  = Get-PSDrive -Name ($drive.TrimEnd(':'))
$usedPct = [math]::Round(($disk.Used / ($disk.Used + $disk.Free)) * 100, 1)
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

if ($usedPct -gt 85) {
    Add-Content "C:\MUServer\Logs\disk.log" `
        "$timestamp → ALERT: Drive $drive at $usedPct% capacity"
}

Database Performance Diagnostics

Identifying Slow Queries

Enable slow query logging in SQL Server or MySQL. Any query taking longer than 1 second during normal operation is a candidate for optimization. The most common offenders in MU server databases are:

• Character inventory reads without an index on AccountID or CharacterName
• Guild ranking queries doing full table scans
• Log table inserts that have grown to tens of millions of rows with no partitioning

In MySQL, add this to my.cnf to capture slow queries:

# → MySQL slow query log configuration
slow_query_log         = 1
slow_query_log_file    = /var/log/mysql/slow.log
long_query_time        = 1          # → threshold in seconds
log_queries_not_using_indexes = 1   # → catch unindexed queries
min_examined_row_limit = 100        # → ignore trivially small scans

Review the slow query log weekly. Recurring slow queries should be addressed with index additions or query rewrites before they become a player-visible problem.

> [!WARNING] > Never run diagnostic queries like SHOW PROCESSLIST or SELECT ... FROM information_schema during peak hours on a heavily loaded server. These operations can acquire metadata locks that stall player data writes for several seconds, causing visible lag for every player currently in a save cycle.

Connection Pool Monitoring

Set up a dedicated monitoring user in your database with read-only access to performance tables. Poll the active connection count every 30 seconds and log spikes. In MySQL:

-- → Run as monitoring user, read-only
SELECT COUNT(*)          AS active_connections,
       MAX(TIME)         AS longest_query_seconds,
       SUM(TIME > 5)     AS queries_over_5s
FROM   information_schema.PROCESSLIST
WHERE  COMMAND != 'Sleep';

If queries_over_5s is consistently above zero outside of maintenance windows, you have an active performance problem that needs investigation before it cascades.

Log Analysis and Alerting Strategy

Structuring Your Log Review

MU Online server logs are verbose. Reading them manually is not practical. Instead, establish a set of pattern triggers — strings that should never appear in healthy logs:

Write a script that scans the last 100 lines of each log file on a 5-minute interval and alerts if any pattern is matched. Pipe results to a webhook (Discord, Telegram, or a self-hosted alerting service) so you receive notifications without polling the server manually.

> [!WARNING] > Do not expose your server logs to a public endpoint for convenience. Logs frequently contain internal IP addresses, player account names, and session tokens. Keep log access restricted to the local machine and your administrative VPN or secure tunnel.

Establishing a Baseline

Before you can recognize anomalous behavior, you need to know what normal looks like. Spend two weeks after a fresh server launch collecting:

• Average CPU usage by hour of day
• Average RAM consumption per GameServer instance per 100 players
• Average database query count per minute
• Typical disk write rate during peak hours

Document these baselines. When an alert fires at 3 AM, the baseline is what tells you whether the spike is genuinely alarming or just a side effect of a scheduled event.

Building an Alert Escalation Ladder

Not every alert needs to wake you up. Structure your responses in tiers:

1. Info — logged only, no notification (CPU 60-75%, normal log patterns)
2. Warning — logged and sent to a low-priority channel (CPU 75-85%, RAM 70-80%)
3. Critical — logged and sent to a high-priority notification (process crash, CPU above 90% sustained, database errors)
4. Emergency — logged, high-priority notification, and automatic restart attempt (process absent for two consecutive checks)

This tiered model prevents alert fatigue. If every threshold fires a loud notification, administrators start ignoring them — which is worse than having no alerts at all.

Summary

Effective MU Online server monitoring rests on three pillars: knowing which processes must stay alive and checking them automatically, tracking resource usage against documented baselines, and analyzing logs for error patterns rather than reading them line by line. With the watchdog script, disk and database checks, and a tiered alert ladder in place, you shift from reactive firefighting to proactive administration. Your players experience fewer outages, and you spend less time in crisis mode.

Perguntas frequentes