Server Monitoring with Prometheus and Grafana: From Metric to Alert
node_exporter collects CPU, memory, disk, and network, Prometheus stores them as time series, and Grafana visualizes and alerts. Here is how to build a useful dashboard and set an alert that reaches you before the disk fills or memory runs out.
Monitoring a server with Prometheus and Grafana rests on three clear roles: a collector such as node_exporter reads system metrics from CPU, memory, disk, and network and exposes them on an internal port, Prometheus scrapes those metrics every few seconds and stores them as time series with timestamps, and Grafana connects to Prometheus to draw dashboards and fire alerts when a threshold is crossed. The core idea is that everything becomes a number over time, so you see the trend rather than only the moment, and an alert reaches you before a problem turns into an outage.
The practical minimum for any production server: install node_exporter on the monitored machine, run Prometheus to scrape it every 15 seconds, add Grafana as the front end, then build a dashboard showing CPU use, memory percentage, remaining disk, network traffic, and load average. After that, set at least two alert rules: disk nearing full, and memory nearing exhaustion. That alone prevents the most common causes of sudden downtime. The rest of this guide explains each component and its role, how to build a dashboard you read at a glance, and how to craft an alert that arrives on time rather than late.
The three roles: who collects, who stores, who shows
Many people blur the components together, so separating them clarifies the picture. node_exporter is a small program running on the server you want to watch. It reads system state from the Linux kernel and presents it as text numbers on an internal HTTP port. It stores nothing and draws nothing, it only reveals the current moment on request.
Prometheus is the engine: a time-series database that scrapes metrics from each collector at regular intervals, stores them with timestamps, and offers a powerful query language called PromQL for computing rates, differences, and aggregations. It is the source of truth for numbers over time. Grafana is the visual layer: it connects to Prometheus as a data source, draws the panels, and manages alerts and delivery channels such as email or Slack. This separation makes each part replaceable and keeps the system flexible.
What node_exporter actually measures
node_exporter exposes hundreds of metrics, but only a few are what you look at daily. The most important are these:
| Metric | What it tells you | When to worry |
|---|---|---|
| CPU use | How busy the vCPU is | Steady above 85% for a long stretch |
| Memory used | How much RAM is actually occupied | Nearing the ceiling as swap kicks in |
| Disk space | Free room on each partition | Less than 15% remaining |
| Load average | Length of the waiting process queue | Persistently above the core count |
| Network traffic | Bytes in and out | Sudden spikes or saturating the cap |
| Disk I/O | Read and write pressure | Long waits that slow everything |
Memory and disk are the silent killers. A full disk stops the database from writing all at once, and exhausted memory pushes the system to kill processes. CPU, by contrast, tolerates brief peaks, so the danger from it is sustained high load, not a momentary spike. That is why you watch memory and disk as strict thresholds and watch CPU as a trend.
Building a dashboard you read at a glance
A useful dashboard is not the one with the most graphs, it is the clearest. Put a top row of four big single numbers: CPU percentage, memory percentage, remaining disk, and load average. That is a one-second health glance. Below it, place time graphs for each metric over the last few hours, because the trend reveals what the moment hides: whether memory is slowly leaking upward, or the disk is filling at a steady rate that predicts a full disk in days.
In Grafana each panel is built from a PromQL query. For example, remaining disk percentage is computed from the free-space metric over total capacity, and memory percentage from used over available. Save the dashboard, set it to refresh every 30 seconds, and default the view to the last 6 hours with the option to widen. This dashboard becomes your first screen every morning. Whether you run a single server or a small fleet on Cloud's cloud server, one dashboard with a variable that selects the server is enough to watch them all.
From metric to alert
A pretty graph is useless if you are not looking at it the moment things break. The real value of monitoring is the alert that reaches you before the disaster. Grafana and Prometheus both support alert rules that fire when a metric crosses a threshold for a set duration. The duration matters: you do not want an alert on a two-second CPU spike, you want one on sustained load above 90% for five minutes, for instance.
Start with three rules that cover most cases:
- Disk filling: free space below 15% for more than 10 minutes. This gives you time to clean up before it stops.
- Memory on the edge: used above 90% with swap starting to engage. An early sign of a needed upgrade or a memory leak.
- Server unresponsive: Prometheus stops getting metrics from the collector for over two minutes. This may mean the machine itself went down.
Wire these alerts to a channel you actually watch: Slack, a monitored inbox, or a message. An alert in a place you never see may as well not exist.
The right server size for monitoring
Prometheus and Grafana are relatively light for a small fleet, since the time-series database writes constantly but the data volume stays reasonable unless you monitor hundreds of machines. For a central monitoring box serving a handful of servers, a Numuw plan with two vCPUs and 4GB of RAM comfortably runs Prometheus and Grafana together, with enough disk to keep as much metric history as you want. Longer retention needs more space, so balance history depth against available disk. Per-plan resources are on the pricing page.
If you run AI tools or many services with variable resource use, monitoring becomes more important, not less, because it reveals which service is eating memory. Hosting tuned for those workloads is on AI hosting, with ready templates that cut the setup short.
Rollout plan
Execute in this order: install node_exporter on every server you want to watch, run Prometheus on the monitoring box and set it to scrape each collector every 15 seconds, and add Grafana connected to Prometheus as a data source. Then build the dashboard with four top numbers and time graphs, and set the three alert rules wired to a channel you see. Test the alert by forcing a condition, such as temporarily filling the disk with a file, to confirm the warning actually arrives. Monitoring whose alerts were never tested is not monitoring, it is a false sense of safety.
