انفجار الكارديناليتي في Prometheus: ليه بياكل رامك وبيموت بـ OOMKilled، وإزاي توقفه

# أكبر المقاييس من حيث عدد السلاسل
curl -s 'http://localhost:9090/api/v1/status/tsdb' | jq '.data.seriesCountByMetricName[:10]'

# وأكبر الليبلات من حيث عدد القيم المميزة
curl -s 'http://localhost:9090/api/v1/status/tsdb' | jq '.data.labelValueCountByLabelName[:10]'

ولو عايز تقيس إجمالي السلاسل النشطة وتراقب اتجاهها، استخدم استعلامات PromQL دي مباشرة:

لو لقيت مقياس واحد بياخد مئات الآلاف من السلاسل، أنت لقيت القنبلة.

إزاي تصلّحها: الـ relabeling (الحل الأسرع)

أسرع علاج وأرخصه هو إنك تحذف الليبل غير المحدود قبل ما يتخزّن، عبر metric_relabel_configs. المثال ده بيمسح ليبل user_id ويشيل أي مقياس debug بالكامل:

وكـ حاجز أمان (guardrail) على مستوى الـ scrape، فعّل الحدود دي علشان أي target بيتعدّى السقف يتم رفضه بدل ما يفجّر الـ TSDB:

سيناريو واقعي بأرقام

في حادثة موثّقة (أبريل 2025)، مقياس nginx_ingress_controller_request_duration_seconds_bucket وصل لـ 256,548 سلسلة واستهلك حوالي 770 ميجابايت رام لوحده (256,548 × 3000 بايت). وفي كلاستر Kubernetes بيراقب 1,200 ServiceMonitor بربط 1:1، اتولّدت 50 مليون سلسلة زمنية، اللي محتاجة حوالي 150 جيجابايت رام قبل ما تحسب أصلًا الاستعلامات أو الـ WAL. دي مش أرقام نظرية، دي أسباب مباشرة لـ OOMKilled في الإنتاج.

الـ trade-offs بصراحة

حذف الليبل بيوفّر رام حقيقي، بس بتخسر القدرة على التقطيع (slicing) بالبُعد ده. لو محتاج تحلّل السلوك per-user، الـ label مش المكان الصح للبيانات دي — استخدم logs أو نظام tracing زي حاجة مبنية على OpenTelemetry، أو حوّلها لـ exemplars. القاعدة: الـ metrics للاتجاهات المجمّعة، مش لتتبّع كيان فردي.

بديل تاني: بدل ما تحذف، ممكن تعمل aggregation عبر recording rules تجمّع السلاسل في مقياس أقل كارديناليتي. بتكسب استعلامات أسرع وذاكرة أقل، بتخسر التفاصيل الدقيقة للسلاسل الأصلية.

متى لا تشغّل بالك بالموضوع

لو إجمالي السلاسل النشطة عندك أقل من بضع مئات الآلاف والرام مستقرة، مفيش مشكلة أصلًا، ومتقعدش تعمل optimization مبكّر. الحدود اللي بتقلق منها بتبدأ من ملايين السلاسل على instance واحد. كمان لو الليبل عدد قيمه محدود ومعروف (زي كود دولة أو نوع جهاز)، سيبه زي ما هو — مش كل ليبل نصّي هو قنبلة.

الخطوة التالية

افتح دلوقتي http://localhost:9090/api/v1/status/tsdb على Prometheus بتاعك وبُص على seriesCountByMetricName. لو لقيت مقياس واحد بياخد أكتر من 100 ألف سلسلة، حدّد الليبل المسؤول من labelValueCountByLabelName، وضيف له labeldrop في metric_relabel_configs. أعد التشغيل وراقب prometheus_tsdb_head_series — المفروض ينزل فورًا.

المصادر

• Prometheus Docs — Metric and label naming (تحذير رسمي من الليبلات غير المحدودة)
• Prometheus Docs — TSDB Stats endpoint (/api/v1/status/tsdb)
• Prometheus Docs — relabel_config و metric_relabel_configs
• High Cardinality Labels Are Killing Your Prometheus — Kaidalov (2025) لأرقام الحوادث
• How Cloudflare runs Prometheus at scale — Cloudflare Blog