Python'da arka plan işlerini çalıştırmak için RQ (Redis Queue) son derece basit ve etkili bir araçtır. Ancak bu basitlik, ekiplerin onu yeterince izlememesine neden olabilir. RQ genellikle 'sadece çalışır', ta ki yavaşlayan bir API veya kötü bir dağıtım işlerin sessizce başarısız olmasına yol açana kadar. Bu makalede, müşterileriniz size söylemeden önce hangi metrikleri izlemeniz gerektiğini ve nasıl uyarı alacağınızı ele alacağız.
RQ iş başarısızlıkları kendiliğinden bildirilmez. Bir iş hata verdiğinde, RQ onu FailedJobRegistry'e taşır ve yoluna devam eder. Worker çalışmaya devam eder, hiçbir şey çökmez. Eğer bu kaydı izlemiyorsanız, başarısızlık görünmezdir. BullMQ, Celery ve diğer tüm sağlam kuyruklar aynı tuzağı paylaşır. Bu nedenle yapmanız gereken, kuyruğun durumuna erişmek ve bunu bir sinyale dönüştürmektir.
Önemli dört sinyal vardır: Başarısızlık sayısı/oranı (belirli bir zaman aralığında FailedJobRegistry'e düşen işler), birikmiş iş sayısı (sıraya alınan işlerin çalışan işlere oranı, worker'ın yetişip yetişemediği), gecikme (işlerin ne kadar sürdüğü ve worker tarafından alınmadan önce ne kadar bekledikleri) ve worker canlılığı (worker'larınızın gerçekten çalışıp çalışmadığı). Bu metrikleri okumak için RQ'nun kuyruk ve kayıt durumlarına doğrudan erişebilirsiniz: `from redis import Redis; from rq import Queue; from rq.registry import FailedJobRegistry, StartedJobRegistry; redis = Redis(); q = Queue('default', connection=redis); queued = len(q); failed = FailedJobRegistry(queue=q); started = StartedJobRegistry(queue=q)`.
Bu metrikleri belirli aralıklarla sorgulayıp seri halinde depolamalısınız; tek bir anlık görüntü eğilimi gizler. Başarısızlıklar için, kayıt defterini dolaşarak gerçek istisnaları alabilirsiniz: `for job_id in failed.get_job_ids(): job = q.fetch_job(job_id); print(job.id, job.exc_info.splitlines()[-1] if job.exc_info else '')`. İki tuzak vardır: İşe göre değil, istisnaya göre gruplandırma yapın. Aynı traceback ile bin işin başarısız olması tek bir olaydır. Mesajı normalleştirin (ID'leri, zaman damgalarını, ana bilgisayarları kaldırın) ve geri kalanına göre gruplandırın, aksi takdirde neredeyse aynı girişlerle boğulursunuz. Ayrıca worker kalp atışlarını izleyin: RQ worker'ları Redis'e kaydolur; eğer bir worker iş ortasında ölürse, iş StartedJobRegistry'de TTL'si dolana kadar kalabilir. Artan 'başlatıldı ama bitmedi' sayısı, kuyruk sorunu gibi görünen bir worker sağlığı sorunudur.
Sinyalleri uyarılara dönüştürmek için birkaç seçenek vardır: Kendi cron işiniz ve eşikleriniz (ucuz, ancak oran hesaplaması, gruplama ve teslimatı siz oluşturursunuz), Prometheus + Grafana (kayıt sayılarını dışa aktarın, örneğin rq-exporter ile, ve Grafana'da uyarı ayarlayın), veya bir barındırılan monitör (olayları gönderin ve pencereleri, gruplamayı ve yönlendirmeyi o yönetsin). İlke her kuyruk için aynıdır: worker'ın dışından izleyin, tek bir başarısızlık yerine oran üzerinden uyarı verin ve aynı başarısızlıkları gruplandırın ki bir yeniden deneme fırtınası tek bir sayfa olsun.
Tam açıklama: Ben PipeRadar'da çalışıyorum, bu işi yapan barındırılan bir monitör. PipeRadar, başarısızlık kümeleme, gecikme yüzdelikleri, geçmiş ve oran tabanlı uyarıları (Slack/PagerDuty/webhooks) sunar. Şu anda sadece BullMQ için çalışıyor; RQ yol haritasında, henüz çıkmadı. Alım API'si kuyruk-agnostiktir (her kuyruk sistemi için bir adaptör türü modeller), bu nedenle RQ adaptörü eksik olan parçadır, yeniden yazma değil. Bu tür bir RQ izleme kullanacaksanız, yol haritasında yukarı çekmenin en hızlı yolu bunu belirtmektir. Bu arada, yukarıdaki desenler sadece Redis ve bir cron ile çalışır. Daha derinlemesine arka plan iş izleme bilgisi için piperadar.dev/blog adresini ziyaret edin.
Kaynak: dev.to
