NO

Node Exporter

Prometheus exporter for hardware and OS metrics

Monitoring & Status ★ 13.8k stars Easy setup Apache-2.0

Node Exporter exposes a wide variety of hardware and operating system metrics from Unix-like systems for Prometheus to scrape. It is the de facto standard for host-level monitoring in the Prometheus ecosystem.

Key features

  • CPU, memory, disk, and network metrics
  • Many collector modules
  • Tiny resource footprint
  • Standard Prometheus exporter

Pros & cons

Strengths

  • Essential for host monitoring
  • Extremely reliable

Trade-offs

  • Host metrics only
  • Requires Prometheus and Grafana

Node Exporter replaces

Last reviewed Aug 26, 2026 · 792 words

Install Node Exporter on every machine you own, including the ones you think are boring. It costs about 32 MB of RAM and a few tenths of a CPU percent, it has been the standard host exporter in the Prometheus world since 2015, and the one thing that will catch you is the Docker deployment: run it in a container without --path.rootfs and the disk and memory figures it reports describe the container, not the host. Get that right and the rest is one scrape job and 5 alert rules.

It is a scrape target, not an agent

Node Exporter does nothing on its own. It listens on port 9100, and when something fetches /metrics it reads /proc and /sys and prints a few thousand lines of plain text. No database, no buffering, no push. Prometheus pulls it on an interval, typically every 15 seconds, and Grafana draws it. If you do not already run Prometheus, this is the moment to set it up; the whole stack for a small network is laid out in monitoring and uptime for homelabs. Compared with the Datadog agent it replaces, it covers host metrics only: container-level numbers come from cAdvisor, and application metrics come from each application's own exporter.

The binary beats the container, but the container is fine

The cleanest deployment is the static Go binary under systemd. Download the release tarball from the project's GitHub page, drop node_exporter in /usr/local/bin, and give it a 6-line unit file. On Debian and Ubuntu, apt install prometheus-node-exporter does the same job with an older version, which for this exporter rarely matters.

If everything on the box is Compose, the container works with three conditions: host networking, the host PID namespace, and the root filesystem bind-mounted read-only with the rootfs flag pointed at it.

services:
  node-exporter:
    image: quay.io/prometheus/node-exporter:latest
    command:
      - --path.rootfs=/host
    network_mode: host
    pid: host
    volumes:
      - /:/host:ro,rslave
    restart: unless-stopped

Skip rslave and any mount that appears after the container starts (a USB disk, a new ZFS dataset) is invisible. Skip network_mode: host and the network counters describe the container's virtual NIC, which is nobody's idea of useful.

Five metrics pay the rent

Of the 60-odd collectors, a handful produce almost everything you will ever alert on. node_filesystem_avail_bytes for disk. node_memory_MemAvailable_bytes (not MemFree, which ignores cache) for memory. node_cpu_seconds_total by mode, turned into a percentage with rate(). node_load1 for a quick sanity check. node_network_receive_bytes_total and its transmit twin for bandwidth. The rule I keep for disk:

- alert: DiskFillingUp
  expr: predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}[6h], 24*3600) < 0
  for: 30m

That fires when the current growth rate will empty the disk within a day, which is the alert you want at 9 pm rather than the "disk is full" alert at 3 am. Add up{job="node"} == 0 for dead hosts, a memory rule at 10 percent available, a load rule at twice the core count, and node_systemd_unit_state for the services you care about if you enable the systemd collector. That is the whole list for most homelabs.

The textfile collector exports anything for free

--collector.textfile.directory=/var/lib/node_exporter makes the exporter read every *.prom file in that directory and append it to its output. A cron job that writes one line, backup_last_success_timestamp 1724630400, gets your backup age into Prometheus without writing an exporter. I use it for SMART summaries, ZFS scrub dates, and the age of the last Borg archive, and it has replaced three separate scripts that used to email me.

What it will not do

It has no idea what Docker containers are doing, does not read logs, and does not know about your GPU (dcgm-exporter covers NVIDIA cards). It exposes metrics to anyone who can reach port 9100, so on an internet-facing host bind it to a private interface or firewall it; the only built-in protection is an optional web config file for TLS and basic auth. Windows hosts need windows_exporter, a separate project with a different metric namespace.

What I'd do

Binary plus systemd on bare-metal hosts, the Compose block above on Docker-only boxes, every one of them in a single node job in Prometheus with an instance label you would recognise at 3 am. The disk prediction rule, the dead-host rule, and the memory rule on day one; the textfile collector for backup age in week one. Then leave it alone. In years of running it I have never had Node Exporter itself be the thing that broke, which is the highest compliment monitoring software can get.

Compare Node Exporter

6 head-to-head comparisons.

Similar monitoring & status apps