Prometheus Node Exporter - Metrics Configuration & Alerting

Prometheus Node Exporter collects host-level metrics such as CPU time, available memory, disk activity, and network traffic. Prometheus scrapes these metrics so you can query them and set up alerts when a host needs attention.

This guide takes you through that setup, then shows how to tune collectors, add custom metrics, and configure common host alerts. You’ll also see how to send Node Exporter metrics to SigNoz Cloud using OpenTelemetry.

Prerequisites

• Prometheus - A monitoring and alerting toolkit that collects and stores metrics as time series data. Download and install Prometheus from the official website.

Install & Run the Prometheus Node Exporter

The easiest way to install Node Exporter is to download the precompiled binary from the Prometheus official downloads page. The tarball contains a single static executable that can be extracted and run directly on any Linux/Unix-based system.

If you prefer not to leave the terminal, you can also use the following commands to download and extract Node Exporter:

# Download the latest version (adjust version number, OS, and ARCH).
wget https://github.com/prometheus/node_exporter/releases/download/v<VERSION>/node_exporter-<VERSION>.<OS>-<ARCH>.tar.gz
 
# Extract binary
tar xvfz node_exporter-<VERSION>.<OS>-<ARCH>.tar.gz
 
# Change directory to the extracted folder
cd node_exporter-<VERSION>.<OS>-<ARCH>
 
# Start the node exporter
./node_exporter

Once Node Exporter is running, your terminal output should look similar to the screenshot below:

Once Node Exporter is running, it begins exposing host-level metrics on port 9100 by default. You can verify this by hitting the /metrics endpoint.

# Verify that Node Exporter is exposing metrics on port 9100
curl http://localhost:9100/metrics | grep node_

All host and system metrics exposed by Node Exporter are prefixed with node_, which makes them easy to identify and filter.

You should now see output similar to the screenshot below, confirming that Node Exporter is successfully exposing your machine's CPU, memory, disk, network, and other system metrics.

Configure Prometheus to Scrape Node Exporter

Prometheus reads all scrape targets from its main configuration file: prometheus.yml. If you don’t already have one, you can create it now and update it with the below configs.

global:
  # How frequently Prometheus scrapes all targets unless overridden
  scrape_interval: 15s
 
scrape_configs:
  # === Scrape Node Exporter Metrics ===
  - job_name: 'node' # A name to identify this scrape job
    static_configs:
      - targets: ['localhost:9100']
        # Node Exporter exposes metrics on port 9100 by default
        # Replace 'localhost' with the server IP if scraping remotely

Once your prometheus.yml file is updated, start Prometheus using the command below:

prometheus --config.file=./prometheus.yml --web.enable-lifecycle

This will load your scrape targets. Now that Prometheus is running, let’s move on to visualizing the metrics using the Prometheus Expression Browser.

Check the Metrics in Prometheus

Open http://localhost:9090/targets and check that the node target is UP. You can also run:

up{job="node"}

A value of 1 confirms the scrape succeeded. To explore the CPU metrics, enter the following query in the Prometheus expression browser and switch to the graph view:

rate(node_cpu_seconds_total{mode="system"}[1m])

This shows the fraction of time each CPU core spent in system mode over the last minute.

With metrics flowing into Prometheus, you can decide which collectors and metric families you need for your hosts.

Limitations of Default Node Exporter Configurations

Node Exporter enables many collectors by default. Start with these defaults, then review which metrics your dashboards and alerts actually use before changing the collector set.

Common issues teams run into:

• Metric noise: Unused metrics increase storage and query costs.
• Resource overhead: Unnecessary collectors add CPU and I/O overhead on hosts.
• Alert fatigue: Alerting on raw metrics without context leads to false positives.
• Lack of ownership: Teams collect metrics they don’t know what to do with.

In production, every metric should serve a purpose (dashboards, alerts, or capacity planning). This brings us to the next critical step: Configuring Node Exporter Collectors. By enabling only the collectors you actually need, you ensure that the metrics you ingest are intentional, meaningful, and aligned with real operational goals.

Configuring Node Exporter Collectors

Collectors determine which categories of system metrics Node Exporter exposes, such as CPU, memory, disks, networking, thermal sensors, filesystem stats, etc.

Node Exporter ships numerous collectors, most of which are enabled by default. You can explore the complete list of collectors and the metrics they expose in the Official Node Exporter GitHub repository.

Stop the exporter before restarting it with a different set of collectors. You can control them using these startup flags:

• --collector.<name>: enable a collector
• --no-collector.<name>: disable a default collector
• --collector.disable-defaults: start with nothing and enable only what you need

For Example

Enable the processes collector (disabled by default)

./node_exporter --collector.processes

Disable the entropy collector

./node_exporter --no-collector.entropy

Minimal mode: enable only CPU and memory collectors:

./node_exporter \
  --collector.disable-defaults \
  --collector.cpu \
  --collector.meminfo

After configuring collectors, you can verify changes by re-running:

curl http://localhost:9100/metrics

By now, you’ve seen how Node Exporter collectors control which categories of metrics are exposed from a host. Tuning collectors helps reduce noise and overhead, but it still leaves one crucial question unanswered: "Which metrics should you actually care about?"

Explore Most Common Node Exporter Metrics

Even with a minimal set of collectors enabled, Node Exporter exposes hundreds of host-level metrics, but only a subset is essential for day-to-day monitoring and alerting. In production, the goal isn’t to understand every metric Node Exporter exposes. The goal is to identify a small, reliable set of signals that helps better understand the host state.

Below are some of the most essential metric families you’ll use when building dashboards or defining alerting rules.

When Built-In Metrics Aren’t Enough

The metrics we’ve covered so far represent the core health signals of a Linux host. For most infrastructure teams, CPU, memory, disk, and network metrics form the backbone of reliable host monitoring.

However, real-world systems often have environment-specific conditions that generic exporters can’t capture.

Examples include:

• Repeated failed SSH login attempts
• Status of backup jobs or cron tasks
• Disk cleanup scripts that must run successfully
• Presence (or absence) of critical files
• Custom health checks tied to your organization’s operational logic

These signals are just as important as CPU or memory usage, but they don’t exist as built-in Node Exporter metrics. This is where custom host metrics come into play.

Expose Custom Host Metrics

Node Exporter doesn’t try to anticipate every possible operational requirement. Instead, it provides a simple and powerful extension mechanism: the textfile collector. It is a custom collector you can use to expose your own metrics by writing them to .prom files.

Step 1: Create a directory

sudo mkdir -p /var/lib/node_exporter/textfile_collector

Step 2: Start Node Exporter with the textfile collector

./node_exporter \
  --collector.textfile \
  --collector.textfile.directory=/var/lib/node_exporter/textfile_collector

Step 3: Create a custom metric file in the directory we created in step 1

echo "custom_failed_ssh_logins_total $(grep -c 'Failed password' /var/log/auth.log)" \
  > /var/lib/node_exporter/textfile_collector/ssh_failures.prom

Step 4: Verify Metrics

curl http://localhost:9100/metrics | grep custom_failed

Now that you have both built-in and custom host metrics available, the next step is to set up alerting rules so Prometheus can notify you when your system enters an unhealthy state.

Setting Up Most Common Node Exporter Alerting Rules

To monitor Linux hosts effectively using Node Exporter, SRE teams rely on four fundamental indicators of system health. These are a host-level adaptation of Google’s “Golden Signals” for services. Each signal maps directly to a PromQL alerting rule that Prometheus can evaluate.

1. CPU Usage (Saturation): High CPU usage indicates saturation, leading to slow application performance or request queuing.
2. Memory Usage (Saturation): Memory pressure can cause swapping, OOM kills, or severe application slowdowns.
3. Disk I/O Saturation (Saturation): When disks are saturated, read/write operations slow down, and applications may stall.
4. Filesystem Fullness (Errors / Saturation): Running out of disk space can cause service outages, failed writes, or database corruption.

Let’s set up these alerting rules.

Step 1: Create a directory for the alert rules alongside prometheus.yml.

mkdir -p rules

Step 2: Save the following rules as rules/node_alerts.yml.

groups:
  - name: node_exporter_alerts
    rules:
      # CPU
      - alert: HighCPUUsage
        # Triggers when average non-idle CPU usage exceeds 85% across all cores.
        expr: (100 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)) > 85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High CPU usage on {{ $labels.instance }}"
 
      # Memory
      - alert: HighMemoryUsage
        # Triggers when available memory drops below 15% of total memory.
        expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
              / node_memory_MemTotal_bytes > 0.85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High memory usage on {{ $labels.instance }}"
 
      # Sustained disk activity
      - alert: DiskIOSaturation
        # Triggers when disk spends more than 80% of time handling I/O operations.
        expr: rate(node_disk_io_time_seconds_total[5m]) > 0.80
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Sustained disk activity on {{ $labels.instance }}"
 
      # Disk Fullness
      - alert: DiskSpaceLow
        # Triggers when available disk space falls below 10% on any real filesystem.
        expr: node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}
              / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"} < 0.10
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Low disk space on {{ $labels.instance }}"

Your Prometheus directory structure should now look like this:

.
  ├── prometheus.yml
  └── rules/
       └── node_alerts.yml

Step 3: Add the rule file to your existing prometheus.yml without removing its scrape jobs:

rule_files:
  - 'rules/node_alerts.yml'

Check the rules and configuration before reloading Prometheus:

promtool check rules rules/node_alerts.yml
promtool check config prometheus.yml

Reload Prometheus to apply the changes. Because Prometheus was started with --web.enable-lifecycle, you can run curl -X POST http://localhost:9090/-/reload. You can also reload it through your service manager or by sending a SIGHUP signal. For the rule lifecycle and notification setup, see our Prometheus rules guide.

Step 4: Verify That Prometheus Loaded Your Configuration

Once Prometheus is running, you can verify that your scrape targets and alert rules are correctly loaded by opening the Prometheus UI in your browser.

To do this, navigate to the following paths on your Prometheus server:

Loaded rules page: /rules

Active alerts page: /alerts

Scrape the target's page: /targets

For example, if Prometheus is running locally on port 9090, these pages will be available at: http://<your-prometheus-host>:9090/rules, /alerts, and /targets.

When the configuration is correct, you should see:

• The node job appears on the target health page and is UP.
• The four host alerting rules appear on the rules page.
• Alerts transitioning from inactive → pending → firing when conditions are met.

Send Node Exporter Metrics to SigNoz Cloud

Once you have checked the metrics in Prometheus, you can also send them to SigNoz Cloud for dashboards alongside application metrics, logs, and traces. The OpenTelemetry Collector provides two ways to collect host metrics, depending on whether you want to keep Node Exporter.

Scrape Node Exporter with the Prometheus Receiver

If Node Exporter is already running, configure the OpenTelemetry Collector's Prometheus receiver to scrape its /metrics endpoint. Add the host and port, such as localhost:9100, as a scrape target and enable the receiver in the metrics pipeline. The Collector then forwards the metrics to SigNoz through its configured exporter.

Open Metrics Explorer in SigNoz Cloud and search for a metric such as node_cpu_seconds_total to confirm that data is arriving.

Follow the SigNoz Prometheus receiver guide for the full configuration.

Collect Host Metrics without Node Exporter

If you prefer to collect host metrics directly through OpenTelemetry, use the hostmetrics receiver instead. It collects CPU, memory, disk, and network metrics without a separate Node Exporter process.

This receiver uses different metric names, so the Node Exporter queries and alert rules in this guide will need adapting. Follow the SigNoz host metrics guide to configure it and check the hosts view.

Conclusion

You now have a Node Exporter setup that exposes host metrics, a Prometheus scrape job to collect them, and examples for tuning collectors and configuring alerts. You can keep this Prometheus setup or use the OpenTelemetry Collector to send Node Exporter metrics to SigNoz.

By being intentional about what you collect and alert on, Node Exporter becomes a reliable signal for host health rather than a source of metric sprawl and alert fatigue.