*Cube-Host– full cloud services!!
*Cube-Host– full cloud services!!
A VPS can feel “stable” right until the day a disk fills up, RAM hits swap, or a database starts choking during peak traffic. Zabbix solves this with one simple idea: collect metrics continuously, visualize trends, and alert you before users notice outages.
This guide is focused on a practical VPS use case: monitoring a Linux/Windows virtual private server (CPU, memory, disk, network, services), setting up meaningful alerts, and securing your monitoring access. If you host projects on Cube-Host, Zabbix is a great companion to keep your VPS hosting environment healthy and scalable.
Zabbix is an open-source monitoring platform used to track servers, networks, websites, databases, virtual machines, and cloud services. On a VPS it can monitor hundreds of parameters in near real time, including:
The goal is not “collect everything”. The goal is to collect the right signals, attach thresholds, and create alerts that lead to action.
Most VPS deployments use three core building blocks. Understanding them makes planning much easier:
| Component | Role | Where it runs | When you need it |
|---|---|---|---|
| Zabbix Server | Central brain: stores data, evaluates triggers, sends alerts | Usually a dedicated Linux VPS | Always (even if you monitor just one host) |
| Zabbix Agent (Agent/Agent2) | Collects OS/app metrics and sends them to the server | On each monitored VPS (Linux or Windows) | Recommended for deep OS monitoring |
| Zabbix Proxy | Collects data locally and forwards it to the server | Remote sites / segmented networks | Useful for many locations or restricted networks |
For a single Cube-Host VPS, a common setup is: Zabbix Server on one VPS + Zabbix Agent on the VPS you monitor. As you grow, you can keep one server and add more hosts (and proxies if needed).
If you only configure one thing, configure these. This set catches most incidents: full disk, memory exhaustion, overload, broken services, and network problems.
/var/www) and configs (/etc) for production serversDefault “high CPU” alerts often produce noise. A better approach is alerting on risk (disk almost full), service down, and performance degradation. Start with the table below and tune based on your baseline.
| Signal | Example trigger | Why it matters | Typical action |
|---|---|---|---|
| Disk free space | < 15% (warning), < 5% (critical) | Full disk breaks databases, logs, updates | Clean logs, extend storage, fix runaway files |
| RAM + swap | Swap usage grows steadily + high iowait | Server becomes slow, may start OOM killing | Optimize app, add RAM, tune PHP-FPM/DB |
| Service availability | HTTP check fails 3 times in a row | Users can’t access the site | Restart service, investigate logs |
| DB latency | Response time above baseline for 5–10 min | Slow site even if it’s “up” | Analyze queries, indexes, disk I/O |
| Network errors | Interface errors/packet loss above baseline | Hidden root cause of timeouts | Check routes, firewall rules, provider status |
Tip: separate alerts into “actionable now” (critical) and “review soon” (warning). This makes Zabbix helpful, not annoying.
You can install Zabbix Server on the same VPS you monitor, but in production it’s usually cleaner to run it separately.
For Cube-Host clients, a simple and scalable pattern is: create a small Linux VPS for Zabbix Server and monitor all other VPS instances from it. When your infrastructure grows, you scale the monitoring VPS or add proxies.
Exact steps depend on your distribution and the Zabbix version, but a correct high-level sequence looks like this:
After installing the agent package, you typically set the server address and hostname. This snippet shows the idea (paths may vary):
# Edit agent config
sudo nano /etc/zabbix/zabbix_agentd.conf
# Typical settings
Server=YOUR_ZABBIX_SERVER_IP
ServerActive=YOUR_ZABBIX_SERVER_IP
Hostname=web-01
# Restart agent
sudo systemctl enable --now zabbix-agent
sudo systemctl restart zabbix-agentFirewall reminder: open only the necessary ports and restrict by IP. Never expose admin panels broadly without access control.
Well-configured alerting is what makes Zabbix a “universal tool” for VPS monitoring:
Zabbix has a web interface, so treat it like any admin system. For production:
If you want the simplest “secure-by-default” approach, use a private tunnel and access Zabbix only through VPN. Cube-Host has a ready option here: VPS VPN.
You can keep the Zabbix Server on Linux (common approach) and install the Zabbix Agent on Windows hosts to monitor CPU, RAM, disk, services, and event logs. If your workload requires Microsoft stack or RDP environments, check VPS Windows and still manage monitoring centrally from the same Zabbix instance.
Once alerts are stable, Zabbix becomes a planning tool: you can see trends and decide when to upgrade CPU/RAM/storage, long before users complain. That’s the difference between “reacting to outages” and running a VPS like a production system.
