2026年6月26日

node_exporterでLinuxのメトリクスを収集する方法（導入からPrometheus連携・保護まで）

バックアップ・監視

node_exporter は、Linux サーバーの CPU・メモリ・ディスク・ネットワークなどの状態を Prometheus が読める形式で公開する公式のエクスポーターです。サーバーに入れて起動し、Prometheus の設定に追加すれば、数分でメトリクスの収集が始まります。この記事では、systemd で常駐させるインストール手順、Prometheus からの取得設定、よく使うクエリ、そして 9100 番ポートを外部にさらさないための保護までを説明します。

node_exporter の役割と全体像

Prometheus は、監視対象に HTTP でアクセスしてメトリクスを取りに行く「プル型」の監視システムです。node_exporter は監視対象のサーバー側で動き、/proc や /sys などから読み取った値を、既定では 9100 番ポートの /metrics で公開します。

構成は次のようになります。

監視対象のサーバー：node_exporter を動かす（WordPress を載せた Web サーバーなど）
Prometheus サーバー：一定間隔で各サーバーの :9100/metrics を取得して保存する
可視化・通知：Grafana でグラフにし、Alertmanager で異常を通知する

Prometheus 本体がまだ無い場合は、先に Prometheus を用意してから進めてください。node_exporter だけ入れても、データを取りに来る側が無ければ蓄積されません。

インストールする

方法は大きく2つあります。

ディストリビューションのパッケージを使う

Debian/Ubuntu では prometheus-node-exporter というパッケージがあり、インストールすると systemd のサービスとして起動します。

sudo apt update
sudo apt install prometheus-node-exporter
systemctl status prometheus-node-exporter

手軽な反面、パッケージのバージョンは公式の最新版より古いことが多く、設定は /etc/default/prometheus-node-exporter の起動引数で行うなど、公式バイナリとは配置が異なります。

公式のバイナリを使う

最新版を使いたい場合は、GitHub の prometheus/node_exporter のリリースページからバイナリを取得します。バージョン番号は例なので、リリースページで最新の安定版を確認して置き換えてください（2026年10月現在も 1 系で更新が続いています）。

VERSION="1.9.1"   # リリースページで確認した版に置き換える
ARCH="linux-amd64"
cd /tmp
curl -LO "https://github.com/prometheus/node_exporter/releases/download/v${VERSION}/node_exporter-${VERSION}.${ARCH}.tar.gz"
curl -LO "https://github.com/prometheus/node_exporter/releases/download/v${VERSION}/sha256sums.txt"

# チェックサムを確認（OK と表示されることを確かめる）
grep "node_exporter-${VERSION}.${ARCH}.tar.gz" sha256sums.txt | sha256sum -c -

tar xzf "node_exporter-${VERSION}.${ARCH}.tar.gz"
sudo install -m 0755 "node_exporter-${VERSION}.${ARCH}/node_exporter" /usr/local/bin/
node_exporter --version

チェックサムの確認は、ダウンロードの破損や改ざんに気づくための手順なので省略しないでください。ARM のサーバーでは linux-arm64 を選びます。

次に、ログインできない専用ユーザーと systemd のユニットを作ります。root で動かす必要はありません。

sudo useradd --system --no-create-home --shell /usr/sbin/nologin node_exporter

# /etc/systemd/system/node_exporter.service
[Unit]
Description=Prometheus node_exporter
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
ExecStart=/usr/local/bin/node_exporter \
  --web.listen-address=:9100 \
  --collector.systemd \
  --collector.textfile.directory=/var/lib/node_exporter/textfile_collector
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo mkdir -p /var/lib/node_exporter/textfile_collector
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter
systemctl status node_exporter

--collector.systemd は既定では無効なコレクターで、サービスの起動状態を取得できるようになります。不要なら外してかまいません。コレクターの既定の有効・無効はバージョンで変わることがあるため、node_exporter --help で手元の版の一覧を確認できます。

メトリクスが出ているか確認する

サーバー上で次のコマンドを実行し、値が返ってくるか確かめます。

curl -s http://localhost:9100/metrics | grep -E '^node_(cpu_seconds_total|memory_MemAvailable_bytes|filesystem_avail_bytes)' | head

何も返らない場合は、journalctl -u node_exporter -n 50 でエラーを確認します。よくある原因は、ポートが他のプロセスと重なっている（ss -ltnp | grep 9100 で確認）、ユニットファイルの改行やバックスラッシュの誤り、テキストファイル用ディレクトリが存在しない、などです。

Prometheus から取得する

Prometheus サーバーの prometheus.yml に、監視対象を追加します。

scrape_configs:
  - job_name: "node"
    scrape_interval: 30s
    static_configs:
      - targets:
          - "192.0.2.10:9100"   # 監視対象サーバーのIPまたはホスト名
        labels:
          role: "web"

変更したら、文法を確認してから再読み込みします。

promtool check config /etc/prometheus/prometheus.yml
sudo systemctl reload prometheus   # reload に対応していない構成では restart

Prometheus の Web 画面の「Status」→「Targets」（版によって表記や場所が異なります）で、対象が UP になっていれば取得できています。DOWN の場合は、表示されるエラーから、接続拒否（ファイアウォール）、タイムアウト（経路）、認証エラー（後述の保護設定）のどれかを切り分けます。

よく使うクエリ

収集したメトリクスは PromQL で集計します。最初に押さえておくと便利なものを挙げます。

# CPU使用率（%）：アイドル以外の時間の割合
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# メモリ使用率（%）：MemAvailable を基準にする
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

# ディスク使用率（%）：一時的なファイルシステムを除く
(1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"}
   / node_filesystem_size_bytes{fstype!~"tmpfs|overlay|squashfs"}) * 100

# 受信量（バイト/秒）
rate(node_network_receive_bytes_total{device!="lo"}[5m])

# 1分間のロードアベレージ
node_load1

メモリは「空き（MemFree）」ではなく「使える量（MemAvailable）」で見るのがポイントです。Linux はファイルキャッシュに空きメモリを使うため、MemFree だけを見ると常に足りないように見えてしまいます。カウンター型のメトリクス（名前が _total で終わるもの）は値が増え続けるので、rate() で単位時間あたりの変化にしてから使います。

9100番ポートを外部にさらさない

/metrics にはカーネルのバージョン、ファイルシステムの構成、ネットワークインターフェース名など、攻撃者の下調べに役立つ情報が含まれます。インターネットから誰でも見られる状態は避けてください。

最も簡単なのは、ファイアウォールで Prometheus サーバーの IP からだけ許可する方法です。UFW の例を示します。

sudo ufw allow from 198.51.100.5 to any port 9100 proto tcp   # PrometheusサーバーのIP

クラウドのセキュリティグループを使っている場合は、そちらでも同じ制限をかけます。同じサーバー上に Prometheus がある場合は、--web.listen-address=127.0.0.1:9100 にしてローカルからしか受け付けない設定にできます。

インターネットを経由して取得する場合は、node_exporter の --web.config.file で TLS と Basic 認証を設定する方法もあります。パスワードは bcrypt のハッシュで書き、平文では保存しません。

# /etc/node_exporter/web-config.yml（node_exporter ユーザーが読める権限にする）
tls_server_config:
  cert_file: /etc/node_exporter/node_exporter.crt
  key_file: /etc/node_exporter/node_exporter.key
basic_auth_users:
  prometheus: "$2y$10$ここにbcryptハッシュを入れる"

ハッシュは htpasswd -nBC 10 "" | tr -d ':\n' などで作れます。Prometheus 側では、対象のジョブに scheme: https と basic_auth（パスワードは password_file で別ファイルから読む）を設定します。設定ファイルの書き方は版によって追加・変更があるため、手元の版のドキュメントを確認してください。

独自の値を追加する：テキストファイルコレクター

node_exporter は、指定したディレクトリにある .prom ファイルの内容もメトリクスとして公開します。たとえば WordPress のバックアップスクリプトの最後に、成功した時刻を書き出しておけば、「24時間以上バックアップが成功していない」ことを Prometheus で検知できます。

# バックアップ成功時に実行する（いったん一時ファイルに書いてから置き換える）
DIR=/var/lib/node_exporter/textfile_collector
echo "backup_last_success_timestamp_seconds $(date +%s)" > "$DIR/backup.prom.$$"
mv "$DIR/backup.prom.$$" "$DIR/backup.prom"

一時ファイルに書いてから mv で置き換えるのは、node_exporter が書きかけのファイルを読んでしまうのを防ぐためです。スクリプトの実行ユーザーがこのディレクトリに書き込めるよう、権限も合わせて設定します。

まとめ

node_exporter は Linux の状態を 9100 番の /metrics で公開し、Prometheus が定期的に取得します。
パッケージなら手軽、公式バイナリなら最新版。バイナリはチェックサムを確認し、専用ユーザーと systemd で常駐させます。
取得できているかは curl localhost:9100/metrics と Prometheus の Targets 画面で確認します。
メモリは MemAvailable、カウンターは rate() で見るのが基本です。
9100 番はファイアウォールで Prometheus の IP に限定し、外部経由なら TLS と Basic 認証を使います。