「カチカチ」という異音が始まる前にデータを保護する
6ヶ月前、メインのメディアサーバーでRAID-Z2アレイが劣化していることに気づき、目が覚めました。長年使っていた8TBのWestern Digital Redの1台に、一晩で1,400以上の代替セクタが発生していたのです。冗長性のおかげでデータは助かりましたが、18時間に及ぶ再構築プロセスは、私にとって大きな警鐘となりました。それまでの私の監視戦略は完全に「事後対応」だったのです。たまを行う手動チェックや、大抵はスパムフォルダに振り分けられてしまうシステムメールに頼り切っていました。
その恐怖をきっかけに、私はScrutinyを導入しました。本番環境のホームラボ(HomeLab)で半年間運用した結果、今や私のシステム構成において欠かせない存在となっています。Scrutinyは、S.M.A.R.T.(Self-Monitoring, Analysis, and Reporting Technology)の生データに伴う複雑さを取り除き、難解な16進数の値を、自動アラート機能を備えたクリーンなダッシュボードへと変換してくれます。
ディスクの健康状態をどう追跡していますか?
Scrutinyに決める前に、ハードウェアを監視する3つの一般的な方法を検討しました。最適な選択は、管理するドライブが2台なのか、それとも20台なのかによって異なります。
1. 手動CLI (smartmontools)
これが標準的なアプローチです。smartmontoolsをインストールし、何かがおかしいと感じたときにsmartctl -a /dev/sdaを実行します。軽量でシステムリソースへの影響もゼロですが、履歴が残りません。もし寝ている間の高負荷なスクラブ処理中にドライブが55°Cに達していたとしても、気づくことはできません。また、チェックすべきサーバーが複数ある場合、非常に面倒な作業になります。
2. NAS内蔵の通知機能
TrueNASやSynologyは、ショートテストの失敗に対して適切なメールアラートを提供しています。特定のユニットを運用している場合はこれで十分ですが、Proxmoxノード、Raspberry Pi、単体のDockerホストなどが混在する現代のホームラボでは、監視が分散してしまいます。ストレージの安全を確認するために、5つの異なるWebポータルをチェックする必要があってはなりません。
3. Scrutinyダッシュボード
Scrutinyは中央司令塔として機能します。「コレクター(Collector)」を使用してハードウェアデータを収集し、「Web UI」でそれをInfluxDBデータベースに保存します。すべての属性を時系列で追跡するため、もし「代替セクタ数(Reallocated Sector Count)」が毎週1つか2つずつ増えていれば、Scrutinyはその傾向をフラグ立てして知らせてくれます。ドライブが実際に故障する数ヶ月前に、その予兆を捉えることができるのです。
6ヶ月運用の結論:メリットとデメリット
サーバーに追加するすべてのサービスには、リソースと時間のコストがかかります。長期テストを経て、Scrutinyがどのように評価されるかをまとめました。
メリット
- 視覚的なトレンド表示: 温度変化のグラフを見ることで、エアフローの問題を特定できます。私の場合、最下段のベイにある1台のドライブが、他のドライブよりも常に5°C高いことに気づくことができました。
- スマートな属性フィルタリング: 致命的な障害と、単なる情報としての数値を分けて表示してくれます。高い「通電時間(Power-On Hours)」の数値を見てパニックになる必要はありません。
- 柔軟なアラート機能: Discord、Telegram、Gotifyと連携できます。猛暑の際、サブドライブが45°Cの警告しきい値に達した瞬間に、Discordで通知を受け取ることができました。
- 迅速なデプロイ: Dockerを使用するため、ホストOSレベルの依存関係やPythonのバージョンを気にする必要がありません。
デメリット
- ハードウェア権限: コンテナがディスクコントローラーと通信するために
--privilegedモード(特権モード)が必要です。これはセキュリティと機能性のトレードオフであり、一部のユーザーにとっては好ましくないかもしれません。 - リソース使用量: 内部でInfluxDBインスタンスを実行するため、約200MBから300MBのRAMを消費します。単純なcronジョブよりは多いですが、ほとんどの現代的なシステムにとっては無視できる範囲です。
理想的なデプロイ戦略
ほとんどのユーザーにとって、オムニバス(Omnibus)Dockerイメージが最適な選択肢です。UI、API、データベースが1つのコンテナにパッケージ化されています。マルチサーバー構成の場合は、メインノードでフルバージョンを実行し、他の小型ノードで「コレクター専用(Collector-only)」バージョンを実行できます。すべてのデータは単一のダッシュボードに集約されます。
私はDocker Composeの使用を推奨します。ドライブのマッピングが明確になり、数秒で新しいサーバーに設定を移行できるからです。これは、長いワンライナーのCLIコマンドを管理するよりもはるかにスマートな方法です。
ステップバイステップ:Scrutinyのデプロイ
すべてを一括で起動するために、latest-omnibusイメージを使用します。以下の手順に従って、Dockerホストにセットアップしましょう。
1. フォルダの整理
まず、Scrutinyの設定ファイルとデータベースファイルを保存するための専用ディレクトリを作成します。
mkdir -p ~/homelab/scrutiny/config
mkdir -p ~/homelab/scrutiny/influxdb
cd ~/homelab/scrutiny
2. Docker Composeの設定
docker-compose.ymlファイルを作成します。devicesセクションとvolumesセクションに注目してください。これらにより、コンテナがマシンの物理ハードウェアを「認識」できるようになります。
version: '3.8'
services:
scrutiny:
container_name: scrutiny
image: ghcr.io/analogj/scrutiny:latest-omnibus
restart: unless-stopped
ports:
- "8080:8080"
volumes:
- /run/udev:/run/udev:ro
- ./config:/opt/scrutiny/config
- ./influxdb:/opt/scrutiny/influxdb
- /dev:/dev
privileged: true
environment:
- TZ=Asia/Tokyo
3. 起動
コマンド1つでサービスを起動します。
docker-compose up -d
http://your-server-ip:8080にアクセスしてください。最初のスキャンが実行されるまで1分ほど待ちます。すべてが正しく動作していれば、ドライブが「Healthy」ステータスで表示されます。
4. アラートの設定(重要)
ダッシュボードは、見ていなければ意味がありません。プッシュ通知を受け取るために、configフォルダにscrutiny.yamlファイルを作成します。以下はシンプルなDiscordウェブフックのテンプレートです。
version: 1
notify:
urls:
- "discord://webhookid@webhooktoken"
threshold:
status: ["failed", "warning"]
metrics: true
設定を反映させるために、docker-compose restart scrutinyでコンテナを再起動します。これで、ドライブに不調の兆候が現れたときに、サーバーが通知してくれるという安心感とともに過ごすことができます。
NVMeとRAIDに関する注意点
テスト中、NVMeドライブやハードウェアRAIDカード(Dell PERCコントローラーなど)の背後にあるドライブは、設定が少し難しい場合があることがわかりました。Scrutinyはこれらを自動検出するのが得意ですが、デバイスタイプをsatやnvmeとして指定するために、たまにcollector.yamlを作成する必要があるかもしれません。標準的なSATAドライブやITモードのHBAを使用している95%のユーザーにとっては、箱出しの状態で完璧に動作します。
まとめ
ハードドライブの監視は、決して刺激的な趣味ではありません。しかし、ホームラボにおける最も重要なメンテナンス作業です。Scrutinyは、シンプルなツールと詳細なデータ分析の中間にある、絶妙なポジションを確立しています。これを導入して以来、私はすでに故障の初期兆候を見せた2台のドライブを交換しました。午前2時の緊急事態ではなく、自分のスケジュールに合わせて対応することができたのです。データを大切に思うなら、今週末の20分間を使ってこれをセットアップしてみてください。

