Immichの警告はいつ監視を続けても安全で、いつ停止すべきか？
Immichの警告が範囲内に収まり、影響を受けた処理が完了し、有用な処理が継続しており、データベース、ファイルシステム、マウント、メモリの障害を示す証拠がない場合は、安全に監視できます。同じ警告が、処理の失敗、ストレージの消失、OOMキル、データベースのリカバリエラー、またはリソース圧迫の急速な悪化を伴って繰り返される場合は、新しい書き込みを停止してください。
判断材料は「warning」という単語ではありません。負荷の高いインポート中には、無害な再試行メッセージと「デバイスに空き容量がありません」というメッセージの両方が表示されることがありますが、示すリスクは大きく異なります。何かを再起動する前に、最初に発生した時刻、正確な処理、影響を受けたアセットまたはジョブ、ストレージとコンテナの状態を記録してください。
警告を、失敗する可能性のある処理で分類する
まず、テスト用の写真をアップロードする、古いアセットを開く、検索を1回実行する、またはメッセージを発生させたバックグラウンドジョブを観察するなど、具体的なユーザー操作を1つ選びます。警告の時刻を、Immichサーバー、機械学習サービス、PostgreSQL、リバースプロキシ、ストレージのログと照合します。重要なのは、その警告が成功したリクエスト、再試行されたリクエスト、失敗した書き込みのいずれに属するかです。
ログレベルの重大度ガイドは有用な出発点です。一般にWARNは、アプリケーションが処理を継続できる可能性のある予期しない状態を示し、ERRORは処理の失敗を示します。ただし、Immichのトラブルシューティングでは、継続使用が安全かどうかを判断する前に、そのラベルを影響を受けたリクエスト、書き込み経路、依存サービスに対応付ける必要があります。
同じ操作が繰り返し成功し、警告の件数が増えなくなった場合は、証拠が変わるまで監視対象として分類します。通常の発生率と状況を記録しておけば、将来のバージョン、ライブラリの変更、容量不足によってメッセージが頻発するようになったかを判断できます。ユーザーに見える影響のない孤立したメッセージだけで、スタックを再構築する理由にはなりません。
ZimaSpaceのImmichの修復と再構築に関する判断フレームワークも同じ境界を用います。つまり、稼働しているデプロイメントを置き換える前に、状態を保持し、局所的な障害を診断します。警告が1つの処理を超えて広がった場合や、原因を修復した後も再発する場合は、重要度が高まります。
進行状況と状態が健全なら監視を続ける
監視のみでよい警告には、安定した範囲があります。新しい項目の到着が止まった後もキューが減り続け、再試行が最終的に成功し、データベースクエリが正常で、空き容量が運用上の下限を上回り、マウントが存在し続け、コンテナの再起動回数が増えない状態です。ユーザーが目にするワークフローも、通常のレイテンシとエラー範囲内に収まっている必要があります。
思い込みで判断せず、実際にこの境界をテストしてください。同じ操作を5回繰り返し、古いアセットと新しくアップロードしたアセットを1つずつ含め、前後の警告件数を比較します。モデルの読み込み中や一時的な依存サービスの再試行で警告が1回表示され、その後の試行が正常なら、正確なバージョンとともに記録して監視を続けます。意味を理解する前に警告を抑制したりフィルタリングしたりしないでください。ノイズの多いログ行を無音化すると基準値が失われ、無害な再試行から書き込み失敗への移行を見逃す可能性があります。重大度ラベルだけでなく、継続時間、発生率、関連するジョブの失敗、メッセージが示すリソースを監視してください。これらの指標のほうが有用です。
警告がデータ安全性の境界に達したら新しい書き込みを停止する
ファイルシステムが満杯または読み取り専用であること、必要なマウントが見つからないこと、PostgreSQLのリカバリまたは書き込みに関する失敗が繰り返されること、コンテナのOOMキル、またはトランザクションが完了する前にサービスが繰り返し再起動することを警告が示している場合は、アップロードとバックグラウンドジョブを停止してください。空き容量を確保したり所有権を変更したりする前に、ログと現在のデータパスを保存します。
データベース関連の「デバイスに空き容量がありません」というメッセージは、通常のログノイズではありません。Immichの障害に関する議論では、問題のあるデプロイメント中に、タイムラインの破損とPostgreSQLの容量エラーが同時に発生していました。
この事例から、普遍的な根本原因が1つに決まるわけではありません。ただし、ストレージ関連のデータベース警告が出た場合、さらに書き込みを受け付ける前に、影響範囲を直ちに確認すべき理由が示されています。
ホストが制御不能なほどスワップを使い始めた場合、予期しない空のマウントの下にファイルが現れた場合、または意図したストレージがマウントされなかったために新しいアップロードがコンテナの書き込み可能レイヤーに保存されている場合も、同じ停止ルールを適用します。書き込みを続けると、復旧可能な設定問題が、より大きな整合性確認の問題に発展する可能性があります。
可逆的な修正を1つ行い、元の発生条件を再現する
確認できた原因だけを修正します。意図したマウントを復元する、安全に確保できる空き容量を増やす、1つのジョブの同時実行数を減らす、失敗した依存サービスを修正する、権限の境界を直す、といった対応です。すべてのキューを消去したり、データベースファイルを削除したり、不明なDockerボリュームをpruneしたり、同時にバージョンアップしたりしないでください。そうすると、結果を判断するために必要な証拠が失われます。
必要であれば影響を受けたサービスだけを再起動し、その後、警告を発生させた正確な条件を再度実行します。成功とは、ユーザー操作が成功し、警告が停止するか記録済みの無害な発生率に戻り、キューが処理され、ストレージとメモリが健全な状態を維持し、2回目の再起動でも障害が再発しないことです。クリーンな再現後もメッセージが残る場合、データベースの整合性が不確かな場合、必要なファイルが消える場合、または最初の安全な修正で通常の進行が回復しない場合は、実験を続けずエスカレーションしてください。正確なImmichとPostgreSQLのバージョン、時刻付きログ、ファイルシステムの状態、コンテナの再起動およびOOMの状態、最小限の再現手順を提示すれば、次の対応で失敗している層を的確に特定できます。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。
