Node Exporter
Prometheus exporter for hardware and OS metrics
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
Uptime Kuma
Monitoring & StatusEasy self-hosted uptime monitoring tool
Replaces Pingdom, UptimeRobot
Netdata
Monitoring & StatusReal-time per-second infrastructure monitoring
Replaces Datadog, New Relic
Grafana
Monitoring & StatusOpen observability dashboards and visualization
Replaces Datadog
Prometheus
Monitoring & StatusMetrics-based monitoring and alerting toolkit
Replaces Datadog
Glances
Monitoring & StatusCross-platform system monitoring at a glance
Replaces Datadog
InfluxDB
Monitoring & StatusPurpose-built time series database for metrics and events
Replaces Datadog, AWS Timestream