Ubuntu 26.04 smartctl exporter の基本設定 – Prometheus でディスク SMART メトリクスを収集する

Ubuntu 26.04 の物理ホストで、prometheus-smartctl-exporter を使ってディスクの S.M.A.R.T. 情報を Prometheus メトリクスとして収集します。smartd が異常イベントをログへ残すための daemon だとすると、smartctl exporter は温度、エラー数、属性値などを時系列で見続けるための入口です。

この記事では、既存の smartd 監視と役割を重複させず、SMART 情報を直接取得できる物理ホストに exporter を配置し、127.0.0.1:9633/metrics で取得できることを確認します。Prometheus から scrape する範囲、通知責任、仮想マシンを対象外にする判断基準もあわせて扱います。

smartd と smartctl exporter の役割を分ける

smartd と smartctl exporter は、どちらも S.M.A.R.T. を扱います。ただし、運用上の責務は同じではありません。

smartd は「異常が起きた時にログへ残す」役割に向いています。一方、smartctl exporter は「値がどう変化しているか」を Prometheus で継続的に見る役割に向いています。どちらか一方で全てを済ませようとせず、イベントログと時系列メトリクスを分けるのが扱いやすい構成です。

適用対象は SMART 情報を取得できる物理ホスト

smartctl exporter は、OS から smartctl でディスク情報を読めることが前提です。通常の仮想マシンでは、仮想ディスクの背後にある物理ドライブの SMART 情報を取得できません。そのため、KVM、VMware、クラウド VM へ無条件に入れても、期待するディスク監視にはなりません。

• 物理 SATA / SAS / NVMe デバイスを直接持つホストを対象にする
• 通常の仮想マシンやクラウド VM は対象外にする
• PCI passthrough や USB passthrough は smartctl で読めるかを先に確認する
• RAID controller 配下では device type と見える範囲を確認する

対象選定は exporter の設定より前に決めます。Prometheus に scrape target を追加してから「メトリクスが出ない」と調べるより、先にローカルで smartctl --scan-open と exporter の /metrics を確認する方が切り分けやすくなります。

smartctl exporter をインストールする

Ubuntu 26.04 では、Prometheus 向けのパッケージとして prometheus-smartctl-exporter を使います。このパッケージは smartmontools に依存するため、smartctl で取得した情報を exporter がメトリクスへ変換する構成になります。

sudo apt update
sudo apt install -y prometheus-smartctl-exporter

パッケージ導入後、サービス unit が存在することを確認します。

systemctl cat smartctl_exporter.service
systemctl status smartctl_exporter.service --no-pager

サービスを有効化する

サービスを起動し、自動起動を有効にします。設定管理で配布する場合も、最終的には systemd の状態を確認します。

sudo systemctl enable --now smartctl_exporter.service
sudo systemctl status smartctl_exporter.service --no-pager -l

起動できない場合は、まず smartctl 側で対象デバイスを読めるかを確認します。exporter の問題に見えても、実際には仮想ディスク、権限、controller 越しの device type、SMART 非対応デバイスが原因になっていることがあります。

ローカルでメトリクスを確認する

Prometheus へ追加する前に、ホスト上で /metrics を確認します。最初に見るべきなのは、HTTP が返ることと、smartctl_ で始まるメトリクスが出ていることです。

curl --fail --silent --show-error http://127.0.0.1:9633/metrics
curl --fail --silent --show-error http://127.0.0.1:9633/metrics | grep '^smartctl_'

curl が失敗する場合は、サービスが起動しているか、待ち受けアドレスとポートが想定どおりかを確認します。HTTP は返るが smartctl_ が出ない場合は、exporter が SMART 情報を取得できるデバイスを見つけられていない可能性があります。

sudo smartctl --scan-open
sudo journalctl -u smartctl_exporter.service --since today --no-pager

Prometheus から scrape する

Prometheus が同じホスト上にある場合は、loopback の 127.0.0.1:9633 を scrape target にできます。Prometheus が別ホストにある場合は、smartctl exporter の待ち受け、firewall、到達元ネットワークを確認してから公開範囲を決めます。

scrape_configs:
  - job_name: smartctl
    static_configs:
      - targets:
          - 127.0.0.1:9633

別ホストの Prometheus から収集する場合は、監視ネットワークからだけ到達できるようにします。ディスクの型番、シリアル番号、デバイス名がラベルや値に含まれる可能性があるため、必要以上に広いネットワークへ exporter を公開しない方が安全です。

node_exporter とは別 job にする

node_exporter は CPU、memory、filesystem、network などのホストメトリクスを広く扱います。smartctl exporter はディスクの SMART 情報に絞るため、同じ Prometheus で収集しても job は分けます。

• node_exporter はホスト全体のリソース状態を見る
• smartctl exporter は物理ディスクの SMART 属性を見る
• 通知ルールは job とメトリクスの責務ごとに分ける
• smartd のログ通知と Prometheus の閾値通知を重複させすぎない

通知責任を分ける

smartd、Prometheus、ログ基盤のどこで通知するかを決めておかないと、同じディスク異常で複数の通知が飛び、逆に運用しづらくなります。最初は責務を次のように分けると扱いやすくなります。

特に、SMART の属性値はメーカーやデバイス種別によって意味が変わることがあります。単一の値だけで即時交換と断定せず、増加傾向、self-test 結果、OS ログ、RAID controller の状態、実際の I/O エラーを合わせて判断します。

Ansible で管理する場合の考え方

構成管理では、パッケージ導入とサービス有効化を最小単位にします。smartctl exporter は smartd の設定ファイルを置き換えるものではないため、smartd ロールとは別責務にします。

- name: Install prometheus-smartctl-exporter
  become: true
  ansible.builtin.apt:
    name: prometheus-smartctl-exporter
    state: present
- name: Enable smartctl_exporter.service
  become: true
  ansible.builtin.systemd:
    name: smartctl_exporter.service
    state: started
    enabled: true

適用対象は inventory やグループで物理ホストへ限定します。全 Ubuntu ホストへ共通適用すると、通常の仮想マシンにも exporter が入り、意味のない scrape target や失敗ログを増やします。

運用確認

適用後は、パッケージ、サービス、ローカルメトリクス、Prometheus 側の target 状態を順に確認します。

dpkg -l prometheus-smartctl-exporter smartmontools
systemctl is-enabled smartctl_exporter.service
systemctl is-active smartctl_exporter.service
curl --fail --silent --show-error http://127.0.0.1:9633/metrics | grep '^smartctl_'

• 対象ホストが物理ホストに限定されていること
• smartctl --scan-open で対象デバイスを確認できること
• smartctl_exporter.service が起動していること
• /metrics に smartctl_ メトリクスが出ていること
• Prometheus の target が UP になっていること
• smartd のログ通知と Prometheus のアラートが同じ責務を二重に持っていないこと

構成を見直すべきケース

次のような場合は、単に exporter を起動するだけではなく、smartd、Prometheus、ストレージ構成をあわせて見直します。

• RAID controller 配下のディスクごとの情報が見えない
• NVMe と SATA HDD が混在し、見るべき属性が違う
• ディスクのシリアル番号や型番を監視基盤へ出したくない
• Prometheus が別ネットワークから scrape する必要がある
• 温度やエラー数の閾値を全デバイス共通にできない
• smartd の異常ログと Prometheus アラートが重複している

smartctl exporter は、ディスク交換判断を自動化する魔法の部品ではありません。交換判断には SMART 属性の傾向、self-test 結果、OS の I/O エラー、RAID / HBA 側の状態、サービス影響を合わせて見る必要があります。

まとめ

Ubuntu 26.04 で smartctl exporter を使うと、物理ディスクの S.M.A.R.T. 情報を Prometheus の時系列メトリクスとして扱えます。smartd が異常イベントをログへ残す役割なら、smartctl exporter は属性値や温度の変化を継続的に見る役割です。

重要なのは、対象を SMART 情報を直接取得できる物理ホストへ限定すること、Prometheus へ追加する前に 127.0.0.1:9633/metrics で smartctl_ メトリクスを確認すること、そして smartd、ログ監視、Prometheus アラートの責務を分けることです。

関連記事

Ubuntu 26.04 node_exporter の基本設定 – Prometheus でホストメトリクスを収集する Ubuntu 26.04 smartd の基本設定 – S.M.A.R.T. で物理ディスクを監視する Ubuntu 26.04 Reverse Path Filtering の基本設定 – 複数インターフェイスと PBR で rp_filter を確認する Ubuntu 26.04 FRR routing の基本設定 – OSPF / BGP を使う前に決めること Ubuntu 26.04 Apache WAF の基本設定 – ModSecurity と CRS を導入する Ubuntu 26.04 Redis の基本設定 – ローカルキャッシュと Unix socket を管理する Ubuntu 26.04 Dovecot の基本設定 – IMAP / Maildir / TLS と Postfix 連携を構成する Ubuntu 26.04 CephFS の基本設定 – pool / MDS / subvolume を構成する