`/srv/status` يُرجع OK حتى لو كانت قاعدة البيانات معطلة

مطور
1

واجهت مشكلة اليوم أثناء ترقية تثبيت يتكون من حاويتين. أدى تهيئة حاوية جديدة إلى نقل قاعدة البيانات إلى حالة معطلة (ربما لم يكن ذلك ليحدث لو استخدمت SKIP_POST_DEPLOYMENT_MIGRATIONS=1، لكن هذه قضية أخرى)، مما جعل الحاوية النشطة تعرض رسالة “أوه، هذا الموقع معطوب”.

هذا الأمر متوقع، لكن مراقبي يتحقق من /srv/status ويعيد ببساطة حالة OK حتى عندما يكون رايلز معطلاً بشكل كبير.

هل هذا خطأ برمجي؟ أريد حقًا أن تعرف مراقباتي إذا كانت هناك مشكلة، فهل يجب علي بدلاً من ذلك استرجاع شيء آخر مثل /about.json (للمواقع التي لا تتطلب تسجيل الدخول)؟

إعجاب واحد (1)
2

كيف بالضبط كان معطلاً؟ هل يمكنك أن تكون أكثر تحديدًا؟ كيف كان شكل الصفحة الرئيسية؟

3

نعم، تعني كلمة “ok” أن “Unicorn” يعمل. يمكنك إيقاف Postgres و Redis، وستظل تظهر كلمة “ok” إذا كنت أتذكر بشكل صحيح.

3 إعجابات
4

أنا متأكد إلى حد كبير من أن ذلك صحيح. إنه منطقي، إنه ببساطة ليس ما كنت أظنه.

إعجاب واحد (1)
5

لست متأكدًا من حالة هذا الأمر @sam @eviltrout؟ أتذكر بشكل ضبابي نقاشًا حول هذا في الماضي.

إعجاب واحد (1)
6

نعم، لا يتحقق من Redis أو PostgreSQL. أعتقد أننا نستخدم إضافة تقوم بـ User.find(1) و $redis.get بدلاً من ذلك. هذا لا يزال لا يغطي حالة @pfaffman، لكن قد يكون ذلك مبالغًا فيه بعض الشيء، فلا يمكن توقع أن يقوم هذا بفحص كامل لاتساق قاعدة البيانات.
discourse/app/controllers/forums_controller.rb at main · discourse/discourse · GitHub

إعجابَين (2)
7

يُفحص نقطة النهاية /srv/status فقط العملية المحلية، وليس أي اعتمادات. “هل كومة HTTP عالقة؟”، بالإضافة إلى “هل أنا في وضع البطء؟”. في مصطلحات Kubernetes، هذا هو livenessProbe، وليس readinessProbe.

إذا أردنا إدخال readinessProbe، فيجب أن يكون موجودًا في عنوان URL مختلف.

على الأرجح Discourse.system_user.id بدلاً من 1.

5 إعجابات