Immichのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Tell Whether an Immich Error Comes From the Client or Server - Zima Store Online

Immichのエラーがクライアント側かサーバー側かを判断するには、1つの変数だけを変えて同じ操作を再現し、失敗したリクエストを経路に沿って追跡します。

「サーバーエラー」と表示されるモバイルバナーでも、実際の原因はクライアントの状態、TLS、リバースプロキシ、またはサーバーが正しく拒否したリクエストである可能性があります。同様に、ブラウザーだけで発生する失敗だからといって、ブラウザーが壊れているとは限りません。アカウント、アセット、操作を固定し、クライアントと経路を比較してから、ステータスコードと同期したログを使って最初に失敗した層を特定します。

2台目のクライアントで同じ操作を再現する

ログイン、既知のアセットを開く、同じ小さな写真をアップロードする、同じ検索を実行するといった、決定性のある操作を1つ選びます。同じアカウントを使い、ネットワーク経路を変えずにブラウザーとモバイルクライアントで繰り返します。両方の試行について、正確な時刻と結果を記録します。

Androidクライアントで接続に失敗し、他のアクセス経路もテストされた最近のImmich報告は、クライアント間比較の有効性を示しています。あるスレッドでの原因を一般化することはできませんが、クライアント固有の結果によって、次に調べるべき場所を大幅に絞り込めます。

すべてのクライアントで同じ操作が同じ時刻に失敗する場合は、サーバー、データベース、ストレージ、または共有ネットワーク経路の可能性が高まります。同じエンドポイントを通じて一方のクライアントだけが失敗し、もう一方が成功する場合は、クライアントのバージョン、キャッシュされた状態、権限、ローカルの証明書信頼、そして異なる実際のリクエストを確認します。

アカウントやアセットを変えずに経路を変更する

次に、信頼できるローカル経路と、通常のリバースプロキシ、VPN、トンネル、またはリモート経路を比較します。同じアカウントと操作を使用します。ローカルでは成功し、リモートでは失敗する場合、メディアレコード自体よりも、DNS、TLS、プロキシ、ファイアウォール、または上流ルーティングの層に原因がある可能性が高くなります。

ZimaSpaceのローカル経路とリモート経路の診断ガイドでは、LANでの成功とインターネット経由での成功が異なる根拠である理由を説明しています。モバイルアプリを再インストールしたりサーバーを再構築したりする前に、この境界をImmichにも適用してください。

両方の経路で同じように失敗する場合は、プロキシ設定の変更を止め、アプリケーション側のリクエストを調べます。プロキシ経路だけが失敗する場合は、プロキシのステータス、TLSの結果、上流からの応答、タイムアウトを記録します。この1変数比較により、クライアントのメッセージによって調査が誤った層へ進むのを防げます。

ステータスコードは手がかりとして使い、最終判断にはしない

HTTPのステータスクラスは調査箇所の分類に役立ちますが、条件を引き起こしたコンポーネントを自動的に特定するものではありません。4xxは多くの場合、リクエスト、認証、または認可が受け入れられなかったことを示し、5xxはサーバー側のコンポーネントがリクエストを処理できなかったことを示します。ただし、プロキシがImmichにリクエストを渡す前に、どちらのクラスも生成する可能性があります。

アクセスログのフィールドガイドでは、ステータスコード、URLパス、リクエスト時刻、リモートホスト、リクエスト識別子が有用なトラブルシューティング項目として挙げられています。無関係な行を何千行も確認するのではなく、失敗した1つの操作についてこれらの値を記録します。

プロキシに502やタイムアウトが記録され、対応するImmichのリクエストがない場合は、上流経路を追跡します。Immichがリクエストを記録し、決定的な4xxを返している場合は、認証、権限、またはリクエスト内容を調べます。クライアントが失敗を報告しているのに、サーバー側のすべての層が2xxを示している場合は、クライアントの解析処理、ローカルキャッシュ、または後続リクエストを調べます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

1つの時刻でエラー率、レイテンシ、サーバーログを関連付ける

1回の失敗したリクエストは外れ値かもしれません。操作を5〜10回再現し、関連するサーバーログとプロキシログを監視しながら、成功率とレイテンシを記録します。リソースの逼迫やキューの急増時にエラーが増える場合は、2回目の試行が成功しても、サーバーが断続的に利用できなくなっている可能性があります。

Better Stackのエラーとレイテンシをサービスシグナルとして扱う概要では、エラー率、レイテンシ、トラフィックを分けて説明しています。この考え方により、単一の不正なクライアントリクエストと、負荷時にのみ劣化するサーバー経路を区別できます。

複数のクライアントでサーバーログに同じ例外が記録される場合は、反証されるまでサーバー側の問題として扱います。サーバーが失敗したリクエストをまったく認識していない場合は、DNS、TLS、プロキシ、クライアントのネットワークを追跡します。1つのクライアントだけが異なる形式のリクエストを生成している場合は、違いを確認できる十分な証拠を保存してから、そのクライアントを更新またはリセットします。

2×2テストで最終判断を下す

2つのクライアントと2つの経路、つまりブラウザー・ローカル、ブラウザー・リモート、モバイル・ローカル、モバイル・リモートを使用します。同じアカウントとテスト用アセットを固定します。このマトリクスにより、クライアント固有の失敗、経路固有の失敗、すべての組み合わせに影響するサーバー障害を切り分けられます。

一方のクライアントが両方の経路で失敗し、もう一方が成功する場合は、クライアント側の原因が示唆されます。両方のクライアントが一方の経路でのみ失敗する場合は、経路側の原因が示唆されます。4つすべてで同じアプリケーションエラーが再現し、サーバーログにも同じ操作の失敗が記録される場合は、サーバー側の原因が示唆されます。

特定した層を修正したら、4つすべての組み合わせと、影響を受けたコンポーネントの再起動を1回実行します。元々失敗していた組み合わせが、対照となる組み合わせを壊さずに成功した時点で終了します。一般的なスクリーンショットではなく、マトリクス、タイムスタンプ、HTTPステータス、プロキシとサーバーのログ抜粋、クライアントのバージョン、再現可能なリクエスト1件を添えてエスカレーションします。