أتيت إلى هنا على أمل العثور على تشخيص خطوة بخطوة عندما يواجه موقع Discourse حالة 502 Bad Gateway. يبدو أن الخيارات الوحيدة المتاحة هي على هذا النحو:
قد يكون تحديث Discourse قد فشل، استخدم ./launcher rebuild app.
تحديث وإعادة تشغيل الخادم.
هذه هي أنواع الردود التي نحصل عليها من فني دعم من المستوى الأول، أو روبوت بريد إلكتروني.
ماذا يمكننا أن نفعل أيضًا للنظر في السجلات ومعرفة سبب تعطل البيئة بالضبط؟ بهذه المعلومات قد نتعلم كيفية منع المشكلة في المستقبل.
على سبيل المثال، هل سيكون من المناسب كتابة نص برمجي لعملية cron لفحص Discourse بشكل دوري، وإذا كانت الاستجابة هي رمز حالة 502 أو رمز مشابه، فإعادة البناء تلقائيًا؟
يبدو أن إعادة البناء طريقة وحشية لحل مشكلة ما. إنها ليست تشخيصًا.
آمل حقًا أن يشير إلينا شخص ما إلى مستند شائع “لتشخيص مشكلات Discourse” فاته أمثالي.
من خلال قراءة الكثير من المشاركات هنا، عادةً لا يكون مسؤولو المنتدى هم سبب أخطاء 502، بل يكون خطأ في المكون الإضافي أو النواة. لذلك لن يكون هناك الكثير مما يمكنك فعله لتجنب هذه المشكلات.
تساعد سجلات وحدة التحكم دائمًا، حيث يمكنها تحديد المكون الإضافي الإشكالي في كثير من الأحيان.
يمكنني فتح وحدة التحكم على هذا الخادم الافتراضي الخاص (VPS) ولكن نافذة النص محدودة.
هل هناك سجلات محددة يمكن التحقق منها في الحاوية أو في نظام التشغيل؟
هل توجد بالفعل أي عملية ping في نظام التشغيل المضيف أو الحاوية تكتشف متى تتوقف العمليات؟
هل يمكن أن يكون إعادة تشغيل بسيط للخادم داخل الحاوية طريقة جيدة للتعامل مع هذا بدلاً من إعادة بناء كاملة؟
بالمناسبة، أنا أقوم بتشغيل أحدث إصدار تجريبي/تطويري، لذلك من الممكن تمامًا أن يكون تحديث حديث قد أوقف الخادم، كما رأينا في الماضي. لا أتذكر حاليًا ما إذا كانت هناك أي إضافات غير افتراضية مثبتة.
لدي الحرية في المساعدة في تشخيص هذا دون أن ينزعج مجتمعنا، على الرغم من أنه في غضون بضعة أشهر سنحتاج إلى الانتقال إلى إصدارات أكثر استقرارًا فقط لإبقاء مستخدمينا مرتاحين. لذا، إذا كان هذا شيئًا في البناء، فسأكون سعيدًا بالمساعدة في العثور عليه.
القرص مستخدم بنسبة أقل من 50%.
الذاكرة العشوائية (RAM) تميل للبقاء في نطاق 80-90%، والتبديل (Swap) أقل من 40%. أعتقد أن هذه هي المشكلة.
السجلات موجودة في /var/discourse/shared/standalone/log/rails.
يحتوي ملف production.log والملفات المضغوطة ذات الصلة على الكثير من تفاصيل المعاملات. ما الذي يمكنني البحث عنه؟
لا توجد أي إدخالات في ملف production_error.log على الإطلاق.
“بشكل متكرر”؟ لا. ولكن بشكل متكرر بما يكفي ليكون مزعجًا بعض الشيء ويدفع إلى نشر مشاركة هنا.
لقد مررت بملف syslog ولم أر شيئًا - لست متأكدًا مما إذا كان هناك أي شيء هناك إذا كانت المشكلة مقصورة على الحاوية، كما ينبغي أن تكون.
أنا مبتدئ في Docker، لذا أنا آسف لعدم وجود معلومات من الحاوية، ولكن سأكون سعيدًا للمساعدة حسب التوجيهات.
لن يساعد هذا. المشكلة تكمن في الواجهة الخلفية. لا يصل الأمر إلى حد الحصول على استجابة من الخادم (ومن هنا جاءت عبارة “بوابة سيئة”)
إنها سجلات الواجهة الخلفية لـ rails التي تحتاج إلى النظر إليها.
جرب الإجراءات:
/var/discourse/shared/standalone/log/rails# tail -n 200 production.log لمعرفة ما إذا كانت هناك أخطاء واضحة عند بدء التشغيل
في الحاوية (أولاً ./launcher enter app):
curl 0.0.0.0:3000 لمعرفة ما إذا كان خادم rails يستجيب.
بخلاف ذلك، قم بإزالة جميع الإضافات، وأعد البناء، ثم أضفها بشكل متكرر مرة أخرى.
أعتقد أن جميع الخيوط تقريبًا هنا حول أخطاء 502 تحدث عندما تمت ترقية Discourse ولم تعد إلى الحياة. فشلت الترقية، أو لم ينتظر المسؤول وقتًا كافيًا حتى يتم تشغيل الخدمة.
هل تقول إن لديك Discourse يعمل، ولا تتخذ أي إجراء إداري، ولكنه يبدأ في إرجاع 502 تلقائيًا؟
وعندما يحدث ذلك، هل يرجع دائمًا 502 حتى تتم إعادة التشغيل أو أنه يعمل بشكل متقطع مرة أخرى؟
