集中型S.M.A.R.T管理：Scrutinyで数十台のHDD/SSDの健康状態を監視する – ITFROMZERO

Table of Contents

HDDが「突然死」してから慌ててデータ復旧を始めるのはやめよう

キャリアの初期、私は24ベイのストレージサーバーが24時間稼働する環境を管理していました。サーバーの動作が重くなったり、異音が聞こえたりするたびに、一台ずつSSHでログインして確認しなければなりませんでした。

その後は、smartctl -a /dev/sdaコマンドを打ち込み、生のデータ（raw data）を凝視して異常がないか探す作業の繰り返しです。一番困ったのは、上司から「最近のディスクの状態はどう？」と聞かれたときです。すぐに見せられるようなグラフや視覚的なレポートが全くありませんでした。

「なぜZabbixやPrometheusのようなプロ向けツールを使わないのか？」と疑問に思う方もいるでしょう。実際、私も試しました。しかし、Reallocated Sector CountやPower On HoursといったS.M.A.R.T属性を一つずつ抽出してGrafanaでダッシュボードを作成するのは、あまりにも時間がかかりすぎます。そこで私が辿り着いたのがScrutinyです。このツールは一つのことに特化しており、それを完璧にこなします。それは、モダンなWebインターフェースを通じたHDDの健康状態の監視です。

なぜ従来のツールではなくScrutinyを選ぶべきなのか？

インストールを始める前に、一般的な監視方法と比較して、その違いを見てみましょう：

smartmontools (CLI): すべてのツールの基本です。軽量でLinuxに標準搭載されていますが、クイックチェックには向いているものの、10台以上のディスクを管理する場合、一台ずつSSHで確認するのは悪夢です。
Zabbix / Prometheus: インフラ全体の監視には非常に強力です。しかし、ディスクの詳細なパラメータを抽出するには、Agentのインストール、スクリプトの作成、複雑な正規表現の設定などが必要です。
Scrutiny: smartmontoolsのパワーと、洗練されたWebインターフェースを融合させています。数値を自動的に分析し、メーカーの安全しきい値と比較して、明確なPass/Fail判定を出してくれます。特にHub-Spokeモデルを使えば、10台のサーバーのデータを一つの画面に集約できます。

Scrutinyのクイックレビュー

メリット:

最小限のWebインターフェースで、温度や寿命をリアルタイムに表示。
HDD、SSD、最新のNVMeにも対応。
Docker Compose一つで即座に展開可能。
エラー時にTelegram、Slack、Discord、メールなどで通知可能。

デメリット:

ハードウェアデータを直接読み取るため、Dockerでroot権限またはprivilegedモードが必要。

Docker ComposeによるScrutinyの構築

環境を汚さず、アップグレードも簡単なDockerを私は常に推奨しています。Scrutinyは、データを保存するWeb (Hub)と、数値を収集するCollectorの2つの部分で構成されています。1台のサーバーのみで利用する場合は、Omnibus（オールインワン）版を使用できます。

ステップ1：設定ファイルの作成

新しいディレクトリを作成し、以下の内容をdocker-compose.ymlとして保存します：

version: '3.5'

services:
  scrutiny:
    container_name: scrutiny
    image: ghcr.io/analogj/scrutiny:master-omnibus
    restart: always
    ports:
      - "8080:8080" # Web UIアクセスポート
    volumes:
      - /run/udev:/run/udev:ro
      - ./scrutiny/config:/opt/scrutiny/config
      - ./scrutiny/data:/opt/scrutiny/influxdb
    devices:
      - "/dev/sda:/dev/sda"
      - "/dev/sdb:/dev/sdb"
    environment:
      - SCRUTINY_WEB_INFLUXDB_HOST=localhost

ヒント：サーバーに多くのディスクがある場合、devicesに一つずつ記述する代わりに、privileged: trueにして/dev:/devをマップすることも可能です。ただし、システムのセキュリティを高めるためには、具体的に列挙することを優先してください。

ステップ2：システムの起動

おなじみのコマンドでコンテナを起動します：

docker-compose up -d

約30秒後、ブラウザでhttp://IP-Server:8080にアクセスしてください。最新のダッシュボードが表示され、ディスクの一覧と現在の健康状態が確認できるはずです。

複数サーバーの一元監視（Hub & Spokeモデル）

これはシステム管理者にとって最も価値のある機能です。例えば、5台のストレージサーバーがある場合、5つのダッシュボードをインストールする必要はありません。中心となるScrutiny Hubを1つと、各サーバーに軽量なScrutiny Collectorをインストールするだけです。

サテライトサーバー（監視対象）側で、以下のDockerコマンドを実行します：

docker run -d \
  --name scrutiny-collector \
  --device=/dev/sda \
  -e SCRUTINY_API_ENDPOINT=http://IP-SERVER-CHINH:8080 \
  ghcr.io/analogj/scrutiny:master-collector

Collectorは定期的にS.M.A.R.T値をスキャンし、メインサーバーに送信します。これで、全インフラを一つのブラウザタブで管理できるようになります。

Telegramによる通知設定

故障した瞬間に気づけなければ、監視システムは意味をなしません。私は以前、ダッシュボードを定期的にチェックせず、ディスクが完全に死ぬまで気づかなかったという苦い経験があります。すぐに通知設定を行いましょう。

configディレクトリ内のscrutiny.yamlを開き、Telegramの設定を追加します：

notify:
  urls:
    - "tgram://bottoken/chatid"
  # ScrutinyはApprise標準をサポートしており、ほとんどのチャットアプリと互換性があります

温度がしきい値（通常55°C）を超えたり、Pending_Sectorが増加したりすると、Scrutinyは即座にスマートフォンへ通知を飛ばします。これで非常に安心できます！

ストレージ健康監視における3つの「鉄則」

長年、数百TBのデータを扱ってきた経験から、いくつかの教訓を得ました：

Power_On_Hoursを気にしすぎない: 30,000時間（3年以上）稼働しているHDDでも、良好な状態であることは多々あります。注目すべきはReallocated_Sector_Countです。この数字が0から1に変わったら、予備のディスクを準備すべきサインです。
温度は静かな殺し屋: 物理的な故障の多くは冷却不足が原因です。ディスク温度が常に50°Cを超える場合は、すぐにケース内のエアフローを確認してください。
NVMe의特性: NVMe SSDはHDDとは異なる指標を使用します。Percentage Usedに注目してください。この数値が100%に近づくと、メモリチップの書き換え寿命が尽きようとしているため、早めの交換が必要です。

Scrutinyを導入したことで、退屈な手作業から解放されました。ログをチェックするためにコマンドを打つ代わりに、その時間をシステムの最適化に充てることができ、同時にデータが常に安全な状態にあることを確信できています。