ホームサーバー向けRAID監視ツール ベスト10

RAIDアレイは正常に見えても、そのドライブの1台がひそかに劣化していることがあります。また、残りのディスクがSMARTで「PASSED」と報告していても、アレイが劣化する場合があります。

したがって、優れた監視には緑色のステータスランプが1つあるだけでは不十分です。最適なホームサーバー環境では、アレイ、物理ドライブ、リビルドやスクラブ、そして何かが変化したことを知らせるアラートを監視します。

RAID監視はSMARTだけではありません

RAIDの健全性とディスクの健全性は、異なる問いに答えるものです。

アレイ監視は、ストレージシステムに想定されたメンバーがまだ存在するか、冗長性が失われているか、リビルド、再同期、スクラブ、整合性処理が実行中かどうかを知らせます。

SMART監視は、アレイの下層にある個々のHDD、SSD、NVMeドライブを監視します。温度、メディアエラー、保留中のセクター、再割り当てセクター、耐久性、セルフテスト結果など、デバイスレベルのシグナルを明らかにできます。

RAID監視
     |
     +-- アレイの状態
     |     正常 / 劣化 / オフライン
     |
     +-- ドライブの健全性
     |     SMART / NVMe / 温度
     |
     +-- 復旧
     |     リビルド / 再同期 / スクラブ
     |
     +-- 履歴
     |     傾向 / エラー / 容量
     |
     +-- アラート
           メール / プッシュ通知 / Webhook / チャット

この違いは重要です。正常なアレイにも劣化しているドライブが含まれることがあり、一方で劣化したアレイでも、個々のディスクのSMARTステータスが正常のままの場合があるためです。

基盤となるRAIDモデルについては、RAIDの仕組みで詳しく説明していますが、監視はもっと単純なルールから始まります。アレイと、その下層にあるドライブの両方を監視することです。

RAID監視ツールは実際に何を監視すべきか？

優れたホームサーバー監視ツールは、用途に必要なだけ、これらのレイヤーをできる限り多くカバーすべきです。

最適なRAID監視ツールの評価方法

これは、見た目の美しいダッシュボードのランキングではありません。以下のツールは、監視スタックの異なる部分を解決します。

実用的な5つの疑問を基準に評価しました。

• 実際に何を監視できるのでしょうか？ アレイの状態、個々のディスク、ZFSプール、ハードウェアRAID、それともサーバー全体でしょうか？
• 履歴を保持できますか？エラー数が徐々に増加していることは、現在の単一の値よりも有用な場合がよくあります。
• 手動で確認しなくてもアラートを出せますか？監視では問題を事前に表面化できるべきです。
• 導入はどの程度難しいですか？ユーザーが望まない限り、1台のホームNASにエンタープライズ向けのオブザーバビリティ基盤を必要とすべきではありません。
• ネイティブのRAIDツールを補完できますか？最も優れた構成では通常、アレイ専用の監視ツールとディスク健全性レイヤーを組み合わせます。

番号の順序は編集上のものであり、合成ベンチマークのスコアではありません。

一目でわかるホームサーバー向けRAID監視ツール10選

1. Netdata — 総合的に最適なRAID監視ダッシュボード

ストレージシステムとホームサーバーの残りの部分を1つの監視レイヤーで管理したい場合、Netdataが総合的に最も優れた選択肢です。

現在のストレージコレクターは、RAIDユーザーに関連する複数のアーキテクチャをカバーしています。

LinuxソフトウェアRAIDでは、MD RAIDコレクターが/proc/mdstatを読み取り、MDデバイスを追跡します。物理ドライブについては、NetdataにsmartctlベースのSMARTコレクターがあります。そのZFSプールコレクターはzpoolを通じてプールの健全性と容量を監視し、StoreCLI RAIDコレクターは、対応するハードウェアRAIDアダプター、物理ドライブ、バックアップバッテリーを監視できます。

この幅広さにより、Netdataは特定のSMARTダッシュボードに対して優位性を持ちます。

MD RAID
SMART
ZFS
ハードウェアRAID
ファイルシステム
CPU
RAM
ネットワーク
コンテナ
     |
  Netdata
     |
1つのダッシュボード

1つのNetdata Agentは独立して動作し、ローカルダッシュボードを次のポートで公開できます 19999監視エージェント自体でのクラウド接続は任意ですが、Netdata Cloudを追加すると、集中管理ビューや複数ノードの追加機能を利用できます。

これによりNetdataは、ストレージ監視をシステム負荷、RAM使用圧、ファイルシステム容量、Dockerのアクティビティ、ネットワークパフォーマンスと並べて確認したいホームサーバーで、特に役立ちます。

最適な用途： RAIDとサーバーのその他の要素を1つのダッシュボードで確認したいユーザー。

トレードオフ： Netdataは、ディスクに特化しているというより、幅広い監視に対応します。SMART属性や長期的な物理ドライブの劣化を詳しく調べたい場合は、Scrutinyのほうが見やすくなります。

2. Scrutiny — ドライブの健全性トレンドの把握に最適

Scrutinyは、SMARTの生データによる監視の弱点をいくつも解決するため、ホームNASへの追加機能として非常に有用です。

SMARTは多数の属性を公開しますが、すべての属性が同じように有用とは限りません。メーカーのしきい値が保守的すぎる場合もあり、故障が比較的近づくまでドライブが「正常」に見えることがあります。

ScrutinyはSMARTデータにWeb UI、履歴トレンドの保存、温度追跡、さらに実際のドライブ故障データに基づく追加のしきい値を組み合わせています。

これにより、次のような疑問を持てるようになります。

現在保留中のセクタ

1月       0
3月         0
6月          2
8月        8

現在のSMARTレポートだけを見ると、その値が8であることしか分かりません。Scrutinyなら、その指標が悪い方向に推移していることが分かります。

また、メール、Webhook、ntfy、Gotify、Slack、Discord、Telegramなどを通じた、設定可能な通知にも対応しています。

RAIDコントローラーのサポートは、次の点に左右されます。 smartctl 基盤となる物理ドライブにアクセスできます。そのため、ScrutinyではコントローラーのパススルーとDockerのデバイスマッピングについて説明しています。

重要な制限事項は、同様に明確です。

Scrutinyはドライブを監視しますが、RAIDアレイ自体は監視しません。

Linux MDアレイは、引き続きmdadmなどのアレイ対応レイヤーで監視すべきです。ZFSプールには、引き続きZFS固有の監視が必要です。

最適な用途： SMARTや温度の履歴トレンドが重要な、複数のHDDまたはSSDを搭載したホームサーバー。

トレードオフ： Scrutinyでディスクがすべて正常に見えても、RAIDアレイが健全だという証拠と誤解しないでください。

ドライブの健全性を監視する層は、ドライブそのものにも依存します。適切なNASドライブを選ぶことで、再構築中や24時間365日の連続稼働で避けられる問題を減らせます。

3. smartmontools — HDD・SSD・NVMe監視の最良の基盤

smartmontoolsはScrutinyほど視覚的に魅力的ではありませんが、より基盤的な存在です。

このプロジェクトには、2つの主要ツールがあります。

smartctl
   |
ドライブを検査・テスト

smartd
   |
ドライブを継続的に監視

smartctl ATA/SATA、SCSI/SAS、NVMeデバイスのSMARTおよび健全性情報を検査し、ドライブのセルフテストを開始できます。 smartd デーモンとして動作し、設定された健全性条件を満たしているかデバイスを継続的にチェックします。

多くの高レベルな監視製品は、最終的にこのデータに依存しています。NetdataのSMARTコレクターにはsmartmontoolsが必要で、Scrutinyはsmartctlのデータを基盤にディスクの状態監視レイヤーを構築し、Prometheusのsmartctlエクスポーターも同じインターフェースを使用します。

このプロジェクトは現在も進化しています。現在の上流変更履歴には、7.5に続く次の未リリース世代としてsmartmontools 8.0が記載されています。

軽量なホームサーバーでは、smartdだけで十分な場合があります。

ドライブ
  |
SMART
  |
smartd
  |
アラート

ドライブが重要なしきい値を超えたことを知るために、必ずしも別のデータベース、ダッシュボード、メトリクススタックが必要なわけではありません。

最適な用途：物理ドライブの状態監視と自動テストのための、軽量で成熟した基盤を求めるユーザー。

トレードオフ：コマンドライン出力はScrutinyやCockpitほど扱いやすくなく、smartd単体では同等の視覚的な履歴分析を提供できません。

4. mdadm Monitor — LinuxソフトウェアRAID向け最適なネイティブモニター

アレイがLinux MD RAIDの場合、Netdataや別のダッシュボードを導入していても、監視計画の一部としてmdadmを引き続き使用すべきです。

mdadm --monitor アレイ自体を認識します。

次のようなイベントを報告できます。

• デバイス障害；
• 劣化したアレイ；
• スペアの有効化；
• デバイスの消失；
• 再構築の開始；
• 再構築の進行状況；
• 再構築の完了。

SMARTが補えない部分を埋めるのは、次のような情報です。

smartd
  |
ドライブは正常ですか？

mdadm --monitor
  |
RAIDアレイは正常ですか？

最小構成のLinuxホームサーバーでは、mdadmの監視とsmartdを組み合わせることで、大規模なWebスタックを追加せずに、驚くほど高機能な監視システムを構築できます。

最適な用途：MD RAID 1、5、6、または10を中心に構築されたDebian、Ubuntu、その他のLinuxサーバー。

トレードオフ：mdadmはZFS、ハードウェアRAID、またはグラフィカルな長期分析ではなく、LinuxソフトウェアRAIDに重点を置いています。

5. OpenZFS ZED — ZFSプール向け最適なネイティブイベント監視

ZFSユーザーは、すべてのイベントを従来のRAID用語に対応付けようとするのではなく、ZFSをZFSとして監視すべきです。

ZED（ZFSイベントデーモン）は、ZFSカーネルモジュールが生成するイベントを監視し、一致するイベントクラスが現れると、設定済みのZEDLETアクションを実行します。

監視の関係は次のようになります。

ZFSカーネル
    |
  zevents
    |
   ZED
    |
ZEDLETアクション
    |
通知／自動化

このため、ZEDは外部ディスクダッシュボードではなく、ZFS自体に属するプールおよびデバイスのイベントに適しています。

そのため、完全なZFSホームサーバースタックには次のような要素が含まれる場合があります。

ZED
 |
プールイベント

smartd／Scrutiny
 |
物理ドライブの健全性

Netdata／Grafana
 |
ダッシュボードと履歴

最適なユーザー：TrueNASスタイル、OpenZFS、またはLinux／BSDのZFSユーザーで、プール周辺のネイティブなイベント処理を求める人。

トレードオフ：ZEDはイベントデーモンであり、洗練されたオールインワンダッシュボードではありません。長期的な可視化が必要なら、別のレイヤーと組み合わせてください。

6. Cockpit Storage — Linux初心者向けのRAID監視GUI

Cockpitは、通常のLinuxサーバーにブラウザーベースの管理インターフェースを追加する最も簡単な方法の1つです。

Storageアプリケーションは、ローカルディスク、パーティション、RAID、暗号化、NFS、iSCSIなど、一般的なストレージ操作に対応しています。

CockpitはStorageページにSMARTデバイスの健全性情報も追加しており、ブラウザーからディスクの自己診断テストを実行できます。

そのため、次のようなサーバーに対する初心者向けの有力な選択肢になります。

Ubuntu／Debian／Fedora
          |
       Cockpit
          |
 ブラウザーストレージUI
          |
 RAID＋SMART＋マウント

専用の可観測性スタックを構築するよりも、ストレージを管理したいユーザーにとって特に便利です。

最適なユーザー：クリーンなサーバー管理UI内でRAIDとディスクの状態を確認したいLinux初心者。

トレードオフ：Cockpitは、現在のサーバー状態の表示・管理には優れていますが、数か月分の詳細なSMART履歴を保存する用途には向いていません。

7. Prometheus＋smartctl_exporter＋Grafana — 長期的なメトリクスに最適

監視そのものが趣味になっているなら、Prometheusスタックのほうが、専用NASダッシュボードよりはるかに細かく制御できます。

公式 smartctl_exporter smartctlの統計情報をPrometheusメトリクスに変換します。smartctlのJSON出力に依存するため、smartmontools 7.0以降が必要です。

アーキテクチャはモジュール式です。

SMART／RAID／ZFSエクスポーター
           |
       Prometheus
           |
         Grafana
           |
 ダッシュボード＋アラート

追加のエクスポーターやノードメトリクスによって、次の情報も追加できます。

• ファイルシステム容量。
• ディスクI/O。
• ZFSプール。
• MD RAIDの状態。
• 温度。
• サーバー負荷。
• UPSのメトリクス。
• ネットワークアクティビティ。

これは、現在の健全性を確認するだけでなく、過去の状況について質問に答えたい場合に最も強力な選択肢です。

たとえば、次のようなことです。

• 直近のRAID再構築中に、ドライブの温度は上昇しましたか？
• 訂正不能エラーが最初に発生したのはいつですか？
• 別のドライブを追加した後、ストレージのレイテンシーは変化しましたか？
• 過去1年間でプールの使用率はどのくらい増加しましたか？

Grafana Alertingでは、Prometheusベースのルールを評価し、条件を満たしたときに通知を振り分けることもできます。

最適な用途: 長期的なメトリクス、カスタムダッシュボード、相関分析、柔軟なアラートを求める愛好家。

トレードオフ: Prometheus + エクスポーター + Grafanaは、ScrutinyやNetdataよりも大幅に多くの設定が必要です。シンプルなホームNASが1台だけの場合、その複雑さに見合う実用的なメリットがほとんどない可能性があります。

8. Checkmk — 複数のホームサーバーの監視に最適

Checkmkは、ホームラボに複数のマシンがある場合に、より魅力的な選択肢になります。

NASだけに注目するのではなく、次のような機器があるかもしれません。

NAS
バックアップサーバー
Proxmoxホスト
ミニPC
ルーター
UPS
スイッチ
     |
   Checkmk

Checkmk Linuxエージェントは、プラグインを通じたハードウェア監視に対応しており、最新のHDDやSSDのSMART値も取得できます。

また、対応するRAIDコントローラーの背後に隠れているドライブも明示的に考慮されています。コントローラーによっては、次のようなツールが必要です。 smartmontools, tw_cliまたは、Checkmkが基盤となるデバイス情報にアクセスする前に、MegaRAIDユーティリティが必要になる場合があります。

さらに大きな利点は運用の一元化です。複数のホスト、サービスの状態、アラートルール、グラフ、インベントリ、容量、システム監視をすべて1つのインターフェースに集約できます。

最適な用途: 複数のLinuxサーバーやインフラ機器と併せてストレージの健全性を監視する必要があるホームラボ。

トレードオフ: NetdataやOS標準の監視ですでに重要な障害兆候を把握できる単一のNASでは、Checkmkは不要なオーバーヘッドになります。

9. StorCLI — LSIおよびBroadcomのハードウェアRAIDに最適

ハードウェアRAIDでは、オペレーティングシステムからは1台の仮想ディスクに見えていても、コントローラーがその下で複数の物理ドライブを管理している場合があるため、監視に対する考え方を変える必要があります。

オペレーティングシステム
      |
 仮想ドライブ
      |
 RAIDコントローラー
      |
+-----+-----+-----+
ディスク 1   ディスク 2  ディスク 3

StorCLIは、対応するLSI/Broadcom RAIDコントローラー向けのBroadcom製コマンドライン管理ユーティリティです。

コントローラーの状態、仮想ドライブ、物理ドライブ、再構築処理、エンクロージャー情報、キャッシュ、対応するバッテリーまたはバックアップコンポーネントを確認できます。

ハードウェアRAIDの状態には、次のようなものがあります。

• 最適。
• 部分的にデグレード。
• デグレード。
• オフライン。

このコントローラーレベルの可視性は不可欠です。汎用的なSMARTツールでは、すべてのRAIDコントローラーを介してメンバードライブを自動的に検出できるとは限らないためです。

有用な監視の組み合わせは次のとおりです。

Broadcom / LSI RAID
        |
      StorCLI
        |
     Netdata
        |
ダッシュボード＋アラート

NetdataのStoreCLIコレクターはコントローラー情報を取得し、他のサーバーメトリクスと並べて表示できます。

最適な用途：Broadcom、LSI、MegaRAIDの対応ハードウェアコントローラーを使用するホームサーバー。

トレードオフ：StorCLIは汎用的なホームサーバーダッシュボードではなく、コントローラー固有の管理ツールです。

10. Zabbix — 高度なRAIDアラートと自動化に最適

Zabbixは、このリストで最もインフラ向けの選択肢です。

現在のAgent 2テンプレートには公式のSMART監視が含まれており、アレイやコントローラーの状態は、環境に適したサポート対象の統合機能、カスタムアイテム、スクリプト、テンプレートを通じて追加できます。

大規模なZabbix環境では、次の要素を組み合わせられます。

SMART
RAID
ZFS
ファイルシステム
UPS
温度
ネットワーク
サービス
     |
   Zabbix
     |
履歴
トリガー
通知
エスカレーション

強みは、RAID専用画面にあるのではありません。何を障害とみなすか、そしてその後に何を実行するかを正確に定義できる点にあります。

たとえば、ある警告を通常の通知チャンネルに振り分け、アレイのデグレードや仮想ディスクのオフラインを、より緊急度の高いエスカレーションの対象にできます。

最適な用途：すでにZabbixを運用している上級ユーザー、または複数システムにわたる詳細なアラートルールと自動化を求めるユーザー。

トレードオフ：セットアップの複雑さが高い。1台のホームNASにある2台のディスクだけを監視するためにZabbixを導入するのは、通常は不要です。

実際に使うべきRAID監視ツールはどれ？

RAIDの健全性とSMARTの健全性：同じものではありません

この違いは、ランキング上位の多くのツールのどれを選ぶかよりも重要です。

有用な例を挙げると、次のようになります。

mdadm：
アレイ正常

Scrutiny：
ディスク3
現在保留中のセクター数 = 0 → 2 → 8

アレイはまだ故障していなくても、物理ドライブの履歴から調査すべき理由がわかることがあります。

逆のことも起こり得ます。

mdadm：
アレイ低下

smartctl：
ディスク1：合格
ディスク2：合格
ディスク3：合格

見つからないメンバーは、SMARTの障害しきい値では示されない、ケーブル接続、電源、コントローラー、デバイス列挙、またはその他の障害が原因で消失した可能性があります。

mdadm対ZFS対ハードウェアRAIDの監視

適切な監視ツールは、RAIDのロジックがどこにあるかにも左右されます。

これが、ストレージレイアウトが監視アーキテクチャに影響する理由です。ソフトウェアRAID、ZFS、ハードウェアRAIDは、それぞれ異なる制御レイヤーを通じて異なる状態を公開します。

ScrutinyとNetdata：どちらをインストールすべき？

相互に対抗するよりも、組み合わせたほうがうまく機能します。

そのため、ホームサーバーでのわかりやすい組み合わせは次のとおりです。

Netdata
  |
アレイとサーバーの状態

Scrutiny
  |
物理ドライブの推移

アプリケーションを1つだけ使いたいなら、Netdataはより多くのレイヤーをカバーします。

NASのOSがすでにアレイの状態を適切に監視しているなら、Scrutinyは物理ディスクの履歴をより詳しく確認できるため、新しい情報を追加できる可能性があります。

ホームNASにPrometheusとGrafanaは必要ですか？

通常は必要ありません。

要件が次の2つだけなら：

RAIDがデグレードしたときに知らせて
ディスクが故障しているときに知らせて

ネイティブのアレイアラートに加えてsmartd、Scrutiny、またはNetdataを使えば、はるかに少ないインフラでこの問題を解決できます。

次の点を重視するなら、PrometheusとGrafanaが適しています。

• 数か月または数年分の履歴。
• 複数のサーバー。
• カスタムダッシュボード。
• 温度とI/Oを関連付ける。
• ストレージの増加を追跡する。
• RAIDとUPS、ネットワーク、Docker、ホストのメトリクスを組み合わせる。
• カスタムPromQLアラートルール。

Grafanaをインストールする間違った理由は、単にダッシュボードが impressive に見えるからです。

正しい理由は、時系列の履歴を必要とする疑問があることです。

どのRAIDアラートを設定すべきか？

監視が役立つのは、最初にダッシュボードを開かなくても何かがあなたに届く場合だけです。

アレイのアラート

• アレイがデグレード。
• アレイがオフライン。
• 予期しないメンバーが見つからない。
• スペアが有効化された。
• 再構築または再同期が開始された。
• 再構築に失敗した。
• 再構築が完了した。

物理ドライブのアラート

• SMARTの総合ヘルスが失敗を示した。
• 現在保留中のセクター数が増加した。
• オフライン訂正不能セクター数が増加した。
• 再割り当てセクター数が大幅に増加した。
• NVMeの重大な警告。
• SSDの耐久性または摩耗が交換レベルに近づいている。
• ドライブ温度が想定範囲外の状態で推移している。

ZFSのアラート

• プールがデグレード。
• デバイス障害。
• チェックサムエラーが増加した。
• スクラブでエラーが検出された。
• リシルバーが開始または失敗した。
• プール容量が設定したしきい値に近づいた。

ハードウェアRAIDのアラート

• 物理ドライブが故障。
• 仮想ドライブがデグレード。
• 仮想ドライブがオフライン。
• 再構築が停止または失敗した。
• コントローラーキャッシュまたはバックアップバッテリーの障害。

正確な温度とSMARTのしきい値を、別のサーバーから盲目的にコピーしてはいけません。ドライブのモデルによって公開される属性や動作範囲は異なります。

より重要なのは、その原則です。

一度も開かないダッシュボードは、監視とは言えません。

SMARTテストとスクラブと再構築：異なる3つの役割

これらの操作は混同されがちですが、検査する対象はそれぞれ異なります。

SMARTセルフテスト

SMARTセルフテストは、個々のストレージデバイスで実行されます。

1台のドライブ
   |
SMARTテスト
   |
デバイスレベルの結果

長時間のSMARTテストは短時間のテストよりもドライブ表面を広範囲にスキャンできますが、RAIDのパリティや、ストレージシステム全体にわたるZFSのデータコピーを検証するものではありません。

RAID Rebuild or Resync

RAIDの再構築または再同期

再構築により、障害または交換されたメンバーの後で冗長性が復元されます。
     |
劣化したRAID
     |
交換用ドライブ
     |
再構築／再同期

冗長性が復元されました

これはディスクの健全性テストではなく、復旧処理です。

ZFSスクラブまたはRAID整合性チェック

これは別の問いに答えるものです。

そのため、ストレージアーキテクチャが3つすべてに対応している場合は、監視で3つすべてを確認できるようにする必要があります。

別のダッシュボードを導入する前にNAS標準のアラートを有効にする

専用のNASオペレーティングシステムには、必要な最初の監視レイヤーがすでに備わっている場合があります。

たとえば、現在のZimaOSのストレージ管理画面では、Settings > Storageでアレイの状態、ドライブの健全性、使用可能容量、読み取り／書き込み速度を確認できます。RAIDメンバーの1台に障害が発生すると、アレイは劣化状態になり、ドライブ交換後の再構築をユーザーに案内する復旧ワークフローが表示されます。

ZimaOSでは、ストレージインターフェースに長時間実行されるRAIDおよびパリティチェックの進捗状況と、詳細なディスク健全性情報も表示されます。

したがって、実際の順序は次のようになります。

1. NAS標準のアラートを有効にする
        |
2. 劣化アレイの検出を確認する
        |
3. 物理ドライブの履歴を追加する
        |
4. 必要な場合にのみ、より大規模な可観測性スタックを追加する

TrueNAS、Unraid、Synology、QNAPなどのNASプラットフォームにも、同様に標準のストレージ健全性機能が備わっています。2つ目の監視システムを追加する前に、これらを設定しておくべきです。

追加するレイヤーは、標準UIでは十分に答えられない質問に答えられるものであるべきです。

RAID監視はバックアップの代わりにはならない

完全なアラートがあれば、ディスクの故障を数秒以内に知らせることができます。

削除したフォルダーの昨日のバージョンを復元することはできません。

ランサムウェアによってすでに暗号化されたファイルを復旧することはできません。

盗難、火災、または壊滅的なコントローラー障害の後に、NASを再構築することはできません。

だからこそ、RAIDはバックアップではありません。

RAID
  |
一部のドライブ障害後も可用性を維持する

監視
  |
問題をすばやく検出する

バックアップ
  |
失われたデータや破損したデータを復旧する

3つとも、信頼性の問題の異なる部分を解決します。

再構築中は、残りのドライブが継続的に稼働し、冗長性が低下するため、監視が特に重要になります。その期間中に予期せぬ停電が発生すると、さらに別のリスクが加わります。そのため、ストレージ処理中のUPSによる保護は、ドライブの健全性監視とは別に重要です。

おすすめのRAID監視構成

シンプルなLinux RAIDサーバー

mdadm --monitor
       +
     smartd

これは軽量な選択肢です。

mdadmがLinuxアレイを監視し、smartdがディスクを監視します。どちらも大規模なWebプラットフォームを必要としません。

簡単なホームNAS

NASネイティブの監視
         +
      Scrutiny

NASインターフェースがアレイの状態と再構築を処理し、Scrutinyがドライブの健全性履歴と通知を追加します。

一般的なLinuxホームサーバー

Netdata
   +
Scrutiny

Netdataはアレイとサーバー全体を監視します。Scrutinyは物理ドライブのより詳細な履歴を提供します。

ZFSホームサーバー

ZED
 +
Scrutiny
 +
Netdata

ZEDがZFSネイティブのイベントを処理し、Scrutinyがドライブの傾向を監視し、Netdataがシステム全体をより広く把握できるダッシュボードを提供します。

高度なホームラボ

smartctl_exporter
MD / ZFSエクスポーター
node_exporter
      |
  Prometheus
      |
   Grafana
      |
アラート

これは、メトリクスの履歴と複数サーバーの監視が、完全なオブザーバビリティスタックの維持を正当化するほど重要な場合に適しています。

ハードウェアRAIDサーバー

StorCLI
   |
Netdata / Checkmk
   |
アラート＋ダッシュボード

ハードウェアRAID層の真の基準はコントローラーユーティリティであり、監視プラットフォームはその状態を見える化し、対応可能にします。

最終結論

Netdataは、ほとんどのホームサーバーに最適な総合RAID監視ツールです

個々のドライブの履歴が重要な場合、Scrutinyは最も優れた補完ツールです。アレイ自体が劣化状態に達する前に、SMART属性の緩やかな変化を把握するのに特に役立ちます。

アレイの状態
     +
ドライブの健全性
     +
復旧ステータス
     +
アラート
     +
履歴