Ask “what should I use to monitor a Linux server” in any forum and someone will answer “just set up Zabbix”. The advice is not wrong, but it skips the question that actually matters: do you have anyone with spare capacity to operate one more system? This article compares the three common paths honestly, with selection criteria for each situation.

Why is “just run Zabbix” not the answer for everyone?

A self-hosted monitoring stack is itself a system that needs monitoring. It wants its own server, a database for metrics, a backup routine, security patches and version upgrades. And when it goes down, you are completely blind, with nothing left to tell you that it went down.

For a company with a dedicated ops team, that overhead is an acceptable price for full control. For a team of one to three people who write code and babysit infrastructure at the same time, it tends to become the side project that gets abandoned after two weeks. So look at all three options before you commit.

Option 1: self-host Zabbix or Prometheus with Grafana?

This is the most powerful path in features and the heaviest in operational work.

Zabbix is the all-inclusive package: server, web UI, alerting and auto-discovery in one product. You configure it through the interface, and templates exist for almost every popular service. In exchange, the learning curve is real: hosts, items, triggers and actions take time to internalize, and the database balloons quickly unless you tune housekeeping.

Prometheus + Grafana is the cloud-native standard. Prometheus pulls metrics, Grafana draws the dashboards, Alertmanager routes the pages. PromQL is a genuinely powerful query language. In exchange, you assemble at least three components yourself, plus node_exporter on every server, all configured in YAML, and long-term storage needs yet another piece such as Thanos.

A good fit for: teams with at least one person who owns infrastructure, data that must stay inside the private network, fleets of several dozen servers or more, or deeply custom application metrics.

A poor fit for: small teams who only need to know the server is alive, the disk has room and the website responds. Bring a sledgehammer to that job and the sledgehammer becomes the maintenance burden.

Option 2: write your own monitoring scripts?

This path is the cheapest on day one and gets more expensive every month after. A disk check that emails you looks like this:

#!/bin/bash
# /etc/cron.d/check-disk: runs every 5 minutes
USAGE=$(df / --output=pcent | tail -1 | tr -dc '0-9')
if [ "$USAGE" -gt 85 ]; then
  echo "Root disk at ${USAGE}%" | mail -s "[ALERT] $(hostname)" ops@example.com
fi

Fifteen minutes of work, and it genuinely runs. The problems arrive later:

  • No history. You know the disk is at 86 percent, but not since when, or how fast it is climbing.
  • Nobody monitors the monitor. If the server dies, the script dies with it, silently.
  • Alerts repeat forever. The script above emails you every 5 minutes until the problem is fixed. Suppressing duplicates means writing state-tracking code on top.
  • Every new need is a new script. RAM, services, SSL certificates, containers: each one is another file, copied to every server, and one fix must be repeated everywhere.

A good fit for: someone running one or two personal servers, learning how systems work from first principles, or covering one very unusual check that no tool ships out of the box.

Option 3: use a hosted monitoring service with an agent?

This model flips the operational burden. You install a small agent on the server; it reads CPU, RAM, disk, service status and container health, then reports to the provider’s infrastructure. Dashboards, metric history, alerting and status pages are all their problem.

The clearest win is time: from sign-up to first alert is measured in minutes, not afternoons. Because the monitoring lives outside your infrastructure, alerts still go out when your server is down. The trade-offs deserve equal honesty: your metrics sit on third-party infrastructure, features live inside whatever frame the vendor designed, and outgrowing the free tier means a recurring bill.

If you go this route, inspect three things: whether the agent opens ports on your server (it should not), whether alerts arrive on a channel you actually read, and where the free tier ends. As one example, AgentWatch ships a static agent binary for linux amd64 and arm64, sends metrics outbound over HTTPS only, alerts through Zalo and email with Telegram coming soon, and the Free plan covers 2 servers with 10 checks at a 5-minute interval. The agent page explains exactly how it works.

A good fit for: small and mid-sized teams, agencies managing customer servers, and startups that want their hours going into the product instead of the tooling.

How do the three options compare at a glance?

Criteria Zabbix / Prometheus DIY scripts Hosted service with agent
Time to first alert A few sessions to a few days 15-30 minutes per check A few minutes
Money Free software, but a dedicated server Free Free tier, paid beyond it
Ongoing operational time High, permanent Grows with every check Close to zero
History and graphs Full, deeply customizable None by default Included per plan
Keeps working when your server dies Yes, if hosted separately No Yes
Data control Total Total Lives with the provider
Custom exotic metrics Unlimited Unlimited Within the vendor frame

Which path fits your situation?

Three questions settle it quickly:

  1. Does anyone own infrastructure full-time? If not, cross out self-hosting, unless you want to volunteer yourself for the job.
  2. How many servers? Under 10, a hosted plan usually costs less than the dedicated server plus the hours Zabbix eats. Past several dozen, the math starts favoring self-hosting.
  3. Must the data stay inside your network? If a compliance rule says yes, self-hosting is the only option left.

And one pragmatic sequence worth stealing: start with a hosted agent so you have monitoring today, and if your system later grows into real Prometheus territory, build it then, armed with months of knowledge about what you actually need to measure. The worst monitoring setup is the one still half-installed.