Celery: [K8S] ليفينجسبار والجاهزية مسبار لخفق الكرفس والعمال

يحتوي الكرفس على واجهة برمجة تطبيقات مراقبة يمكنك استخدامها.
يجب اعتبار الكبسولة حية إذا أرسل عامل الكرفس نبضات قلب .
يجب اعتبار الكبسولة جاهزة إذا أرسل العامل الحدث

إذا كانت لديك مشكلات محددة أو طلبات ميزات ، فيرجى فتح مشكلة منفصلة.

هل هذا العمل؟

readinessProbe:
          exec:
            command:
            - "/bin/sh"
            - "-c"
            - "celery -A path.to.app status | grep -o ': OK'"
          initialDelaySeconds: 30
          periodSeconds: 10

@ 7wonders ستحتاج إلى استخراج اسم عقدة الكرفس أولاً. سيفشل هذا الاختبار في حالة فشل أي مثيل من الكرفس وهو ما لا تريده.

thedrow Hmm ، أعتقد أنها ستنجح في الواقع حتى لو فشلت العقدة الفعلية لكن عقدة أخرى على ما يرام وهي أيضًا ليست نتيجة رائعة.

يشبه

/bin/sh -c 'exec celery -A path.to.app inspect ping -d celery@$HOSTNAME' جيد بما يكفي لفحص الجاهزية ويتحقق من عقدة واحدة فقط.

احذر من أنه في بعض التطبيقات ، قد يستغرق تشغيل هذا الأمر بضع ثوانٍ باستخدام الإعدادات الافتراضية لوحدة المعالجة المركزية و kubernetes لتشغيله كل 10 ثوانٍ.

وبالتالي ، من الأكثر أمانًا أن يكون لديك فترة زمنية عاليةالثواني (تم تعييننا على 300)

redbaron هل عمل هذا الأمر من أجلك؟ إذا نجح ، فما هي إعدادات احتمال الحيوية والاستعداد؟

لسبب ما ، فإن تحقيق الاستعداد هذا ليس مرضيًا بالنسبة لنا. المفتش يستجيب بشكل غير حتمي مع عدم وجود حمل على مجموعتنا. نقوم بتشغيل التنسيق مثل هذا:

فحص الكرفس ping -b " redis: // archii-redis-master : 6379" -d celery @ archii-Task-crawl-Integration-7d96d86b9d-jwtq7

ومع أوقات اختبار الاتصال العادية (10 ثوانٍ) ، يتم قتل المجموعة بالكامل بواسطة الكرفس الذي يتطلبه وحدة المعالجة المركزية.

~ أستخدم هذا للحيوية مع فاصل 30 ثانية: sh -c celery -A path.to.app status | grep "${HOSTNAME}:.*OK" ~
أستخدم هذا للحيوية مع فاصل 30 ثانية: sh -c celery -A path.to.app inspect ping --destination celery@${HOSTNAME}
لا يبدو أنه يسبب أي حمولة إضافية ، فأنا أدير أسطولًا يضم أكثر من 100 عامل.

مجسات الجاهزية ليست ضرورية ، لا يتم استخدام الكرفس أبدًا في الخدمة. لقد قمت للتو بتعيين minReadySeconds: 10 وهو أمر جيد بما يكفي لتأخير بدء تشغيل العامل في عمليات النشر المتداول ، ولكن من الواضح أن ذلك يعتمد على وقت بدء تشغيل Celery لمشروعك ، لذا قم بفحص السجلات وتعيينها وفقًا لذلك.

لا تزال تحقيقات الجاهزية مفيدة حتى لو لم يتم استخدامها في الخدمة. على وجه التحديد ، عندما تقوم بنشر العمال وتريد التأكد من نجاح عملية النشر ، فإنك تستخدم عادةً kubectl rollout status deployment . بدون مجسات الجاهزية ، نشرنا كودًا سيئًا لم يبدأ الكرفس ولم نعرفه.

كان الحل:

readinessProbe:
  exec:
    command:
      [
        "/usr/local/bin/python",
        "-c",
        "\"import os;from celery.task.control import inspect;from <APP> import celery_app;exit(0 if os.environ['HOSTNAME'] in ','.join(inspect(app=celery_app).stats().keys()) else 1)\""
      ]

يبدو أن الآخرين لا يعملون 🤷‍♂️

yardensachs شكرا!
اقضِ وقتًا طويلاً في تصحيح الأخطاء في الحلول الأخرى ، ولكن بلا طريقة
يبدو أن الأمر celery inspect ping لا يُرجع المخرج (0) أو شيء بهذه الطريقة

celery inspect ping يعمل ، لكنك تحتاج bash لاستبدال متغير البيئة مثل هذا:

        livenessProbe:
          exec:
            # bash is needed to replace the environment variable
            command: [
              "bash",
              "-c",
              "celery inspect ping -A apps -d celery@$HOSTNAME"
            ]
          initialDelaySeconds: 30  # startup takes some time
          periodSeconds: 60  # default is quite often and celery uses a lot cpu/ram then.
          timeoutSeconds: 10  # default is too low

جيد ان تعلم

انتهى بنا المطاف بتمزيق فحص الكرفس من مجسات الحياة لدينا لأننا وجدنا أنه في ظل الحمل الثقيل ، سيتعطل الأمر لدقائق فقط في كل مرة على الرغم من أن المهام كانت تتم بشكل جيد ولم يكن هناك تراكم. لدي شعور بأن له علاقة باستخدام Eventlet ، لكننا مستمرون في النظر فيه.

WillPlatnick لن يحدث ذلك مع

أواجه مشكلة مع inspect ping التفريخ البائدة / الزومبي:

root      2296  0.0  0.0      0     0 ?        Z    16:04   0:00 [python] <defunct>
root      2323  0.0  0.0      0     0 ?        Z    16:05   0:00 [python] <defunct>
...

أي شخص آخر يواجه هذا؟ لا توجد وسيطة --pool لفرض تنفيذ عملية واحدة.

هل يمكنني أن أسأل ما الذي تستخدمه بدلاً من celery inspect ping WillPlatnick؟ لقد واجهنا مشكلة مماثلة مع المسبار الذي فشل تحت الحمل الثقيل.

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

نواجه نفس مشكلة وحدة المعالجة المركزية مع وسيط Redis

هل وجد أحد الحل؟
كنا أيضًا نجرب جدولة "debug_task" في قائمة الانتظار أي اسم اعتمدناه على اسم الحاوية. المشكلة هي أن لدينا الكثير من قوائم الانتظار القديمة في RabbitMQ الآن

يرجى العلم أن استخدام

sh -c celery -A path.to.app status | grep "${HOSTNAME}:.*OK"

كما هو مقترح في https://github.com/celery/celery/issues/4079#issuecomment -437415370 سيؤدي إلى تقارير أخطاء ضخمة على rabbitmq ، راجع https://github.com/celery/celery/issues/4355#issuecomment - 578786369

أعتقد أنني وجدت طريقة لتقليل استخدام وحدة المعالجة المركزية لفحص ping.

celery -b amqp: // المستخدم: pass @ rabbitmq : 5672 / vhost افحص ping

عدم تحميل تكوينات الكرفس باستخدام -A path.to.celery ساعد بالتأكيد في استخدام وحدة المعالجة المركزية ،
يمكن لشخص ما التحقق.

أعتقد أنني وجدت طريقة لتقليل استخدام وحدة المعالجة المركزية لفحص ping.

celery -b amqp: // المستخدم: pass @ rabbitmq : 5672 / vhost افحص ping

عدم تحميل تكوينات الكرفس باستخدام -A path.to.celery ساعد بالتأكيد في استخدام وحدة المعالجة المركزية ،
يمكن لشخص ما التحقق.

لطيف! إنه أفضل بكثير من تحميل التطبيق.
لكننا ما زلنا نحصل على النفقات العامة الضخمة لعملية الثعبان التي تبدأ + استيراد الكرفس. ما زلت أوصي بفترة عالية.

أهلا،
فحص الكرفس ping -A app.tasks -d celery @ $ HOSTNAME يعطيني "خطأ: البث غير مدعوم بواسطة النقل 'sqs'".
أنا أستخدم SQS كوسيط ، لذلك هذا يعني أن أمر "فحص" / "الحالة" لن يعمل مع SQS؟

لقد وجدنا أنه على نطاق واسع ، تتسبب جميع ميزات التحكم عن بعد في زيادة مثيل Redis في وحدة المعالجة المركزية بسبب تعيين الأوامر على مفتاح kombu.pidbox ، لذلك لا يمكننا استخدام ping أو الحالة أو فحصها كما هي كل ذلك باستخدام جهاز التحكم عن بعد ومحاولة تعطيل جهاز التحكم عن بعد لحالة استخدام الإنتاج.

يبدو لي أن وجود قائمة انتظار مخصصة للفحص الصحي هو الطريقة الصحيحة ولكني لست متأكدًا على الإطلاق

أي شخص لديه أي اتجاه آخر لا يتضمن جهاز التحكم عن بعد لاختبار الفحوصات الصحية؟

نحن نستخدم قوائم انتظار مخصصة للفحوصات الصحية مع سياسات إخلاء RabbitMQ (يتم حذف قوائم الانتظار تلقائيًا) بنجاح لبعض الوقت الآن ، ونحن سعداء بالحل. في الغالب لأن هذا الفحص يتحقق بالفعل من أن العامل يعالج المهمة وينتهي. منذ أن قدمناه ، لم نواجه المزيد من المشاكل مع العمال العالقين.

bartoszhernas هل تمانع في مشاركة بعض التعليمات البرمجية لذلك؟ هل تصطف هذه عبر الإيقاع ثم يلتقطها العمال؟

أود أن أرى الكود + قسم التحقيق في الحياة

مرحبًا ، الكود سهل حقًا:

في Kubernetes ، أحدد اسم قائمة الانتظار بناءً على POD_NAME ، وقم بتمريره إلى البرنامج النصي للتحقق المباشر:

        livenessProbe:
          initialDelaySeconds: 120
          periodSeconds: 70
          failureThreshold: 1
          exec:
            command:
            - bash 
            - "-c" 
            - |
              python celery_liveness_probe.py $LIVENESS_QUEUE_NAME
        env:
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name

        - name: LIVENESS_QUEUE_NAME
          value: queue-$(MY_POD_NAME)

(تحتاج إلى استخدام bash -c ، لأن Kubernetes لا توسع ENVs عند محاولة تمريرها كأمر مباشرة)

ثم يقوم celery_liveness_probe.py بإعداد Django ليتمكن من استخدام الكرفس وجدولة المهمة في قائمة انتظار POD

# encoding: utf-8
from __future__ import absolute_import, unicode_literals

import os
import sys

if __name__ == "__main__":
    import django

    sys.path.append(os.path.join(os.path.dirname(__file__), '..', '..'))
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "ahoy.archive.settings")
    django.setup()
    from ahoy.archive.apps.eventbus.service import eventbus_service

    exit(0 if eventbus_service.health_check(sys.argv[1] if sys.argv and len(sys.argv) > 1 else None) else 1)

ترسل وظيفة فحص الصحة المهمة وتنتظر النتائج

    def health_check(self, queue_name: Optional[str] = None) -> bool:
        event = self.celery.send_task(
            AhoyEventBusTaskName.LIVENESS_PROBE,
            None,
            queue=queue_name or self.origin_queue,
            ignore_result=False,
            acks_late=True,
            retry=False,
            priority=255
        )

        try:
            is_success = event.get(timeout=10)
        except (celery.exceptions.TimeoutError, AttributeError):
            is_success = False

        return is_success

لذلك بشكل أساسي: أرسل مهمة ، وإذا كانت تؤدي إلى نتائج ، فإن العامل يتمتع بصحة جيدة. إذا توقف العامل (حدث كثيرًا) ، فلن تنتهي المهام أبدًا ، تتم إعادة تشغيل Pod ويعود كل شيء إلى طبيعته.

التحذير الوحيد هو أنك تحتاج إلى التعامل مع قوائم الانتظار القديمة ، مع RabbitMQ ، الأمر سهل ، لقد قمنا فقط بإعداد سياسة انتهاء الصلاحية في قائمة الانتظار
https://www.rabbitmq.com/ttl.html#queue -ttl

bartoszhernas أشكركم على مشاركة الكود!

كما قلت إن قوائم الانتظار الخاصة بي ديناميكية ونستخدم Redis - لذلك نحتاج حقًا إلى إيجاد طريقة للتعامل مع انتهاء صلاحية أسماء قائمة الانتظار على Redis

نعم ، لدينا مشكلة مماثلة مع BullMQ مع Redis. فكرتي هي كتابة CronJob لـ Kubernetes والتي من شأنها مسح قوائم الانتظار في كل مرة.