Server Monitoring: Tracking Resources, Services and Alerts
How do you monitor a server? What to watch, real-time monitoring with Netdata, external checks with Uptime Kuma, Prometheus and Grafana, alerts and logs.
Server monitoring means continuously tracking your server's CPU, memory, disk and network usage, the state of its services and its availability from outside, and letting you know when something goes wrong. A good monitoring setup lets you notice a problem before the disk fills up, a service crashes or your users complain. With the right tools, a basic monitoring setup takes a few minutes.
This guide covers what you should monitor, real-time monitoring with Netdata, external checks with Uptime Kuma, Prometheus and Grafana, alert thresholds and keeping an eye on logs.
What should you monitor?
| Area | What to monitor? | Why? |
|---|---|---|
| CPU | Usage, load average, steal time | Slowness and overload |
| Memory | Available memory, swap usage | Applications getting killed (OOM) |
| Disk | Usage, inodes, read/write wait | A full disk stops everything |
| Network | Traffic, number of connections, packet loss | Attacks, unexpected traffic |
| Services | Web server, database, game server, queues | Crashed services |
| Availability | Site and ports responding from outside | The real state users see |
| Expiry dates | SSL certificate and domain expiry dates | Outages that are easy to prevent |
We explain how to check each of these metrics by hand in our Why is my server slow? article. Monitoring tools collect the same information continuously, keep its history and notify you when a threshold is crossed.
Two types of monitoring
- Internal monitoring (metrics): A tool running on the server collects resource usage and the state of services. It shows the cause of a problem.
- External monitoring (availability): A tool running somewhere else regularly checks your site or port. It shows the result users see.
The two complement each other. External monitoring tells you "the site isn't responding", and internal monitoring tells you "because the disk is full". Don't run the external monitoring tool on the server you're monitoring; when the server goes down, no notification can be sent either.
Real-time monitoring with Netdata
Netdata is an open-source monitoring tool that starts collecting hundreds of metrics automatically the moment it's installed and offers per-second graphs. It recognizes common services such as web servers, databases and Docker on its own.
After connecting to your server over SSH, run Netdata's official install script:
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh
By default, Netdata opens a web panel on port 19999. Don't expose this panel to the internet; it reveals detailed information about your server. Keep port 19999 closed in the firewall and reach the panel from your own computer through an SSH tunnel:
ssh -L 19999:127.0.0.1:19999 user@203.0.113.10
Then open http://127.0.0.1:19999 in your browser. We cover SSH tunnels in our What is an SSH tunnel? article.
External checks with Uptime Kuma
Uptime Kuma is an open-source tool that checks your websites, ports and services from outside and sends notifications through email, Discord, Telegram and many other channels when something goes wrong. It can track HTTP responses, TCP ports, DNS records and SSL certificate expiry dates.
It installs in a few minutes with Docker; we walk through an example setup in our How to install Docker guide. Run Uptime Kuma on a different server from the one you're monitoring. You can find out what uptime percentages mean in our What is uptime? article.
Prometheus and Grafana
If you want to monitor several servers with long-term data and build your own dashboards, the common solution is the Prometheus and Grafana pair:
- node_exporter: Runs on each server and exposes CPU, memory, disk and network metrics.
- Prometheus: Collects these metrics at regular intervals, stores them and evaluates alert rules.
- Grafana: Visualizes the collected data in dashboards. Ready-made dashboards can be imported in a few clicks.
This setup takes more work than Netdata, but it's very powerful for monitoring many servers from one place and keeping data for months. Open node_exporter's port (9100 by default) only to the Prometheus server; you can use WireGuard to connect the servers to each other securely.
Alert thresholds
The real value of monitoring is alerts that arrive at the right time. A good starting point:
| Alert | Threshold |
|---|---|
| Disk usage | Above 80% |
| Available memory | Below 10% for 10 minutes |
| CPU load | Above the number of cores for 15 minutes |
| Critical service stopped | Immediately |
| Site or port not responding | After 2–3 consecutive failed checks |
| Time left before the SSL certificate expires | Less than 14 days |
Make alerts conditional on a certain period so they don't fire on short spikes. Alerts that come too often and don't need action end up being ignored after a while, and that leads to the really important ones being missed.
Keeping an eye on logs
Metrics tell you there's a problem; logs tell you why:
journalctl -p err -b
journalctl -u nginx --since "1 hour ago"
journalctl -p err -b: Shows all error-level system logs since the last boot.journalctl -u service --since ...: Shows a service's logs after a given time.
To keep log files from filling the disk, check the logrotate settings and the size of the systemd journal; sudo journalctl --vacuum-size=500M cleans up old logs. We cover what to keep an eye on from a security point of view in our Linux server security checklist.
Monitoring on Nodesty servers
With full root access on Nodesty AMD Ryzen 9 9950X VPS and AMD EPYC 7763 VPS plans, you can install Netdata, Prometheus or any monitoring tool you like. Using a second, small server for external checks means you get notified even when your main server goes down. On the infrastructure side, Nodesty offers a 99.95% uptime SLA on all of its services, and L3–L7 nShield DDoS protection filters network-level attacks before they reach your server.
Frequently Asked Questions
Does a small server need monitoring?
Yes. Even on a single server, a full disk, a crashed service or an expired SSL certificate can take down a site or a game server. A simple external check and a few basic alerts let you notice problems before your users do, and setting them up takes a few minutes.
Does a monitoring tool slow the server down?
Tools such as Netdata and the Prometheus node_exporter use few resources and go unnoticed on most servers. On very small servers, you can reduce resource usage even further by lowering the data retention period and the collection frequency.
Should I run the monitoring tool on the same server?
The tool that collects resource metrics runs on the server being monitored. The tool that checks availability and sends alerts, however, should run somewhere else; otherwise, when the server goes down completely, no notification can be sent either.
At what values should I get alerts?
A good starting point is to get an alert when disk usage goes above 80 percent, when available memory stays very low for a long time, when CPU load stays high for minutes, when a critical service stops, when the site doesn't respond and when less than two weeks are left before the SSL certificate expires.
Should I expose the Netdata panel to the internet?
No. Monitoring panels reveal detailed information about your server, and an unprotected panel is a valuable resource for attackers. Keep the panel open only to the server itself and access it through an SSH tunnel, or put it behind a password-protected reverse proxy.
I'm getting alerts too often. What should I do?
Alerts that come too often end up being ignored after a while. To avoid alerts on short spikes, make thresholds conditional on being exceeded for a certain period, turn off alerts that don't really need action and send important alerts to a separate channel.
About the author
Nodesty Team · Infrastructure & Support
The Nodesty team runs our servers, network and DDoS protection day to day and answers customer support requests around the clock. These guides come from that work.
Related articles
Linux Timezone and NTP: A Server Time Setup Guide
How to set the timezone and NTP on a Linux server: timedatectl, UTC or local time, chrony and timesyncd, cron, logs, 2FA codes and Windows Server.
How to Install Ollama: Run AI Models on Your Own Server
How to install Ollama and run AI models on your own server: setup, choosing a model and RAM, using the API, Open WebUI, secure access and CPU usage.
How to Install WordPress with Docker Compose
How to install WordPress with Docker Compose: MariaDB and WordPress containers, passwords in .env, Nginx and SSL, upload limits, backups and updates.