Server Monitoring Dashboard

Run the monitoring dashboard on its own machine, not alongside your main workload — if the service dies and monitoring dies with it, the monitoring was pointless.

Two vCPU and 2 GB of RAM with a few Mbps of bandwidth is enough, for roughly US$10–15 a year on an entry plan. Prefer Ubuntu 22.04 or another supported LTS; panels behave best on those.

Three things before anything else:

1. Open ports 22, 80, 443 and the panel port in the cloud console's security group
2. Point a subdomain at this machine (for example monitor.example.com) with an A record
3. SSH in and run the setup script to install the panel

Monitoring is three stages: collect → store → display. This step covers the first two.

Each run of the collector writes these metrics into a JSON file:

• CPU usage and load average (1 / 5 / 15 minutes)
• Memory usage and swap usage
• Disk usage per partition
• Whether key processes are alive (nginx, php-fpm, mysql)
• System uptime

Write it to a fixed path such as /www/wwwroot/monitor.example.com/data/status.json, and the front end can fetch that file and draw the charts.

Why land it in JSON instead of querying a database? Because the front end stays a static page. However you decide to collect later, not a line of front-end code has to change.

Monitoring that nobody looks at is monitoring you didn't do. It has to come find you when something's wrong.

Options, easiest first:

1. A chat bot webhook: create a group with only yourself in it, add a custom bot, take the webhook URL, and POST a JSON from the script. Free and unlimited
2. Your existing chat platform's bot: same idea — take the webhook from the group settings. Cheapest if you already use it
3. Telegram bot: ask BotFather for a token. The best option for servers outside China
4. Email: most panels can do it, but it's the least real-time. Treat it as a fallback

Suggested thresholds:

• CPU above 90% for 5 straight minutes
• Memory usage above 90%
• Disk usage above 85%
• A key process is missing

The one principle that matters: add a silence window. Send the same alert at most once per 10 minutes, or you'll get two hundred messages overnight and switch alerts off entirely.

Once the script works, make it run on its own.

Option 1: the panel's scheduler (best if you're new to this) — scheduled tasks → add task → type "shell script" → period "every N minutes" → 1 → paste the script's absolute path.

Option 2: crontab (lighter) — crontab -e and add:
* * * * * /bin/bash /root/monitor/collect.sh >/dev/null 2>&1

Start on boot — if the collector is a long-running daemon rather than a per-minute script, write a .service file into /etc/systemd/system/ and then run:
systemctl daemon-reload && systemctl enable monitor && systemctl start monitor

Finally, reboot the server to verify: after it comes back, metrics should keep updating without you logging in.

Last step: make the data readable at a glance.

Display layer: a single static HTML page that fetches status.json every 30 seconds with setInterval and renders a few progress bars plus number cards. You don't need a charting library — plain CSS bars are the sturdiest and fastest option.

Colour conventions (don't underestimate these):

• Normal: green
• Warning (above 80%): amber
• Critical (above 90%): red

With that, one glance tells you whether anything is wrong; you never have to read the numbers.

Backup strategy: the monitoring config is small, but rewriting it is annoying.

1. Panel → scheduled tasks → back up the site, weekly
2. Include the script directory /root/monitor/ in the archive
3. Store it in object storage, and keep a local copy as well

Weekly five-minute checklist:

• Is the dashboard still updating?
• Do alerts still arrive? Test one on purpose
• Is disk growth trending oddly?