モニタリング

Rediaccは、マシンの健全性、実行中のコンテナ、サービス、リポジトリの状態、システム診断を検査するための組み込みの監視コマンドを提供します。

マシンの健全性

マシンのフルヘルスレポートを取得します：

rdc machine health --name server-1

CLIリファレンス： rdc machine health

レポート内容：

System: アップタイム、ディスク使用量、データストア使用量
コンテナ: 実行中、正常、異常のコンテナ数
ストレージ: SMARTヘルスステータス
問題点: 検出された問題

マシン可読な出力には --output json を使用してください。

コンテナの一覧表示

マシン上のすべてのリポジトリにわたる実行中のコンテナをすべて表示します：

rdc machine containers --name server-1

CLIリファレンス： rdc machine containers

カラム	説明
Name	コンテナ名
Status	アップタイムまたは終了理由
State	実行中、終了済みなど
Health	正常、異常、なし
CPU	CPU使用率
Memory	メモリ使用量 / 上限
Repository	コンテナが属するリポジトリ

オプション：

--health-check, コンテナに対してアクティブなヘルスチェックを実行
--output json, マシン可読なJSON出力

JSON 出力には完全なコンテナ詳細（labels、port_mappings、image、id）に加え、repository（解決後の名前）、repository_guid（元の GUID）、domain、autoRoute が含まれます。

サービスの一覧表示

マシン上のRediaccに関連するsystemdサービスを表示します：

rdc machine services --name server-1

CLIリファレンス： rdc machine services

カラム	説明
Name	サービス名
State	アクティブ、非アクティブ、失敗
Sub-state	実行中、停止など
Restarts	再起動回数
Memory	サービスのメモリ使用量
Repository	関連するリポジトリ

オプション：

--stability-check, 不安定なサービスをフラグ付け（失敗、3回以上の再起動、自動再起動）
--output json, マシン可読なJSON出力

JSON 出力には、repository（解決後の名前）と repository_guid（元の GUID）を含む完全なサービス詳細が含まれます。

リポジトリの一覧表示

マシン上のリポジトリを詳細な統計情報とともに表示します：

rdc machine repos --name server-1

CLIリファレンス： rdc machine repos

カラム	説明
Name	リポジトリ名
Size	ディスクイメージのサイズ
Mount	マウント済みまたは未マウント
Docker	Docker daemonが実行中または停止
Containers	コンテナ数
Disk Usage	リポジトリ内の実際のディスク使用量
Modified	最終更新日時

オプション：

--search <text>, 名前またはマウントパスでフィルタリング
--output json, マシン可読なJSON出力

JSON 出力には name（解決済み）と guid（元の GUID）が含まれ、各リポジトリの containers（domain、autoRoute、repository/repository_guid を含む）配列と services 配列がネストされます。

ストレージの健全性

マシン上のすべてのリポジトリにわたる BTRFS の断片化と reflink 共有を検査します：

rdc machine query --name server-1 --storage-health

CLIリファレンス： rdc machine query

カラム	説明
Quota	リポジトリの最大サイズ（拡張の上限。作成時またはリサイズ/自動拡張によって設定）
Allocated	スパースイメージが現時点でプール内に実際に占有している容量
Unique	このリポジトリのみが所有する実際の一意データ
Shared	BTRFS reflink を通じてリポジトリ間で再利用されるデータブロック（無償コピー）
Reclaimable	`repo trim` でプールに返却できる、割り当て済みと使用済みの差分。未マウントのリポジトリには `-` が表示されます
Discards	暗号化ボリュームがディスカードを透過的に通過させるか（現行バージョンでマウントされたリポジトリはすべて `on`）
Divergence	このリポジトリに固有のイメージの割合（共有されていない部分）（高いほど削除時に回収可能なデータが多い）
Frag	コピーオンライトイメージの GB あたりエクステント数（参考情報のみ）

クォータと割り当て容量は意図的に異なる数値です。20 GB クォータのリポジトリが 6 GB のデータしか保存していない場合、プールには割り当て済みの容量のみコストがかかります。プールは物理容量より多くのトータルクォータを約束でき、Reclaimable カラムは各リポジトリの割り当て済み容量のうちもはや使用されておらずトリムで返却できる容量を示します。

テーブルの下に、データストアの充填率とバックアップスナップショットが確保している容量を報告するプールサマリーが表示されます。

Pool: 265.4 GB used, 95.2 GB free (73.6% full)
Backup snapshots pin 2.1 GB (1 active, 0 stale; stale ones are removed by 'rdc machine prune')

バックアップの実行中は、そのスナップショットがライブリポジトリと共有するすべてのブロックを参照し続けるため、そのバックアップサイクルが完了してスナップショットが削除されるまで、削除やトリムによる空き容量の解放量が減ります。中断されたバックアップの古いスナップショットは、ストレージメンテナーによって数分以内に自動的に削除されます。

サマリーには BTRFS reflink による節約の合計が表示されます：

14 repos, 224.3 GB virtual size
Unique data: 323.7 MB | Shared: 224.0 GB | Efficiency: 99.9%

仮想サイズはすべてのリポジトリイメージサイズの合計です。これはリポジトリの見かけ上のサイズですが、reflink で共有されているブロックを二重にカウントします。
一意データは1つのリポジトリにのみ存在するリポジトリデータによって実際に消費されているストレージです。リポジトリを削除したときに解放される容量です。
共有は BTRFS reflink を通じてリポジトリ間で再利用されるデータです。リポジトリをフォークすると、どちらかの側が新しいデータを書き込むまでブロックを共有する reflink コピーが作成され、その時点でブロックが分岐します。
効率は reflink で再利用されるデータの割合です。高いほど良いです。同じ親から多くのフォークを持つマシンは 100% に近い効率を示します。

Frag カラムは参考情報です。アプリケーションが内部で読むファイルではなく、コピーオンライトイメージファイルのエクステントを数えるため、通常のランダム書き込みワークロード（データベース、コンテナレイヤー）では高い値を示しますが、SSD バックストレージにおける読み取りパフォーマンスを予測しません。Rediacc は意図的にデフラグコマンドを提供していません。btrfs filesystem defragment はreflinkされたフォークやスナップショットを非共有化し、ほぼ満杯のプールでは使用量が劇的に膨れ上がる一方、ベンチマークでは計測可能な読み取り改善は見られません。計測データと詳細については断片化の数値が怖く見える。実際のコストを計測してみた。をご覧ください。

スキャンは並列実行され、リポジトリの数とサイズによって 5〜15 秒かかります。--storage-health を指定しない場合、クエリ出力の後にリマインダーとして1行のヒントが表示されます。

BTRFS スクラブ

Rediaccはすべてのマシンで毎週 BTRFS スクラブを自動的にスケジュールします。スクラブはデータストアのすべてのデータブロックを読み取り、チェックサムを検証し、破損を報告します。これにより、バックアップやフォークに伝播する前にサイレントなデータ破損（ビットロット）を検出します。

スクラブは毎週日曜日の 02:00 ローカルタイム（マシンのタイムゾーン）に最大1時間のランダムな遅延を加えて実行されます。最低の I/O 優先度（ionice idle、nice 19）で実行されるため、実行中のサービスに干渉しません。SSD ベースのマシンでは、データストア 100 GB あたり約 8 分を見込んでください。

スクラブタイマーは、renet のアップグレード後の最初のデーモン起動時に自動的にインストールされます。将来の renet バージョンでスクラブポリシーが変更された場合、次のデーモン起動時にユーザーのアクションなしで自動的に更新されます。

スクラブのステータス

最後のスクラブの結果は BTRFS ボリュームの外部（/var/lib/rediacc/scrub-last-result.json）に保存されるため、ボリュームに問題があっても読み取り可能なままです。rdc machine query --system の出力には scrub_status フィールドが含まれます：

"scrub_status": {
  "last_run_human": "3 days ago",
  "status": "ok",
  "total_errors": 0,
  "uncorrectable": 0,
  "duration_seconds": 312
}

ステータス	意味
`ok`	最後のスクラブがエラーなしで完了した
`never_run`	スクラブがまだ実行されていない（タイマーがインストールされたばかり）
`overdue`	最後のスクラブが 14 日以上前だった
`errors_found`	スクラブがチェックサムの不一致を発見した（`total_errors` と `uncorrectable` のカウントを確認してください）
`failed`	スクラブプロセスが非ゼロのコードで終了した

uncorrectable がゼロより大きい場合、影響を受けたブロックは自動的に修復できません（単一ディスクの BTRFS には冗長コピーがありません）。影響を受けたリポジトリを最新のバックアップから復元してください。

手動スクラブ

スクラブを即座に実行するには（例：電源障害またはディスク移行後）：

rdc term connect -m server-1 -c "sudo renet maintenance scrub --datastore /mnt/rediacc"

CLIリファレンス： rdc term connect

結果は同じ JSON ファイルに保存され、次の rdc machine query --system で即座に確認できます。

Vaultステータス

デプロイ情報を含むマシンの完全な概要を取得します：

rdc machine vault-status --name server-1

CLIリファレンス： rdc machine vault-status

提供される情報：

ホスト名とアップタイム
メモリ、ディスク、データストアの使用量
リポジトリの総数、マウント数、Docker実行数
リポジトリごとの詳細情報

マシン可読な出力には --output json を使用してください。

接続テスト

クラウドアダプターのみ。 ローカルアダプターでは、rdc term connect -m server-1 -c "hostname" を使用して接続を確認してください。

マシンへのSSH接続を確認します：

rdc machine test-connection --ip 203.0.113.50 --user deploy

CLIリファレンス： rdc machine test-connection

レポート内容：

接続状態（成功/失敗）
使用された認証方法
SSH鍵の設定
公開鍵のデプロイ状態
Known hostsエントリ

オプション：

--port <number>, SSHポート（デフォルト: 22）
--save -m server-1, 検証済みホスト鍵をマシン設定に保存

診断 (doctor)

Rediacc環境のフル診断チェックを実行します：

rdc doctor

CLIリファレンス： rdc doctor

カテゴリ	チェック内容
環境	Node.jsバージョン、CLIバージョン、SEAモード、Goインストール、Dockerの利用可否
Renet	バイナリの場所、バージョン、CRIU、rsync、SEA埋め込みアセット
設定	アクティブな設定、アダプター、マシン、SSH鍵
仮想化	ローカル仮想マシンを実行できるか確認（`rdc ops`）

各チェックは OK、警告、または エラー を報告します。問題のトラブルシューティングの最初のステップとしてこれを使用してください。

終了コード: 0 = すべて合格、1 = 警告あり、2 = エラーあり。

サービス準備完了チェック

repo up 実行中、renet は HTTP サービスが接続を受け入れるまで待機してから準備完了とみなします。この待機処理はヘルスチェックの状態を考慮します。

Docker が healthy と報告するコンテナはそのまま信頼されます。TCP プローブは行いません。
ヘルスチェックの start_period 内にあるコンテナは、警告ではなく情報ログを出力します。プロキシはバインドするまで再試行を続けます。
実行中のコンテナが存在しない Compose サービス（たとえば非アクティブなプロファイルの背後にあるもの）はスキップされます。
それ以外はすべて TCP で最大 15 秒プローブします（REDIACC_READINESS_TIMEOUT 環境変数に秒数を設定することで変更できます）。

起動に時間のかかるサービスに Docker ヘルスチェックを定義すると、renet に信頼できる準備完了シグナルが伝わり、デプロイ出力のプローブノイズが減ります。