はじめに

本稿では、Synology DiskStation Manager（DSM）のSynology Hybrid RAID（SHR）環境において、NetdataのMDアレイに関するアラートが誤検知される問題に焦点を当て、その原因を深く掘り下げ、そして最適な閾値設定を研究します。特に、SHRの特性がNetdataのデフォルト監視に与える影響を解説し、2つの異なる改善案を提示します。

問題の背景とDSM SHRの特性

通常のLinuxシステムにおいて、RAIDアレイのディスクが「ダウン」状態になることは、物理的な故障やディスクの不足を意味し、データ損失のリスクがあるため、緊急性の高い問題として扱われます。Netdataのデフォルト設定も、md.disksチャートの$downメトリクスが0より大きくなるとアラートを発するように定義されています。

しかし、SynologyのDSMで採用されているSHR（Synology Hybrid RAID）は、従来のRAIDとは異なる特性を持ちます。SHRは、異なるサイズのディスクを柔軟に組み合わせてストレージプールを構築し、効率的な容量利用とデータ保護を両立させることを目的としています。このSHRの内部実装において、特にシステムパーティションや一部のデータボリュームを構成するMDアレイ（例: /dev/md0、/dev/md1）は、論理的に最大で26個のような多数のデバイスを期待するメタデータを持つことがあります。

実際の環境では、例えば物理ディスクが2台しか接続されていなくても、cat /proc/mdstatの出力では [26/2] [UU________________________] のように表示されます。これは、「26個の期待されるデバイスのうち、2個がアクティブであり、残りの24個は論理的に不足している（つまり、待機スロットとして扱われている）」状態を示唆します。Netdataは、この「24個の論理的に不足しているデバイス」を「24 failed devices」として認識し、デフォルトの $this > 0 という閾値によってアラートをトリガーします。

この状況は、物理的なディスク故障ではないにもかかわらず、継続的なアラート発生を引き起こし、真の障害検知の妨げとなります。

閾値設定の研究と提案

この問題に対処するため、Netdataのmdstat_disksアラート（/etc/netdata/health.d/mdstat.conf 内で定義）を修正します。キーとなるのは、calc変数の活用と、それに続くwarnおよびcrit閾値の調整です。

共通の修正点：calc変数の活用

どちらの提案も、calc変数を以下の式で修正することで、Netdataが「ダウンデバイス数」として扱う値を、あなたの環境での「真の物理的な故障数」に変換します。これにより、後続のwarnやcritの閾値を通常の意味（>0 や >1）で設定できるようになります。

calc: ($down > 24 ? ($down - 24) : 0)

この計算により、$downが24を超える場合のみ、その超過分（すなわち、論理的不足数を超える物理的故障数）が$thisに代入されます。これにより、$thisは「24個の論理的不足を除いた、実際の物理故障デバイス数」を示します。

提案1（私の案）：物理ディスク1台故障で警告、2台故障で致命的

この案は、一般的なRAID1アレイの耐障害性モデルに沿ったものです。2台の物理ディスクで構成されるRAID1において、1台の故障は「デグレード」状態（冗長性喪失）であり警告を要し、2台の故障は「アレイ停止」であり致命的な問題と見なされます。

template: mdstat_disks
    on: md.disks
    class: Errors
    type: System
    component: RAID
    units: failed devices
    every: 10s # ディスク故障の即時検知を優先

    calc: ($down > 24 ? ($down - 24) : 0) # 24個の論理的不足を除外

    warn: $this > 0 # 物理ディスクが1台でも故障したら警告
    crit: $this > 1 # 物理ディスクが2台以上故障したら危険

    summary: MD array device ${label:device} physical status alert
    info: Number of devices in the down state for the ${label:device} ${label:raid_level} array. \
          Calculated actual physical failed devices: ${this}. \
          (Note: In this specific Synology DSM environment, up to 24 non-active logical devices are considered normal.) \
          A positive 'physical failed devices' count indicates a true hardware degradation.
    to: sysadmin

【評価】

• 利点: 物理ディスク1台の故障で迅速に警告を発するため、最も保守的かつ安全な監視を提供します。冗長性が失われた時点でアラートを出すため、次の故障に備える時間的余裕が生まれます。
• 適用シナリオ: データの整合性と可用性を最優先し、いかなるデグレード状態も見逃したくない場合に最適です。

提案2（ユーザー様の案）：物理ディスク1台故障では警告なし、2台故障で警告、3台以上で致命的

この案は、提案1よりも警告の敷居を高く設定するものです。RAID1の性質上、1台の故障ではまだデータ損失には至らないため、あえて警告をスキップし、より深刻な状態（2台以上の故障）で警告を発することを意図している可能性があります。

template: mdstat_disks
    on: md.disks
    class: Errors
    type: System
    component: RAID
    units: failed devices
    every: 30s # 監視間隔を長めに設定し、負荷軽減を優先

    calc: ($down > 24 ? ($down - 24) : 0)  # SHRの待機ディスクを除外

    warn: $this > 1  # 物理ディスク2台以上故障で警告
    crit: $this > 2  # 物理ディスク3台以上故障で危険

    summary: MD array device ${label:device} down
    info: Number of devices in the down state for the ${label:device} ${label:raid_level} array. \
          Any number > 1 indicates that the array is degraded beyond SHR's normal standby limits.
    to: sysadmin

【評価】

• 利点: 警告の頻度をさらに減らし、RAID1の性質上1台故障ではデータ損失がないという点を重視する場合に有効です。every: 30sと組み合わせることで、Netdataの負荷をわずかに軽減する可能性があります。
• 適用シナリオ: 警告の数を最小限に抑えたい、かつ1台のディスク故障は許容範囲内であり、複数台の故障時のみ迅速な通知が必要な場合に検討されます。ただし、RAID1で2台故障は既に致命的な状態であるため、critの閾値を$this > 1に設定し直す方が一般的なRAID運用の観点からは適切です。RAID1で$this > 2（物理ディスク3台以上の故障）という状態は通常発生しないため、この設定は実質的に機能しません。

結論と推奨

DSM SHR環境におけるNetdataのMDアレイアラートは、論理的なディスク不足による誤検知が原因です。この問題を解決するためには、calc変数で「真の物理的な故障数」を計算し、その値に対して閾値を設定することが不可欠です。

研究の結果、Netdataのデフォルト設定の意図と一般的なRAID1の耐障害性の概念を最も適切に両立させるのは、提案1（私の案）であると結論付けられます。 物理ディスク1台の故障で警告を発することで、冗長性が失われた状態を早期に検知し、データ損失のリスクを最小限に抑えることが可能です。

提案2は、warnとcritの閾値がRAID1の特性と乖離しており、特にcrit: $this > 2は実質的に機能しない可能性が高いため、推奨されません。また、every: 30sは負荷軽減のメリットはありますが、ディスク故障の即時性という点では10sに劣ります。

この研究と提案が、あなたのDSM環境におけるNetdataの監視を最適化し、より信頼性の高いシステム運用に貢献することを願っています。