How to create a metrics dashboard for a MU server

You cannot manage what you cannot measure. Many MU Online servers are managed in the dark: the admin only finds out the machine is overloaded when players start complaining about lag, or only notices item duplication when the economy has already collapsed. A metrics dashboard solves this by turning the server's state into visible, historical numbers, letting you act before the problem becomes a crisis.

In this tutorial you will build a practical metrics dashboard combining data from three sources: the machine (operating system), the game server process and the MU database. We will use an open, common stack - a time-series collector, a storage layer and a visualization layer - but the concepts apply to any tool. Table and column names vary by season/emulator (Season 6, IGCN, MuEMU, X-Files, etc.), so treat the SQL queries as EXAMPLES and adapt them to your structure.

Prerequisites

Before you start, have at hand:

1. Administrative access to the game server machine.
2. A second machine or small VPS to host the collector and the dashboard (recommended, so it does not compete for resources with the game).
3. Read access to the MU database (create a metrics_ro user with SELECT only).
4. Basic familiarity with SQL and with editing configuration files.
5. Ports opened between the collector and the game machine (only on the internal network or via VPN, never exposed to the internet).

Never use the sa account or the application user to collect metrics. A dedicated read-only user limits the damage if the dashboard credentials leak.

Step 1 - Define what to measure

Before installing any tool, decide which questions the dashboard needs to answer. A common mistake is to collect everything and look at nothing. Split the metrics into four categories:

• Machine health: CPU, memory, disk, network, uptime.
• Game service health: GameServer/ConnectServer processes alive, login latency, queues.
• Player activity: online accounts, characters created, distribution by map.
• Economy and security: circulating zen, excellent items created per hour, resets per hour, login failures.

The economy and security category is the one that most sets an amateur dashboard apart from a professional one, because that is where you detect duplication, bots and intrusions.

Step 2 - Dashboard architecture

The recommended architecture has three components:

1. Collector/exporter: reads metrics from the machine and the database and exposes them in a standardized format.
2. Time-series database: stores the collected points over time.
3. Visualization layer: builds the charts and triggers alerts.

A popular, free set is Prometheus (collection + storage) with Grafana (visualization), plus a node_exporter for machine metrics and a small script that queries the MU database and exposes game metrics. The exact choice is secondary; what matters is separating collection, storage and visualization.

Step 3 - Collect machine metrics

Install a system metrics exporter on the game machine. It exposes CPU, memory, disk and network on an endpoint that the collector reads periodically. On the collector side, configure a target pointing to that endpoint, accessible only from the internal network:

scrape_configs:
  - job_name: 'mu-maquina'
    scrape_interval: 15s
    static_configs:
      - targets: ['10.0.0.5:9100']  # internal IP of the game machine

With this you already get CPU and memory usage charts. Set alerts for sustained usage above 85% CPU or 90% disk, which are the most common bottlenecks on MU servers during an event.

Step 4 - Collect game database metrics

This is the heart of the dashboard. Write a small exporter that runs periodic SQL queries with the metrics_ro user and publishes the results as metrics. Query examples (adapt the table names):

-- Accounts currently online
SELECT COUNT(*) AS online FROM MEMB_STAT WHERE ConnectStat = 1;

-- Total zen in circulation (sum across characters)
SELECT SUM(CAST(Money AS BIGINT)) AS zen_total FROM Character;

-- Resets performed in the last 24h (if there is a log column)
SELECT COUNT(*) AS resets_24h
FROM ResetLog
WHERE ResetDate >= DATEADD(HOUR, -24, GETDATE());

Publish each result as a named metric (for example, mu_online_accounts, mu_zen_total, mu_resets_24h). Run the game queries every 1-5 minutes; heavy queries running every second hurt game performance. Always use indexes and avoid SELECT * on large tables.

Step 5 - Build the visual dashboards

On the visualization layer, create thematic dashboards. A good starting set:

1. Overview: online players, uptime, CPU and memory on a single screen.
2. Economy: total zen, zen created per hour, excellent items generated per hour.
3. Security: login failures per minute, accounts created per IP, GM commands used.
4. Infrastructure: disk, network, database latency.

Use line charts for trends and instant values (single stat) for the current state. Mark thresholds with colors: green for normal, yellow for warning, red for critical.

Step 6 - Configure alerts

A dashboard nobody looks at prevents nothing. Configure alerts that push the information to you (email, Discord webhook, Telegram). Examples of useful rules:

• CPU above 90% for more than 5 minutes.
• GameServer process absent (online dropped to zero abruptly).
• Total zen growing more than X% in one hour (possible duplication).
• More than N login failures per minute coming from the same IP (brute force).
• Disk with less than 10% free.

Table of essential metrics

Table of alert thresholds (example)

The numbers above are an EXAMPLE starting point and vary by season/emulator, community size and time of day. Adjust the thresholds after observing your server's normal behavior for a few days.

Common errors and fixes

Operational best practices

Document the meaning of each dashboard so any team member understands an alert at 3 a.m. Back up the dashboard definitions along with the rest of the server. Review the thresholds monthly, because the player base and events change what is normal. And treat the security dashboard as seriously as the technical one: many intrusions and duplications are detectable through anomalies in the economy metrics before any player report.

Launch checklist

• Metric categories defined (machine, service, players, economy)
• metrics_ro read-only user created
• Collector and dashboard running on a separate machine
• Machine exporter installed and collecting
• Game SQL queries validated and indexed
• Overview, economy, security and infrastructure dashboards built
• CPU, disk, online, zen and login-failure alerts configured
• Alerts sent via a push channel (Discord/Telegram/email)
• Thresholds calibrated to the observed normal behavior
• Adequate history retention with backup
• Metrics endpoints closed to the internet
• Dashboard documentation shared with the team

With the dashboard live, you stop managing in the dark and start anticipating performance, economy and security problems. If you are still structuring the server, the how to create a MU Online server guide helps you build the foundation the monitoring will run on. A good dashboard is not a luxury: it is the difference between reacting to fires and preventing them.

Frequently asked questions