كيفية معرفة ما إذا كان خطأ Immich صادرًا عن العميل أم الخادم

حدّد ما إذا كان خطأ Immich من جهة العميل أم من جهة الخادم عبر إعادة تنفيذ الإجراء نفسه مع تغيير متغيّر واحد، ثم تتبّع الطلب الفاشل عبر المسار.

قد يكون الشريط الظاهر على الهاتف ويعرض عبارة «خطأ في الخادم» ناتجًا في الواقع عن حالة العميل، أو TLS، أو وكيل عكسي، أو طلب رفضه الخادم بشكل صحيح. وبالمثل، لا يثبت فشل المتصفح فقط أن المتصفح معطّل. ثبّت الحساب والأصل والإجراء؛ وقارن بين العملاء والمسارات؛ ثم استخدم رموز الحالة والسجلات المتزامنة لتحديد أول طبقة حدث فيها الفشل.

أعد تنفيذ الإجراء نفسه على عميل ثانٍ

اختر إجراءً محددًا يمكن تكراره، مثل تسجيل الدخول، أو فتح أصل معروف، أو تحميل الصورة الصغيرة نفسها، أو إجراء البحث نفسه. كرّره بالحساب نفسه على المتصفح وعميل الهاتف، مع إبقاء مسار الشبكة دون تغيير. سجّل الوقت الدقيق والنتيجة لكلتا المحاولتين.

يوضح تقرير حديث عن Immich، حيث فشل عميل أندرويد أثناء اختبار مسارات وصول أخرى، قيمة المقارنة بين العملاء. لا يمكن تعميم السبب في موضوع واحد، لكن النتيجة الخاصة بعميل معيّن تضيق نطاق الفحص التالي بوضوح.

إذا فشل كل عميل في الإجراء نفسه وفي الوقت نفسه، ترتفع أولوية فحص الخادم أو قاعدة البيانات أو التخزين أو مسار الشبكة المشترك. وإذا فشل عميل واحد فقط بينما نجح آخر عبر نقطة النهاية نفسها، فتحقّق من إصدار العميل، والحالة المخزنة مؤقتًا، والأذونات، وثقة الشهادة المحلية، والطلب الدقيق المختلف.

غيّر المسار دون تغيير الحساب أو الأصل

قارن بعد ذلك بين مسار محلي موثوق ومسار وكيل عكسي أو VPN أو نفق أو مسار بعيد. استخدم الحساب والإجراء نفسيهما. يشير النجاح محليًا مع الفشل عن بُعد إلى أن المشكلة ليست في سجل الوسائط نفسه، بل في طبقات DNS أو TLS أو الوكيل أو جدار الحماية أو توجيه المنبع.

يشرح دليل ZimaSpace حول تشخيص المسار المحلي مقابل البعيد سبب اختلاف دليلي نجاح الشبكة المحلية ونجاح الإنترنت. طبّق هذا الحد الفاصل على Immich قبل إعادة تثبيت تطبيق الهاتف أو إعادة بناء الخادم.

إذا فشل المساران بالطريقة نفسها، فتوقّف عن تغيير إعدادات الوكيل وافحص الطلب من جهة التطبيق. وإذا فشل مسار الوكيل فقط، فالتقط حالة الوكيل، ونتيجة TLS، واستجابة المنبع، والمهلة. تمنع هذه المقارنة ذات المتغيّر الواحد رسالةَ العميل من توجيه التحقيق إلى الطبقة الخطأ.

استخدم رموز الحالة كقرائن لا كأحكام نهائية

تساعد فئات حالات HTTP في تحديد موضع البحث، لكنها لا تحدد تلقائيًا المكوّن الذي تسبب في الحالة. غالبًا ما يعني 4xx أن الطلب أو المصادقة أو التفويض غير مقبول؛ بينما يشير 5xx إلى أن مكوّنًا من جهة الخادم لم يتمكن من تنفيذ الطلب. وقد تنشئ الوكلاء أيًا من الفئتين قبل أن يرى Immich الطلب.

يسلط الدليل الميداني لسجلات الوصول الضوء على رمز الحالة، ومسار URL، ووقت الطلب، والمضيف البعيد، ومعرّفات الطلب باعتبارها حقولًا مفيدة لاستكشاف الأخطاء. التقط هذه القيم للإجراء الفاشل الواحد بدلًا من فحص آلاف الأسطر غير المرتبطة.

إذا سجّل الوكيل الحالة 502 أو مهلة دون وجود طلب مطابق في Immich، فتتبّع مسار المنبع. وإذا سجّل Immich الطلب وأعاد 4xx محددًا بصورة متسقة، فافحص المصادقة أو الأذونات أو محتوى الطلب. وإذا أبلغ العميل عن فشل بينما تعرض جميع طبقات الخادم الحالة 2xx، فافحص تحليل العميل أو ذاكرته المحلية المؤقتة أو الطلبات اللاحقة.

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

اربط معدل الأخطاء وزمن الاستجابة بسجلات الخادم عند وقت واحد

قد يكون الطلب الفاشل الواحد حالة شاذة. أعد تنفيذ الإجراء من خمس إلى عشر مرات، وسجّل معدل النجاح وزمن الاستجابة، مع مراقبة سجلات الخادم والوكيل ذات الصلة. إذا ارتفعت الأخطاء أثناء ضغط الموارد أو ارتفاع طوابير الانتظار، فقد يكون الخادم غير متاح على نحو متقطع حتى لو نجحت المحاولة الثانية.

يفصل عرض Better Stack حول الأخطاء وزمن الاستجابة بوصفهما إشارتين للخدمة بين معدل الأخطاء وزمن الاستجابة وحركة المرور. يساعد هذا الإطار في التمييز بين طلب عميل واحد غير صالح ومسار خادم يتدهور فقط تحت الحمل.

إذا احتوت سجلات الخادم على الاستثناء نفسه لعدة عملاء، فاعتبر المشكلة من جهة الخادم حتى يثبت العكس. وإذا لم يرَ الخادم الطلب الفاشل مطلقًا، فتتبّع DNS وTLS والوكيل وشبكة العميل. وإذا أنشأ عميل واحد فقط شكلًا مختلفًا للطلب، فحدّث ذلك العميل أو أعد ضبطه بعد الاحتفاظ بأدلة كافية لتأكيد الفرق.

أصدر الحكم النهائي باختبار اثنين في اثنين

استخدم عميلين ومسارين: المتصفح-محلي، والمتصفح-بعيد، والهاتف-محلي، والهاتف-بعيد. أبقِ الحساب نفسه واختبر الأصل نفسه. تفصل هذه المصفوفة بين حالات الفشل الخاصة بالعميل وحالات الفشل الخاصة بالمسار، وبين حالات فشل الخادم التي تؤثر في كل التركيبات.

يُدعَم كون السبب من جهة العميل عندما يفشل عميل واحد على كلا المسارين بينما ينجح الآخر. ويُدعَم كون السبب من جهة المسار عندما يفشل كلا العميلين عبر مسار واحد فقط. ويُدعَم كون السبب من جهة الخادم عندما تعيد التركيبات الأربع الخطأ نفسه في التطبيق، وتعرض سجلات الخادم العملية الفاشلة نفسها.

بعد إصلاح الطبقة المحددة، أعد اختبار الخلايا الأربع وأجرِ إعادة تشغيل واحدة للمكوّن المتأثر. توقّف عندما تنجح الخلية الفاشلة الأصلية دون تعطيل حالات المقارنة. صعّد المشكلة مع المصفوفة، والطوابع الزمنية، وحالات HTTP، ومقتطفات من سجلات الوكيل والخادم، وإصدارات العملاء، وطلب واحد قابل لإعادة الإنتاج بدلًا من لقطة شاشة عامة.