見出し画像

[自宅サーバーのアプリ] Scrutinyで日々のStorage健康診断

自宅快適化計画

こんにちは、Noboです。
今回は、ScrutinyというHDDの健康状態を監視するアプリを紹介します。

こちらのNoteで構築している自宅サーバーは、TrueNASをプラットフォームとしています。データを確実に保護するということが一つの大きな目的であり、そのためにZFSによるデータ整合性の担保や、スナップショット機能によるデータ保護といったソフトウェアレベルの保護と、RAID-1といったハードウェアレベルの冗長性等でデータの耐障害性を高めていますが、HDD自体の健康状態を確認する機能が欠けています。

TrueNAS 25.04までは、S.M.A.R.T.機能でHDDの健康状態を確認する機能が搭載されていましたが、TrueNASの開発陣はS.M.A.R.T.による診断は適切でないと判断したため、TrueNAS 25.10から機能が廃止されました。その代わりに、TrueNASは今回紹介する「Scrutiny」の利用を推奨しています。


Scrutinyについて

ハードディスク・SSDの健康診断を自動化し、障害の予兆を早期に検出してアラートを送ってくれるWebアプリケーションです。

公式サイト： https://github.com/AnalogJ/scrutiny

主な機能：

  1. S.M.A.R.T.監視
    S.M.A.R.T.（Self-Monitoring, Analysis and Reporting Technology）とは、HDDやSSD自身が内部の状態を監視する技術です。

  2. データの分析
    取得したS.M.A.R.T.情報を、Backblaze社の大規模障害データの統計情報と照合し、実際の障害リスクを評価。

  3. 美しいWebダッシュボードと通知機能
    上記内容を、わかりやすいWebインターフェイスで表示するとともに、必要な内容をお好みの方法で通知してくれます。

Webダッシュボード：

メインのダッシュボードはこのように分かりやすい表示です。
（1つのHDDのが「Failed」となっていますが。。。）
上半分に各Storageデバイスの状況が表示され、下半分にHDD・SSDの温度の推移がグラフとして表示されています。

ストレージの状況を一目で確認できる

FailedとなっているHDDの詳細はこちら。S.M.A.R.T.の情報で「Command Timeout」の回数が異常に発生していますが、HDDは問題なく機能しています。

Command Timeoutの異常値

導入と設定

非常に簡単なので、要点のみ説明します。

TrueNASへの導入

  • TrueNASのApp Marketから「Scrutiny」をインストール

    • Additional Environment Variablesに下記を追加

      • 名称：COLLECTOR_CRON_SCHEDULE

      • 値：0 * * * *　（通知のタイミングを設定）

    • それ以外はデフォルトのままでもOK

Scrutinyの設定

  • 設定ファイルの作成
    ScrutinyのGitHubを参照して、下記2つのファイルを作成します。
    基本的に用意されている内容をコピーするだけでOKですが、通知部分は編集が必要です。（GUIになっていると良いのですが）

    • scrunity.yaml
      主要な設定をするファイルです。ここでは「通知方法」を設定します。

      • notify:　→　#コメントアウトを取る

      • urls:　→　#コメントアウトを取る

      • お好みの通知方法を設定　→　#コメントアウトを取り、設定する
        設定内容は下に補足しています。

    • collector.yaml
      対象のデバイスの詳細設定や、複数ホストをまとめて管理する（ハブ＆スポーク構成）場合に使用します。今回は特に設定していません。必要に応じて編集してください。

補足：Scrutinyには多様な通知方法が用意されています。
　　スクリプトの実行なども可能となっています。

  • scrunity.yamlによる通知の設定例

    • 例１：Discordへの通知
      Discordの自分のサーバーでWebhookを作成。
      WebhookのURLから「token」と「webhookid」をセットする

    • 例２：Slackへの通知
      SlackのYour Appから「Bot User OAuth Token」を作成し、「Bot Name」 と「Token」をセットする

    • 例３：SMTP通知（メール）
      Gmailの場合は、App パスワードを作成し、「Mailアドレス」「パスワード」「smtp.gmail.com」「587」と「送信元」「通知先」をセットする

#notify:
#  urls:
#    - "discord://token@webhookid"
#    - "telegram://token@telegram?channels=channel-1[,channel-2,...]"
#    - "pushover://shoutrrr:apiToken@userKey/?priority=1&devices=device1[,device2, ...]"
#    - "slack://[botname@]token-a/token-b/token-c"
#    - "smtp://username:password@host:port/?fromAddress=fromAddress&toAddresses=recipient1[,recipient2,...]"
#    - "teams://token-a/token-b/token-c"
#    - "gotify://gotify-host/token"
#    - "pushbullet://api-token[/device/#channel/email]"
#    - "ifttt://key/?events=event1[,event2,...]&value1=value1&value2=value2&value3=value3"
#    - "mattermost://[username@]mattermost-host/token[/channel]"
#    - "ntfy://username:password@host:port/topic"
#    - "hangouts://chat.googleapis.com/v1/spaces/FOO/messages?key=bar&token=baz"
#    - "zulip://bot-mail:bot-key@zulip-domain/?stream=name-or-id&topic=name"
#    - "join://shoutrrr:api-key@join/?devices=device1[,device2, ...][&icon=icon][&title=title]"
#    - "script:///file/path/on/disk"
#    - "https://www.example.com/path"

  • マウント先に設定ファイルを追加
    TrueNASのアプリ一覧の画面で、Scrutinyのマウント先を確認します。
    設定ファイルを置くのは「/opt/scrutiny/config」なので、そちらにbindされている「/mnt/App/config/scrutiny」に、上記で作成した2つの設定ファイルを配置します。
    ぶっちゃけ、nanoで直接作成して貼り付けるのが一番簡単です。

フォルダの形のアイコンをクリック
「/opt/scrutiny/config」にbindされているディレクトリを確認

  • Scrutinyを再起動すれば設定が反映されているはずです。

通知のテスト

設定が正しく反映されて、通知が届くか確認します。
設定した方法で通知が届けばOKです。

  • コマンドラインからScrunityのAPIを呼び出す方法。

curl -X POST http://（ホスト）:（ポート）/api/health/notify

  • Dockerの中に入り、下記コマンドで直接実行することも可能です。

/opt/scrutiny/bin/scrutiny-collector-metrics run

2026/xx/xx xx:xx:xx Loading configuration file: /opt/scrutiny/config/collector.yaml

 ___   ___  ____  __  __  ____  ____  _  _  _  _
/ __) / __)(  _ \(  )(  )(_  _)(_  _)( \( )( \/ )
\__ \( (__  )   / )(__)(   )(   _)(_  )  (  \  /
(___/ \___)(_)\_)(______) (__) (____)(_)\_) (__)
AnalogJ/scrutiny/metrics                                dev-0.8.6

INFO[0000] Verifying required tools                      type=metrics
INFO[0000] Executing command: smartctl --scan --json     type=metrics
INFO[0000] Executing command: smartctl --info --json /dev/sda  type=metrics
INFO[0000] Generating WWN                                type=metrics
INFO[0000] Executing command: smartctl --info --json /dev/sdb  type=metrics
INFO[0000] Generating WWN                                type=metrics
INFO[0000] Executing command: smartctl --info --json /dev/sdc  type=metrics
INFO[0000] Generating WWN                                type=metrics
INFO[0000] Executing command: smartctl --info --json /dev/sdd  type=metrics
INFO[0000] Generating WWN                                type=metrics
INFO[0000] Executing command: smartctl --info --json --device nvme /dev/nvme0  type=metrics
INFO[0000] Using WWN Fallback                            type=metrics
INFO[0000] Executing command: smartctl --info --json --device nvme /dev/nvme1  type=metrics
INFO[0000] Using WWN Fallback                            type=metrics
INFO[0000] Sending detected devices to API, for filtering & validation  type=metrics
INFO[0000] Collecting smartctl results for sda           type=metrics
INFO[0000] Executing command: smartctl --xall --json --device sat /dev/sda  type=metrics
INFO[0000] Publishing smartctl results for 0x5000c500e37aaf69  type=metrics
INFO[0001] Collecting smartctl results for sdb           type=metrics
INFO[0001] Executing command: smartctl --xall --json --device sat /dev/sdb  type=metrics
INFO[0002] Publishing smartctl results for 0x50024e920179ce90  type=metrics
INFO[0002] Collecting smartctl results for sdc           type=metrics
INFO[0002] Executing command: smartctl --xall --json --device sat /dev/sdc  type=metrics
INFO[0002] Publishing smartctl results for 0x5000c500e9f34108  type=metrics
INFO[0002] Collecting smartctl results for sdd           type=metrics
INFO[0002] Executing command: smartctl --xall --json --device sat /dev/sdd  type=metrics
INFO[0002] Publishing smartctl results for 0x5000c500e9f9fe6f  type=metrics
INFO[0003] Collecting smartctl results for nvme0         type=metrics
INFO[0003] Executing command: smartctl --xall --json --device nvme /dev/nvme0  type=metrics
INFO[0003] Publishing smartctl results for 2444cw400178  type=metrics
INFO[0003] Collecting smartctl results for nvme1         type=metrics
INFO[0003] Executing command: smartctl --xall --json --device nvme /dev/nvme1  type=metrics
INFO[0003] Publishing smartctl results for 2444cw402050  type=metrics
INFO[0003] Main: Completed                               type=metrics

これで、何か異常があったときには通知が来るようになります。

Scrutinyは必要か？

ここまで書いておいて本末転倒な意見ですが、私は別に使わなくても良いかなと考えています。

Scrutinyの導入目的は「ストレージの突然死を予兆する」ことです。そのために、S.M.A.R.T.情報だけでなく、Backblaze社の統計情報も使って分析することを否定するわけではないのですが、そもそものS.M.A.R.T.情報はどこまで信頼できるのか、という点が問題です。

S.M.A.R.T. の信頼性

私の一つのHDDは、Scrutinyを使うと「Failed」となっており交換が必要な状況です。ですが、私はその背景の理由を知っています。一時期、旧NASに突っ込んでいたのですが、正しいセットアップができていないまま長時間放置していました。その間「Command Timeout」の状況が積み重なって異常データとなっていますが、HDDとしてのRead / Writeは全く問題がなく使えています。こうなるとS.M.A.R.T.の情報がノイズとなってしまいます。

その他、半年以上前から常時起動している2本のSSDの通電時間が58 Daysとなっていたり、S.M.A.R.T.って信用に値する情報なのかが微妙だなと考えています。

S.M.A.R.T. リセット問題

最近は、HDDの再生品というものも市場に出回っています。HDDの耐久性が上がったからなのか、一度別の用途に使用されたHDDを、S.M.A.R.T.情報をリセットして販売しているケースがあるようです。そうなってくると、そもそもS.M.A.R.T.の情報が正しいのかどうか判断はつかないのではないでしょうか。（私は上記のCommand Timeoutをリセットしたいですが）

TrueNASによる包括的なデータ保護で事足りる

TrueNASを使う理由の一つに、データ整合性をしっかりと確認してくれるという点があります。これはzfsの機能なのでTrueNASに限った話ではないのですが、HDD自体に問題が無くても、他のI/Oのエラーに起因するデータエラーも全て検出され、書き込んだデータが正しく読み出しできることを担保してくれます。
その他、HDDの定期的なスクラブや、スナップショット、RAID機能などを全て含めて包括的にデータを保護するための機能を提供してくれるTrueNASというプラットフォームがあれば、十分ではないかと考えています。

Scrutinyの意義

もちろん、S.M.A.R.T.情報の確認が無意味では無いと思います。正しい状況（リセットされていない）にて提供された情報であれば、一定の意味はあると思うのですが、あくまでも参考情報でありNice to Haveでしかないというのが私の理解です。

それよりも、複数のバックアップを異なるメディアに取得して、できればリモートにも置いておく、という3-2-1バックアップルールを実践するほうがよほど現実的な対策だと思います。Storageデバイスはいつか必ず壊れます。その前提で大切なデータを失わないための施策が重要ということです。

TrueNASのForumなどでも議論がされていますが、いままでのファイルサーバー等はS.M.A.R.T.で健康状態を管理するのが定番になっていましたので、ScrutinyはS.M.A.R.T.が無いと不安だという方のためのアプリです。

入れておいて損は無いと思いますが、入れなくても問題はありません。
TrueNASが優秀なので、エラーがあればTrueNASが気がついて通知してくれます。大切なのは、適切なバックアップ体制と、優秀なデータ管理プラットフォームということで、本件は一旦終わりにしたいと思います。

Minisforum N5 Proのデータ障害

余談ですが、このNoteで推しているMinisforum N5のPro版ではHDDのデータエラーが出るということで昨年末頃から情報が錯綜していました。元々そのエラーを発見できたのはzfsの機能によるもので、S.M.A.R.T.や他のext4等のフォーマットでは気がつくことも出来なかったと思われます。

Minisforum N5 Proのデータエラーですが、実態としてはHDDののエラーではなく、特定条件下におけるDMAの誤動作であることが解ってきました。
一時期はSATAコントローラーであるJMB585が原因ともされましたが濡れ衣っぽいです。同じチップを使っているMinisforum N5（無印）ではエラーは発生していません。無印とProの違いは、CPUとECCメモリー対応、PCIeレーン等のマザーボード構成くらいなので、そのあたりが原因だとは思います。

現時点では、kernelのIOMMUの設定でDMAをバイパスしてしまえば問題は発生しないようです。（検知出来ないだけとも言う？）この『至高の自宅サーバー』ではGPUパススルーのためにIOMMUを設定しているので、その関係でエラーが検知できていないだけなのか気にはなります。
根本的な原因が判らないため、早く真相を解明して欲しいところです。

いいなと思ったら応援しよう！