Monitoring Linux Servers with Prometheus and Node Exporter

A server without monitoring only tells you it is down when someone complains. With Node Exporter, each host exposes Linux metrics; Prometheus collects and stores them as time series for queries and alerts. This walkthrough uses Ubuntu packages where available, avoids exposing metrics to the internet, and validates each step before moving on.

The design: who collects and who exposes

Node Exporter listens on the monitored host, usually on port 9100. Prometheus, on the central server, performs the scrape over HTTP at regular intervals; it does not receive pushed metrics in this scenario. For a few servers, static_configs is the canonical way to declare targets. As the fleet grows, prefer service discovery or target files instead of editing the main configuration for every machine.

Install Node Exporter through Ubuntu

On Ubuntu, the distribution package integrates the service, user, and security updates. This avoids downloading a fixed-version binary and forgetting about it later. On each monitored server:

sudo apt update
sudo apt install -y prometheus-node-exporter
sudo systemctl enable --now prometheus-node-exporter
sudo systemctl status prometheus-node-exporter --no-pager
curl -fsS http://localhost:9100/metrics | head

If you need the upstream binary for a specific feature, check the architecture, signature/checksum, and version on the official releases page before installing. The project recommends checking node_exporter --help for available collectors and flags.

Restrict port 9100

/metrics reveals host data and should not be open to the internet. Allow only the Prometheus server's IP or network. In this example, replace 10.0.0.10 with your collector's actual IP:

sudo ufw allow from 10.0.0.10 to any port 9100 proto tcp
sudo ufw status numbered

On networks without a trusted perimeter, use exporter TLS and authentication or a private network/VPN. Basic authentication without TLS exposes the password on the network.

Install Prometheus and add targets

sudo apt update
sudo apt install -y prometheus
sudo systemctl enable --now prometheus
sudo systemctl status prometheus --no-pager

On the monitoring server, add only this job to the scrape_configs list already present in /etc/prometheus/prometheus.yml. Do not replace the entire file: the package usually includes Prometheus's own job.

  - job_name: linux
    scrape_interval: 30s
    static_configs:
      - targets:
          - web1.exemplo.com.br:9100
          - db1.exemplo.com.br:9100
        labels:
          ambiente: producao

Validate the syntax before restarting. An invalid configuration should not turn into a monitoring gap:

sudo promtool check config /etc/prometheus/prometheus.yml
sudo systemctl restart prometheus
curl -fsS http://localhost:9090/-/ready

Open http://IP_DO_PROMETHEUS:9090/targets. Both targets should appear as UP. The endpoint /-/ready returns 200 when Prometheus is ready to serve queries.

PromQL queries that answer real questions

# alvo está acessível? 1 = UP, 0 = falhou
up{job="linux"}

# CPU ocupada por host, média dos últimos 5 minutos
100 - (avg by (instance) (rate(node_cpu_seconds_total{job="linux",mode="idle"}[5m])) * 100)

# memória usada, sem contar cache reaproveitável
100 * (1 - node_memory_MemAvailable_bytes{job="linux"} / node_memory_MemTotal_bytes{job="linux"})

# espaço usado em sistemas de arquivos reais
100 * (1 - node_filesystem_avail_bytes{job="linux",fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{job="linux",fstype!~"tmpfs|overlay"})

node_load1 measures load, not CPU percentage. Compare it with the host's CPU count before concluding there is saturation. For counters, such as CPU, use rate(); applying rate() to a metric that is already an instantaneous value produces a meaningless reading.

From graph to alert

Grafana improves visualization, but an alert should originate from a rule with a duration and severity, routed through Alertmanager. Start with unavailability, disks nearing capacity, and memory pressure; avoid alerting on every momentary spike. For a comparison with traditional monitoring, see the history of Nagios and the history of Zabbix. If your hosts are provisioned through automation, also use the guide to Ansible to repeat the installation and rules without manual configuration.

Sources: Prometheus configuration; PromQL guide; security model; Node Exporter.