診断情報の取得

Unraid サーバーで問題が発生した場合、効果的なトラブルシューティングのためには詳細な情報を収集することが重要です。こうした情報は、特にフォーラムに投稿する際に、他のユーザーが正確かつ迅速に支援するのに役立ちます。

Diagnostics 含める...

診断 zip ファイルには、次の内容を含む、Unraid システムの詳細なスナップショットを作成するいくつかの匿名化されたテキストファイルが含まれます:

• システム構成: array、共有、ネットワーク設定、インストール済みプラグインに関する情報。
• システムログ: カーネル、WebGUI、およびシステムサービスのログ。問題の原因につながった可能性のあるイベントを記録します。
• ハードウェア情報: 接続されているドライブ、コントローラー、その他のハードウェアコンポーネントの詳細。
• Docker と VM の情報: Docker と仮想マシンの全体構成（個々のコンテナや %%VM%% に関する情報は含まれません）。

---

システム診断

Unraid では、トラブルシューティングのために包括的なシステム情報を取得できる Diagnostics ツールが、WebGUI の Tools → Diagnostics にあります。このツールは zip ファイルを生成し、ダウンロードしてフォーラム投稿に添付してサポートを受けることができます。診断ファイルはすべてテキストベースで、含まれる情報をユーザー自身が確認できます。

シナリオ	取得方法	注記
WebGUI が利用可能	WebGUI の Tools → Diagnostics を使用して、診断 zip ファイルを生成してダウンロードします。	診断は、機密データを保護するために既定で匿名化されます。
WebGUI が利用できない	SSH、telnet、または直接コンソールからアクセスして diagnostics コマンドを実行します。zip ファイルは /boot/logs に保存されます。	再起動する前に必ず診断を取得し、ログをそのまま保持してください。
Array が通常モードで起動済み	これが診断を取得する推奨方法です。特にドライブの状態について、最も完全な情報を得られます。	これが不可能な場合は、代替の取得方法として 永続ログのセクション を参照してください。

important

フォーラムに投稿する際は、展開したファイルを個別にアップロードせず、診断 zip ファイル 1 つを添付してください。

診断データの匿名化

既定では、診断情報は自動的に匿名化されます。Settings → Scheduler → Mover Settings で Mover logging を有効にすると、syslog には Mover が処理するファイルの詳細が含まれます。ファイルパスや名前が明らかになる可能性があるため、Mover ログは特定の Mover 関連問題のトラブルシューティング時にのみ有効にするのが最適です。

システムが正常にシャットダウンすると、セッションログは起動デバイスに自動的に保存されます。再起動後は、Tools → Syslog → syslog-previous に移動してアクセスできます。このログは次回の起動時の診断情報にも含まれます。ただし、システムがクラッシュした場合は、システムログは失われます。こうした場合は、ログをトラブルシューティング用に保持するため、起動デバイスへの syslog ミラーリングを有効にするか、リモートの syslog server を使用することをお勧めします。

---

ドライブ読み取り性能のテスト

組み込みの Linux ツールを使用して、ハードドライブの読み取り性能を評価できます。これは、array または cache 内の parity 同期が遅い、ディスク応答が鈍い、あるいはドライブ間の速度差がある場合の診断に役立ちます。

ドライブ速度をテストするタイミングと理由

次のような場合は、ディスク読み取りベンチマークの実行を検討してください:

• parity の構築や parity check が非常に遅い場合
• 特定のディスクからのファイル転送が不自然に遅い
• ディスクの追加や交換後のドライブ不一致、特に SSD と HDD を混在させる場合
• 再割り当てされたセクターまたは UDMA CRC errors。ドライブの故障を示している可能性があります

これらのテストで実際のファイル転送速度を正確に再現できるわけではありませんが、性能の低いディスクやコントローラーのボトルネックを特定する手がかりになります。

クイックテスト (hdparm)

hdparm ツールは、ディスクのキャッシュ読み取り速度とバッファ付き読み取り速度の両方を測定します。

テストを実行するには、X をディスクデバイス名（sdb や sdg など）に置き換え、次のコマンドを入力します:

hdparm -tT /dev/sdX

• -T の結果はキャッシュ読み取り速度を示します。
• -t の結果は、バッファ付き（連続）ディスク読み取り性能を示します。

ヒント

より信頼性の高いベンチマークを得るには、このテストを複数回実行してください。たとえば、次のワンライナーを使ってテストを 12 回実行できます:

for ((i=0;i<12;i++)); do hdparm -tT /dev/sdX; done

注記

必ず /dev/sdX を有効な物理デバイスに置き換えてください。/dev/md1 のような論理 Unraid デバイスは避けてください。これらには parity 処理が含まれ、生の性能測定値が歪む可能性があります。

総合テスト (diskspeed.sh)

parity ドライブとデータドライブを含む、接続されているすべてのドライブをより詳細に評価するには、コミュニティスクリプト diskspeed.sh の使用を検討してください。

このスクリプトは次のことを行います:

• ディスク表面全体で複数の線形オフセットにおける読み取り速度をテストします
• CSV データと性能ヒートマップ（画像）を生成します
• 性能の低い領域を特定できます。これは、ハードウェアの故障や問題のある SMR ドライブの兆候である可能性があります

diskspeed.sh を始めるには:

1. スクリプトを Unraid フォーラム からダウンロードします。
2. /boot/scripts/ のような永続パスに配置します。
3. 実行可能にします:

chmod +x /boot/scripts/diskspeed.sh

4. スクリプトを実行します:

bash /boot/scripts/diskspeed.sh

注記

このスクリプトは読み取り専用の操作のみを行い、ドライブ上のデータを変更しません。ただし、ディスク I/O に影響し、array の性能に干渉する可能性があるため、テストはアイドル時間帯に実行するのが最善です。

---

永続ログ (syslog サーバー)

永続ログは、再起動間のシステムイベントを記録するために不可欠です。システムの再起動時にリセットされる標準ログとは異なり、永続ログは Unraid の組み込み syslog server を使用して、時間の経過とともに発生するクラッシュや断続的な問題を診断できるようにします。

適切なログ方法の選択

永続ログを設定するには、Settings → Syslog Server に移動します。各方法には長所と短所があります:

方法	利点	欠点	最適な用途
シスログを起動ドライブにミラーリングする	起動プロセスのイベントを記録します	起動デバイスがすぐに摩耗する可能性がある	短期的な診断（数日）
リモート syslog	ログは別のデバイスに保存されます	常時稼働の別サーバーが必要です	長期的な監視（数週間から数か月）
ローカル syslog	ログを array または cache に保存し、起動デバイスの摩耗を抑える	システムがクラッシュするとアクセスしにくくなります	外部デバイスなしで継続的にログを記録します

ヒント

詳細な設定方法については、WebGUI ツールバーの ヘルプ アイコンを確認してください。

syslog サーバーの有効化

シスログを起動ドライブにミラーリングする

1. Mirror syslog to boot drive の下で Yes を選択します。
2. Apply をクリックします。ログは起動デバイス上の /boot/logs/syslog に保存されます

次回の再起動時に、このファイルは /boot/logs/syslog-previous に名前が変更されます。このファイルは Tools → Syslog → syslog-previous から表示でき、診断情報にも（匿名化されて）含まれます。

仕組み

• 既定では、Unraid は正常なシャットダウンのたびに syslog を起動デバイスにコピーします。これは、既定で有効になっている "Copy syslog to boot drive on shutdown" 設定によって管理されます。
• クラッシュのトラブルシューティングを行う場合は、"Mirror syslog to boot drive" を有効にできます。これにより、syslog は /var/log/syslog と /boot/logs/syslog の両方にリアルタイムで書き込まれます。クラッシュが発生した場合、クラッシュ前に起動デバイスへ記録された syslog のエントリは保持されます。

どちらの方法でも、次回の起動後に /boot/logs/syslog-previous ファイルが作成されます。このファイルは syslog ビューアーからアクセスでき、診断情報にも含まれます。

注意

Copy syslog to boot drive on shutdown 設定は、起動デバイスに対して安全です。ただし、Mirror syslog to boot drive を有効にしたまま長時間使用すると、過剰な書き込みが発生する可能性があります。長期的なログ記録が必要な場合は、ローカルまたはリモートの syslog server の使用を検討してください。

リモートsyslogサーバー

1. ローカル syslog サーバーを有効に設定します。
2. リモート syslog サーバーに syslog サーバーの IP アドレスを入力してください。
3. Apply をクリックします。
   • ログは指定したデバイスにストリームされます。

注記

フォーラムにリモート syslog server からファイルをアップロードすると、それらは匿名化されません。

ローカル syslog サーバー

サーバー上にUnraid syslogの永続的で信頼性の高いコピーを作成するには:

1. ローカル syslog サーバーを有効に設定します。
2. 次のオプションを設定します:
   • ローカル syslog フォルダー: キャッシュのみ、または優先共有を使用します（SSDに最適）。
   • ローテーション設定: ファイルサイズと数の上限を調整します。
3. 最良の結果を得て、起動イベントを含むすべての syslog データが確実に取得されるようにするには、リモート syslog server フィールドにサーバー自身のIPアドレス（「ループバック方式」）を設定してください。そうしないと、syslog は設定した共有に保存されません。
   • これにより、syslog イベントはローカルに保存され、再起動後も保持されます。しかも、ブートデバイスに書き込むことはありません。
4. Apply をクリックします。
   • ログは指定した共有に保存されます。

注記

• ローカル syslog server からフォーラムにファイルをアップロードした場合、それらは匿名化されません。
• この方法で保存されたログは標準の診断情報には含まれません。サポートが必要な場合は、別途添付してください。

---

Docker コンテナログへのアクセス

標準診断では Docker と VM に関するデータは限定的ですが、より詳細にトラブルシューティングするためにコンテナのログへ直接アクセスできます。

Docker ログを取得するには:

WebGUI 経由

• Docker > コンテナ に移動します
• 対象のコンテナの ログ アイコンをクリックします

コマンドライン経由

コマンドを使用してください:

docker logs [container_name] > /path/to/save/log.txt

永続ロギング

コンテナのログをホストのパスにマッピングするには、コンテナテンプレートを次のように設定します:

/path/in/container:/logs

仮想マシンのログ

VM のログは、それぞれのハイパーバイザーを通じてアクセスできます（たとえば、QEMU のログは /var/log/libvirt/ にあります）。詳細については、使用している VM プラットフォームのドキュメントを確認してください。

important

アプリケーション固有の問題でサポートを求める際は、関連するコンテナまたは VM のログを別途添付することを忘れないでください。